Pular para o conteúdo
online
pt-BRv0.46.1 · 1d135e2

Um site rápido que continua rápido

Deixar um site rápido uma vez é fácil; difícil é mantê-lo rápido enquanto novos recursos chegam. Por isso a velocidade deixou de ser uma auditoria pontual e virou um teste que toda mudança precisa passar.

Ilustração: quatro medidores de pontuação em 100 acima de um gráfico em que as primeiras medições ultrapassam a linha do orçamento e as demais ficam abaixo dela.

Deixar um site rápido uma vez é fácil. O difícil é mantê-lo rápido enquanto você continua adicionando recursos: cada novo componente, fonte ou biblioteca deixa a página um pouco mais pesada, e ninguém percebe até o site parecer lento. Por isso, deixamos de tratar a velocidade como uma auditoria pontual e a transformamos em um teste que toda mudança precisa passar.

De onde partimos

Quando medimos este site a sério pela primeira vez, o layout pulava durante o carregamento (um Cumulative Layout Shift em torno de 0,2) e o conteúdo principal levava de 4 a 6 segundos para aparecer em uma conexão móvel limitada. A folha de estilos principal pesava 41 KB comprimida, principalmente porque componentes e código de validação feitos para a área administrativa também eram enviados aos visitantes.

O que mudamos

  • Visitantes recebem só o código de visitante. A biblioteca de UI do painel e a biblioteca de validação de formulários não chegam mais ao site público. Um teste percorre os imports do site e falha se alguma delas voltar escondida.
  • CSS só para o que está na página. A folha de estilos principal caiu de 296 KB para 98 KB, e para 16 KB comprimida.
  • Fontes que não deslocam o layout. As fontes principais são pré-carregadas, e a página não pré-busca mais código que talvez nunca use.

O teste que mantém tudo assim

Em cada pull request, o CI faz o build do site, serve-o como a produção serve — HTTP/2, TLS, compressão — e roda o Lighthouse três vezes em quatro páginas-chave, usando a mediana. O orçamento: todas as notas no mínimo 95, o maior conteúdo visível em menos de 2 segundos, deslocamento de layout abaixo de 0,1, bloqueio da thread principal abaixo de 200 ms. Se uma mudança estoura o orçamento, o CI fica vermelho e a mudança não entra. Uma verificação de acessibilidade roda junto e, hoje, não encontra violações WCAG AA nas páginas que cobre.

O resultado

No CI, as páginas tiram 100 nas quatro categorias do Lighthouse, com o conteúdo principal visível em menos de um segundo. No site em produção, a página inicial tira 100 com o conteúdo principal em cerca de 1,2 segundo, e uma página de produto tira 98.

Também somos sinceros sobre o que ainda não está perfeito: páginas em japonês e em outros idiomas CJK são mais lentas, porque as fontes delas são bem maiores. Isso tem uma tarefa própria.

Por que isso importa para você

Uma página lenta perde visitantes antes que eles leiam uma palavra, e os buscadores também percebem. Se você criar uma landing page ou uma loja com a gente, esse orçamento vem junto — faz parte de como trabalhamos, não é um extra.

Fale com a gente sobre o seu site