De 57 para 92 no PageSpeed sem tirar nada da página

A primeira vez que rodei o PageSpeed Insights na home do Curtly no celular, a nota de desempenho foi 57. O LCP (o tempo até o maior elemento da tela aparecer) estava em 8,1 segundos e o primeiro conteúdo levava 5,9 segundos para surgir. Para um site que vende velocidade, era constrangedor. A regra que eu me impus foi simples: melhorar sem tirar nada da página, nem o AdSense, nem o Google Analytics, nem o gráfico da seção de analytics.

Este post é o diário dessa otimização, com os números de cada etapa. Inclusive as tentativas que não deram em nada.

#O ponto de partida

Métrica (celular)	Antes
Desempenho	57
First Contentful Paint	5,9 s
Largest Contentful Paint	8,1 s
Speed Index	6,3 s
Total Blocking Time	190 ms
Acessibilidade	96

O diagnóstico do próprio relatório apontava três culpados:

1. Scripts de terceiros: o AdSense, a mensagem de consentimento que vem com ele e o Google Analytics somavam quase 500 KB e quase 1 segundo de processamento.
2. CSS bloqueando a renderização: três arquivos de CSS que o navegador precisava baixar antes de desenhar qualquer coisa.
3. JavaScript próprio pesado: um pedaço grande vinha da biblioteca de gráficos, carregada logo de cara para desenhar um gráfico que fica no meio da página.

#O que funcionou

#1. CSS dentro do HTML

O site usa Tailwind, que gera um CSS pequeno. O Next.js tem uma opção experimental, inlineCss, que coloca esse CSS direto no HTML em vez de um arquivo separado. A própria documentação recomenda isso para sites com Tailwind que recebem muitos visitantes novos, que é exatamente o caso de quem chega pela busca. Menos uma ida e volta na rede antes da primeira pintura.

#2. O gráfico só quando aparece

A biblioteca de gráficos (cerca de 100 KB) passou a ser baixada só quando a pessoa rola até a seção. Usei um IntersectionObserver que carrega o componente quando ele está a 300 pixels de entrar na tela, e reservei a altura dele antes, para a página não "pular" quando o gráfico surge. O CLS continuou em zero.

#3. AdSense e Analytics depois da página abrir

Os dois passaram a carregar com a estratégia lazyOnload, depois que a página termina de abrir. Antes de fazer isso, conferi uma coisa: a verificação de propriedade do AdSense não dependia do script, porque o site já tinha a metatag e o ads.txt. Então não havia risco de quebrar a aprovação.

#4. Menos JavaScript em quem não precisa

O título principal estava dentro de um componente marcado para rodar no navegador, sem nenhum motivo: não tinha estado nem interação. Virou um componente de servidor. E a biblioteca de notificações do painel, que carregava no site inteiro, passou a carregar só nas áreas que usam notificação.

#O resultado da primeira rodada

Métrica (celular)	Antes	Depois
Desempenho	57	88
First Contentful Paint	5,9 s	1,4 s
Largest Contentful Paint	8,1 s	3,2 s

Um salto enorme com quatro mudanças, e nenhuma delas tirou algo da página.

#O que não funcionou

Aqui está a parte que quase ninguém conta. Com a nota em 88, o LCP ficou travado em torno de 3,5 segundos nos meus testes locais, e o relatório dizia que 63% desse tempo era "atraso de renderização" do título.

Minha primeira suspeita foram as fontes. Testei tirar o preload das fontes que só aparecem lá embaixo da página. Depois testei tirar o preload da própria fonte do título. Rodei três vezes cada versão. Nenhuma mudou o resultado. Desfiz as duas, porque mudança sem ganho é só risco.

#A descoberta: o LCP do relatório é uma simulação

Fui olhar os números "observados" do próprio relatório. No navegador real, durante o teste, o título aparecia em 0,2 segundo. Os 3,4 segundos eram uma estimativa.

A documentação do Lighthouse explica: por padrão, ele usa "uma simulação do carregamento da página, baseada nos dados observados no carregamento inicial sem limitação". Ele carrega a página rápido e depois calcula como ela seria num celular lento. Nessa conta, o tempo do título cresce com o volume total de JavaScript da página, mesmo que o JavaScript não esteja impedindo o título de aparecer.

Isso mudou a estratégia: em vez de caçar o título, o caminho era reduzir o JavaScript total. O que sobra, a esta altura, é quase todo do próprio Next.js e do React, que não dá para tirar, e dos scripts do Google que eu decidi manter.

#Acessibilidade: de 96 para 100

Enquanto isso, a acessibilidade tinha um problema concentrado num lugar só: o cinza dos textos secundários. Ele tinha contraste de cerca de 4:1 sobre o fundo escuro, abaixo do mínimo recomendado de 4,5:1. Clareei esse cinza um pouco, de #717171 para #8f8f8f, e o problema sumiu no site inteiro de uma vez. Completei com sublinhado nos links no meio do texto e descrição nas caixinhas de checklist dos posts.

#Onde chegamos

Métrica (celular)	Antes	Agora
Desempenho	57	92
First Contentful Paint	5,9 s	1,1 s
Largest Contentful Paint	8,1 s	2,9 s
Total Blocking Time	190 ms	30 ms
Acessibilidade	96	100
Práticas recomendadas	100	100
SEO	100	100

#O que eu levaria para qualquer site

• Meça três vezes. A nota varia de um teste para outro. Decidir com um teste só é decidir no escuro.
• Uma mudança por vez. Foi assim que eu descobri que mexer nas fontes não ajudava.
• Leia os números observados. Eles dizem o que o usuário real sente; a nota diz o que a simulação estima.
• Tire terceiros do caminho, não da página. Carregar AdSense e Analytics depois da abertura resolveu muito sem perder nada.
• Não persiga o 100 a qualquer custo. Com anúncios e analytics, 90 e poucos no celular é um resultado muito bom. O resto do tempo rende mais em conteúdo.

Fontes: Lighthouse: como funciona a limitação simulada, Next.js: inlineCss, web.dev: Largest Contentful Paint, Chrome: Speed Index.