gmbapi: LCP de 5 a 1,9 segundos, solucionado en una llamada

 Power hour · gmbapi
LCP de 5 a 1,9 segundos, solucionado en una llamadaUna empresa de SEO local con un sitio nuevo en Next.js: rápido en escritorio y lento en móvil.
1,9sLCP en CrUX, antes 5s
150msINP en móvil, antes 220ms
700msrespuesta del servidor, antes 3s
0,00CLS en CrUX, antes 0,08
Clientegmbapi, software de SEO local
PlataformaReact, Next.js, headless CMS
ServicioPower hour, agosto de 2026
 El cliente
Un sitio nuevo que aprobaba en escritorio y fallaba en móvilgmbapi es una empresa de software de SEO local, y de las buenas. En julio de 2026 migraron de WordPress a un sitio nuevo en React y Next.js sobre un headless CMS. En escritorio cumplía los Core Web Vitals. En móvil, el LCP, el FCP y el INP no.
Conozco a Michel van Luijtelaar, que está al frente, desde 2021. Me pidió revisar su sitio en WordPress en 2023 y otra vez en 2025; en julio de 2026 vino con el nuevo.
 Qué encontramos, qué hicimos
Muerte por mil cortesNo había un solo gran problema, y casi nunca lo hay. Grabamos una carga en móvil con DevTools, recorrimos la traza desde el primer byte hasta el LCP y fuimos corrigiendo cosas mientras hablábamos.
Qué fallaba
Qué hicimos
TTFB
El servidor tardaba 3 segundos en entregar el primer byte. Cada página se renderizaba por petición y pedía su contenido en vivo al headless CMS. Además, las cabeceras de caché indicaban no-store, así que la CDN nunca guardaba el HTML.
Las páginas pasaron a renderizado estático con ISR, se cachearon las peticiones al CMS y las cabeceras permitieron a la CDN guardar el HTML. La respuesta del servidor bajó a 700 ms, tiempo que se descuenta directamente del FCP y del LCP antes de tocar nada más.
LCPINP
Etiquetas y analítica en el head, widgets de terceros arriba del todo y componentes renderizados en el navegador que el servidor podía renderizar igual de bien. Todo ese JavaScript se usaba; solo que se ejecutaba demasiado pronto.
Las etiquetas y los widgets esperan a que la página esté lista, y esos componentes vienen del servidor.
LCP
El hero tenía lazy loading. Pasaba por next/image sin priority, el bloque del CMS aplicaba loading="lazy" a todas las imágenes y, donde el hero era un fondo CSS, el navegador lo descubría tarde.
El hero recibió priority y fetchpriority="high", el bloque del CMS una excepción para la primera imagen, y el fondo CSS pasó a ser un img real con preload. Entre todo le quitaron 120 ms al LCP.
LCP
Dos hojas de estilo, de 30 kB y 0,5 kB, que la primera pantalla tenía que esperar.
Ambas se reescribieron a 15 kB, lo que restó otros 100 ms.
LCP
Muchos detalles menores, ninguno grave por sí solo.
Seguimos avanzando por la traza y los fuimos corrigiendo uno a uno mientras hablábamos.
En CrUX
Este es el gráfico que quieres ver. El LCP de sus visitantes en móvil pasó de 5,6 segundos en su peor momento a 2,0, y la respuesta del servidor, de 4,2 a 0,8 segundos. Ambas líneas tardan semanas en bajar, porque cada punto sigue incluyendo los días lentos en su ventana de 28 días. Desde agosto, el LCP se mantiene entre 1,9 y 2,2 segundos.
2,5 s4,0 sFebMarAbrMayJunJulAgoSepOct3,8 s2,0 s5,6 sLCP en móvil, p75
0,8 s1,8 sFebMarAbrMayJunJulAgoSepOct2,0 s0,76 s4,2 sTTFB en móvil, p75
gmbapi.com en CrUX, de enero a octubre de 2026. Cada punto representa los 28 días previos a esa fecha. Verde es bueno, naranja necesita mejorar y rojo es deficiente.
Seguimiento
Tras la llamada les di acceso a CoreDash para que puedan ver a sus visitantes en móvil por página y por release, y revisé su lista de tareas. Las cifras de arriba son de CrUX, los propios field data de Google.
Una hora es suficiente si los desarrolladores están en la llamada y los cambios son pequeños. Las tareas más grandes van a las notas, ordenadas por prioridad.
 Qué aprendimos
Su hipótesis era JavaScript sin usarUna sospecha razonable en un sitio nuevo en React. La traza puso en primer lugar la respuesta del servidor y un hero con lazy loading.
Un framework nuevo no te hace rápidoAcababan de migrar a Next.js y sus valores por defecto venían con él: next/image aplica lazy loading a todas las imágenes salvo que le indiques priority, y su hero era una de ellas.
 Una hora con tus desarrolladores en la llamada: 350 €Trae a tu desarrollador y tu página más lenta. La revisamos juntos y corregimos lo que podamos mientras hablamos.
Reserva una power hourMás resultados en la página de clientes.
Core Web Vitals gmbapi: LCP de 5 a 1,9 segundos, solucionado en una llamada