Aprender
Optimización LCP: mejora Largest Contentful Paint y velocidad de página
Una guía profunda de Largest Contentful Paint: las cuatro fases que lo forman, cómo identificar tu elemento LCP y las correcciones que de verdad lo mueven.
Ejecuta una auditoría nueva en DomainLens y usa el informe como lista de prioridades.
Qué mide LCP
Largest Contentful Paint (LCP) marca el momento en que el elemento de contenido más grande del viewport — normalmente una imagen hero, un póster de vídeo o un bloque grande de texto — termina de renderizarse. Es la métrica que mejor responde «¿cuándo pareció realmente lista la página?», de ahí su vínculo con la sensación de velocidad.
Un buen LCP es 2,5 segundos o menos en el percentil 75 de usuarios reales; por encima de 4 segundos es malo. Como se mide en campo sobre tu cuarto de visitas más lento, una página instantánea en la oficina aún puede fallar.
Las cuatro fases de un LCP
Lo más útil es dejar de ver LCP como un solo número y descomponerlo en cuatro subpartes. Casi cada corrección apunta a una de ellas, así que medir el reparto indica adónde va realmente el tiempo:
- Time to First Byte (TTFB): cuánto tarda el servidor en enviar el primer byte. Backends lentos, falta de caché y hosting lejano viven aquí.
- Resource load delay: el hueco entre el primer byte y el inicio de descarga de la imagen LCP — normalmente por descubrimiento tardío o prioridad baja.
- Resource load time: cuánto tarda en descargarse la propia imagen LCP. Imágenes sobredimensionadas, sin comprimir, en formato incorrecto.
- Element render delay: el tiempo desde que la imagen se descarga hasta que se pinta — normalmente bloqueado por CSS o JavaScript que bloquea el render.
Cómo encontrar tu elemento LCP
No puedes corregir lo que no has identificado — y el elemento LCP difiere según plantilla y viewport.
- En el panel Performance, graba una carga y mira el marcador «LCP» en la pista Timings; nombra el elemento exacto.
- Ejecuta PageSpeed Insights y lee el diagnóstico «Elemento Largest Contentful Paint», que muestra el nodo y su reparto por fases.
- Revisa móvil y desktop — el elemento LCP suele ser una imagen distinta en cada uno.
- Confirma con datos de campo para optimizar el elemento que esperan los usuarios reales, no el que elige tu test de laboratorio rápido.
Cómo hacer que el elemento LCP aparezca antes
- Reduce el TTFB: cachea el HTML en el edge/CDN, calienta consultas lentas de base de datos y aloja cerca de tu audiencia.
- Haz la imagen LCP detectable de inmediato: ponla en el HTML inicial con fetchpriority="high", y precárgala si viene por CSS o la inyecta JavaScript.
- Nunca apliques lazy-load a la imagen LCP — loading="lazy" en el hero es una de las regresiones autoinfligidas más comunes.
- Reduce el archivo: sirve una imagen bien dimensionada en formato moderno (AVIF/WebP) con srcset responsive para que el móvil no descargue el hero de desktop.
- Elimina el trabajo que bloquea el render: inlinea el CSS crítico, difiere CSS y JavaScript no críticos, y no inyectes el hero con un framework de cliente tras la hidratación.
Errores que inflan el LCP
- Optimizar la puntuación de laboratorio de Lighthouse ignorando el TTFB de campo, que el laboratorio infravalora.
- Precargar todo, lo que satura la red y retrasa el único recurso que importa.
- Servir el hero desde un origen de terceros lento sin preconnect.
- Renderizar el contenido principal solo tras un fetch de datos en cliente, así el LCP espera a JavaScript y a un ida y vuelta a la API.
Cómo validar el LCP
Vuelve a ejecutar la traza Performance y confirma que la fase objetivo realmente se redujo — menor TTFB, petición de imagen más temprana, bloqueo eliminado. Luego sigue el LCP de campo en Search Console durante las semanas siguientes, ya que agrega 28 días de visitas reales.
En DomainLens, lee el LCP junto al tiempo de respuesta del servidor y los recursos que bloquean el render que reporta: la victoria más rápida suele ser hacer que la imagen hero real se pida antes y se descargue más pequeña, en la conexión móvil que usan tus visitantes.