gmbapi: LCP de 5 para 1,9 segundos, corrigido em uma chamada

 Power hour · gmbapi
LCP de 5 para 1,9 segundos, corrigido em uma chamadaUma empresa de SEO local com um site novo em Next.js, rápido no desktop e lento no celular.
1,9sLCP no CrUX, era 5s
150msINP no celular, era 220ms
700msresposta do servidor, era 3s
0,00CLS no CrUX, era 0,08
Clientegmbapi, software de SEO local
PlataformaReact, Next.js, headless CMS
ServiçoPower hour, agosto de 2026
 O cliente
Um site novo que passava no desktop e falhava no celularA gmbapi é uma empresa de software de SEO local — e das boas. Em julho de 2026, eles migraram do WordPress para um site novo em React e Next.js com headless CMS. No desktop, passavam no Core Web Vitals. No celular, o LCP, o FCP e o INP falhavam.
Conheço Michel van Luijtelaar, que comanda a empresa, desde 2021. Ele me pediu para analisar o site em WordPress em 2023 e de novo em 2025. Em julho de 2026, trouxe o novo.
 O que encontramos, o que fizemos
Morte por mil cortesNão havia um grande problema isolado — quase nunca há. Gravamos o carregamento de uma página no celular pelo DevTools, analisamos o trace do primeiro byte até o LCP e fomos corrigindo os problemas durante a chamada.
O que estava errado
O que fizemos
TTFB
O servidor levava 3 segundos até o primeiro byte. Todas as páginas eram renderizadas a cada requisição e buscavam o conteúdo em tempo real no headless CMS. Como os cabeçalhos de cache definiam no-store, a CDN nunca guardava o HTML.
As páginas passaram para renderização estática com ISR, as consultas ao CMS entraram em cache e os cabeçalhos permitiram à CDN guardar o HTML. A resposta do servidor caiu para 700 ms, e isso sai direto do FCP e do LCP antes de mexer em qualquer outra coisa.
LCPINP
Tags e analytics no head, widgets de terceiros no topo da página e componentes renderizados no navegador que o servidor poderia muito bem renderizar. Todo esse JavaScript era usado; só rodava cedo demais.
As tags e os widgets esperam a página carregar, e esses componentes vêm do servidor.
LCP
O hero estava com lazy loading. Ele passava pelo next/image sem priority, o bloco do CMS aplicava loading="lazy" em todas as imagens e, onde o hero era um background em CSS, o navegador só encontrava a imagem tarde demais.
O hero recebeu priority e fetchpriority="high", o bloco do CMS ganhou uma exceção para a primeira imagem e o background em CSS virou uma tag img de verdade com preload. Juntas, essas mudanças tiraram 120 ms do LCP.
LCP
Duas folhas de estilo, de 30 kB e 0,5 kB, que a primeira tela ficava esperando.
Reescrevemos as duas para 15 kB, tirando outros 100 ms.
LCP
Vários detalhes menores, nenhum grande por si só.
Seguimos avançando pelo trace e corrigindo um a um durante a chamada.
No CrUX
É este o gráfico que você quer ver. O LCP para os visitantes no celular foi de 5,6 segundos no pior momento para 2,0, e a resposta do servidor caiu de 4,2 para 0,8 segundos. As duas linhas levam semanas para baixar, porque cada ponto ainda contabiliza os dias lentos na sua janela de 28 dias. Desde agosto, o LCP se mantém entre 1,9 e 2,2 segundos.
2,5 s4,0 sFevMarAbrMaiJunJulAgoSetOut3,8 s2,0 s5,6 sLCP no celular, p75
0,8 s1,8 sFevMarAbrMaiJunJulAgoSetOut2,0 s0,76 s4,2 sTTFB no celular, p75
gmbapi.com no CrUX, de janeiro a outubro de 2026. Cada ponto representa os 28 dias até aquela data. Verde é bom, laranja precisa melhorar, vermelho é ruim.
Acompanhamento
Depois da chamada, dei acesso ao CoreDash para eles verem os visitantes no celular por página e por release, e revisei a lista de tarefas. Os números no topo vêm do CrUX, o field data do próprio Google.
Uma hora é suficiente quando os desenvolvedores estão na chamada e os ajustes são pequenos. Problemas maiores vão para as notas, os mais importantes primeiro.
 O que aprendemos
O palpite deles era JavaScript não utilizadoUm palpite razoável para um site novo em React. Mas o trace colocou a resposta do servidor e o hero com lazy loading no topo.
Um framework novo não deixa você rápidoEles tinham acabado de migrar para o Next.js e os padrões vieram juntos: o next/image aplica lazy loading em todas as imagens se você não definir priority, e o hero era uma delas.
 Uma hora com seus desenvolvedores na chamada: €350Traga seu desenvolvedor e sua página mais lenta. Analisamos tudo juntos e corrigimos o que der durante a chamada.
Agende uma power hourVeja mais resultados na minha página de clientes.
Core Web Vitals gmbapi: LCP de 5 para 1,9 segundos, corrigido em uma chamada