Rápido por padrão

A velocidade aqui não é afinada por projeto , é uma propriedade da arquitetura. O site público são arquivos estáticos simples servidos do disco, sem renderização por requisição, com cache agressivo e payloads pequenos por construção. Esta página resume de onde vem a velocidade e quais ajustes você controla.

Sem renderização por requisição

Seus visitantes recebem os arquivos estáticos publicados direto do disco. A aplicação de criação nunca renderiza páginas públicas sob demanda , em produção ela está vinculada a um endereço de loopback privado, então os visitantes simplesmente não conseguem alcançá-la.

O cache que vem na configuração padrão

A configuração de exemplo do servidor define os tempos de vida de cache para que a sua implantação seja rápida por padrão:

• Páginas HTML , cache curto de 5 minutos com must-revalidate, para que o conteúdo recém-construído chegue aos leitores minutos após um build.
• Fontes , arquivos com nome baseado no hash do conteúdo, com cache de um ano e marcados como immutable.
• Outros assets estáticos (CSS, JS, imagens, ícones) , cache de um dia.
• O service worker , explicitamente não cacheado, para que uma cópia desatualizada nunca bloqueie atualizações.
• Assets do painel de administração , cache de um dia.

A compressão (zstd e gzip) está habilitada no servidor na configuração padrão.

Páginas pequenas, geradas com inteligência

O estágio de build faz na hora da publicação o trabalho que outros sistemas pagam no runtime:

• O HTML é minificado por padrão. O espaço em branco colapsa em toda página construída (há uma chave nas configurações se você precisa de saída sem minificação para depurar).
• As imagens lazy-load automaticamente. Toda imagem sem uma dica de carregamento recebe loading="lazy" durante o build.
• As imagens vão com derivadas responsivas. Quando você envia uma imagem, cópias escaladas em 320, 640 e 1280 px são geradas tanto no formato original (JPEG ou PNG) quanto em WebP, e os templates recebem atributos srcset prontos, de modo que os visitantes baixam apenas o tamanho de que precisam.

Velocidade também na hora de criar

• Builds incrementais por padrão: arquivos inalterados são pulados por hash de conteúdo, então os rebuilds do dia a dia são rápidos; um rebuild completo permanece disponível para aqueles dias em que você quiser um.
• O banco de dados nunca bloqueia a administração. O SQLite roda em modo WAL , leituras concorrentes não bloqueiam escritas , afinado com um cache generoso para a carga de trabalho esperada de uma sessão de administração ativa mais builds periódicos.
• Os builds permanecem limitados, e saída desatualizada vence saída quebrada: um build tem teto de volume de escrita e de tempo (cinco minutos), e um build que colapsa (queda na contagem de páginas, pico de links, timeout) não é promovido , o site bom anterior continua servindo.

O que não deixa o site lento

Não há JavaScript em runtime na saída pública , nada para baixar, nada para executar, nada para adiar, e nenhum beacon para carregar. As páginas de conteúdo são apenas marcação com otimizações incorporadas na hora do build.