Por qué su LCP es lento
El LCP es una carrera entre la solicitud de su página por parte del navegador y la finalización del renderizado de ese único elemento más grande. Casi todo LCP lento se remonta a una de cuatro cosas que se interponen en esa carrera:
- Time to First Byte lento. Si el servidor tarda 2 segundos solo en responder, el LCP no puede empezar el reloj antes de eso: todo lo que viene después hereda el retraso.
- Una imagen destacada sin optimizar. Un PNG de 4 MB servido al tamaño de visualización en lugar de un formato comprimido y correctamente dimensionado es la causa individual más común que vemos.
- CSS o JS que bloquean el renderizado en
<head>. El navegador no puede pintar nada, incluido el elemento LCP, hasta que termina de descargar y analizar los recursos que bloquean el renderizado. - Descubrimiento tardío de recursos. Si la imagen LCP solo se referencia en lo profundo de un
background-imagede CSS o se carga mediante JavaScript después de la hidratación, el navegador ni siquiera sabe que debe empezar a obtenerla hasta mucho más tarde de lo que podría haberlo hecho.
Cómo identificar su elemento LCP
Adivinar cuál es su elemento LCP no es fiable: cambia con el tamaño del viewport y el contenido. La Auditoría de sitio web de Scanverra ejecuta una pasada real de Lighthouse tanto en un perfil de escritorio como en un viewport móvil de 375 px, y reporta el valor y el tiempo del LCP directamente de esa ejecución, no una estimación, así que está viendo la misma métrica que eventualmente reflejan los datos de campo de Google, no un sustituto de ella.
En Chrome DevTools también puede abrir el panel de Rendimiento, grabar una carga de página y buscar el marcador "LCP" en la pista de tiempos: resalta el elemento exacto en la página renderizada cuando lo pasa el cursor por encima.
Cómo solucionarlo
1. Precargue el recurso LCP real
Si el navegador solo puede descubrir su imagen destacada después de analizar CSS o ejecutar JS, indíquele la imagen de antemano en su lugar:
1export default function RootLayout() {
2 return (
3 <html lang="en">
4 <head>
5 <link
6 rel="preload"
7 as="image"
8 href="/hero.webp"
9 fetchPriority="high"
10 />
11 </head>
12 <body>{/* ... */}</body>
13 </html>
14 );
15}2. Marque la imagen LCP como prioridad alta
Si está renderizando la imagen destacada mediante una etiqueta de imagen a nivel de componente, márquela como el recurso prioritario para que no se cargue de forma diferida y compita primero por el ancho de banda:
1<img
2 src="/hero.webp"
3 alt="Product dashboard overview"
4 width={1200}
5 height={630}
6 fetchPriority="high"
7 loading="eager"
8/>3. Comprima y dimensione correctamente la imagen en sí
Sirva AVIF o WebP en lugar de PNG/JPEG cuando el navegador lo soporte, y nunca envíe una imagen más grande que el tamaño máximo al que realmente se mostrará: una imagen de origen de 3000 px de ancho reducida con CSS sigue costando la descarga completa.
4. Resuelva primero el TTFB
Precargar una imagen que carga lento no soluciona un servidor lento. Si el TTFB representa una parte significativa de su presupuesto de LCP, arregle eso primero: consulte la guía de TTFB más abajo, ya que cualquier otra optimización de LCP está limitada por lo tarde que el navegador puede siquiera empezar.
5. Elimine los recursos que bloquean el renderizado de la ruta crítica
Aplace o cargue de forma asíncrona el JavaScript no crítico, incorpore en línea la pequeña cantidad de CSS necesaria para el contenido por encima de la línea de flotación, y cargue el resto de su hoja de estilos sin bloquear el primer pintado.
Cómo detecta Scanverra los problemas de LCP
Las verificaciones de rendimiento de Scanverra ejecutan una auditoría genuina de Lighthouse contra su URL en vivo tanto en escritorio como en un viewport móvil de 375 px, y reportan el tiempo real de LCP de esa ejecución junto con las demás Core Web Vitals: esto no es una estimación sintética ni una cifra de terceros almacenada en caché.