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

 Power hour · gmbapi
LCP de 5 para 1,9 segundos, corrigido numa chamadaUma empresa de SEO local com um site novo em Next.js, rápido no desktop e lento no telemóvel.
1,9sLCP no CrUX, era 5s
150msINP no telemóvel, 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 telemóvelA gmbapi é uma empresa de software de SEO local, e das boas. Em julho de 2026 mudaram do WordPress para um site novo em React e Next.js com headless CMS. No desktop cumpria os Core Web Vitals. No telemóvel, o LCP, o FCP e o INP não.
Conheço o Michel van Luijtelaar, que a gere, desde 2021. Pediu-me para analisar o site em WordPress em 2023 e novamente em 2025, e em julho de 2026 trouxe o novo.
 O que encontrámos, o que fizemos
Morte por mil cortesNão havia um único grande problema, e quase nunca há. Gravámos o carregamento de uma página no telemóvel nas DevTools, analisámos o trace desde o primeiro byte até ao LCP e fomos corrigindo problemas durante a conversa.
O que estava mal
O que fizemos
TTFB
O servidor demorava 3 segundos até ao primeiro byte. Todas as páginas eram renderizadas a cada pedido e iam buscar o conteúdo em direto ao headless CMS. Como os headers de cache tinham no-store, a CDN nunca guardava o HTML.
As páginas passaram para rendering estático com ISR, as chamadas ao CMS passaram a ter cache e os headers deixaram a CDN guardar o HTML. A resposta do servidor desceu para 700 ms, o que abate logo no FCP e no LCP antes de se mexer em mais nada.
LCPINP
Tags e analytics no head, widgets de terceiros no topo da página e componentes renderizados no browser que o servidor podia perfeitamente renderizar. Todo esse JavaScript era utilizado; só corria demasiado cedo.
As tags e os widgets passaram a esperar até a página estar pronta, e esses componentes vêm do servidor.
LCP
O hero tinha lazy loading. Passava pelo next/image sem priority, o bloco do CMS colocava loading="lazy" em todas as imagens e, onde o hero era um background em CSS, o browser só o encontrava demasiado tarde.
O hero passou a ter priority e fetchpriority="high", o bloco do CMS ganhou uma exceção para a primeira imagem e o background em CSS passou a ser uma tag img real com preload. No total, retirou 120 ms ao LCP.
LCP
Duas stylesheets, de 30 kB e 0,5 kB, pelas quais o primeiro ecrã ficava à espera.
Ambas reescritas para 15 kB, o que retirou outros 100 ms.
LCP
Muitas coisas pequenas, nenhuma delas grave por si só.
Continuámos a percorrer o trace e corrigimo-las uma a uma durante a chamada.
No CrUX
É este o gráfico que se quer ver. O LCP para os visitantes em telemóvel passou de 5,6 segundos no pior momento para 2,0, e a resposta do servidor de 4,2 para 0,8 segundos. Ambas as linhas demoram semanas a descer, porque cada ponto ainda contabiliza os dias lentos da sua janela de 28 dias. Desde agosto, o LCP tem-se mantido entre 1,9 e 2,2 segundos.
2,5 s4,0 sFevMarAbrMaiJunJulAgoSetOut3,8 s2,0 s5,6 sLCP no telemóvel, p75
0,8 s1,8 sFevMarAbrMaiJunJulAgoSetOut2,0 s0,76 s4,2 sTTFB no telemóvel, p75
gmbapi.com no CrUX, de janeiro a outubro de 2026. Cada ponto corresponde aos 28 dias até essa data. Verde é bom, laranja precisa de melhorias, vermelho é fraco.
Acompanhamento
Depois da chamada, dei-lhes acesso ao CoreDash para poderem ver os visitantes em telemóvel por página e por release, e verifiquei a lista de tarefas. Os números no topo vêm do CrUX, os field data da própria Google.
Uma hora chega quando os developers estão na chamada e as correções são pequenas. As coisas maiores vão para as notas, as mais importantes primeiro.
 O que aprendemos
A suspeita deles era JavaScript não utilizadoUma suspeita razoável num site React novo. O trace colocou a resposta do servidor e um hero com lazy loading no topo.
Uma framework nova não o torna rápidoTinham acabado de mudar para Next.js, e o comportamento por omissão veio com ele: o next/image aplica lazy loading a todas as imagens a menos que se defina priority, e o hero era uma dessas imagens.
 Uma hora com os seus developers na chamada: 350 €Traga o seu developer e a página mais lenta. Analisamo-la em conjunto e corrigimos o que for possível durante a chamada.
Marcar uma power hourMais resultados na página de clientes.
Core Web Vitals gmbapi: LCP de 5 para 1,9 segundos, corrigido numa chamada