Largest Contentful Paint: cómo mejorarlo en tu web

El Largest Contentful Paint (LCP) marca el momento en el que el elemento más grande visible dentro del viewport termina de renderizarse. No mide cuándo llegó el primer byte del HTML ni cuándo terminó de ejecutarse el JavaScript de la página: mide el instante en el que, para quien está mirando la pantalla, el contenido principal ya está ahí. Por eso es la métrica que más se acerca a responder una pregunta muy simple: ¿la página ya se ve lista, o el usuario sigue viendo una pantalla a medio cargar?

Esa cercanía con la percepción real explica por qué el LCP es la más citada de las Core Web Vitals, y también por qué se optimiza mal con tanta frecuencia. Es habitual pasar horas comprimiendo imágenes, moviendo scripts o cambiando de proveedor de hosting sin haber comprobado antes cuál es, en cada plantilla, el elemento que realmente determina el LCP. Si ese elemento no es el que se está tocando, el trabajo no se refleja en la métrica por mucho esfuerzo que se le dedique. Lo que sigue es justo eso: cómo identificar el elemento LCP en páginas reales, en qué fase del proceso se pierde el tiempo y qué cambios técnicos mueven la aguja de verdad, sin desviarse hacia consejos genéricos de velocidad que ya están cubiertos en otro sitio.

Qué elemento cuenta realmente como LCP

El navegador no elige el elemento LCP al azar entre todo lo que hay en la página: solo compite un grupo concreto de candidatos. Cuentan las imágenes (img), las imágenes dentro de un svg, el poster de un video antes de que arranque la reproducción, los elementos de bloque con una imagen de fondo cargada mediante background-image, y los bloques de texto que contienen nodos de texto directamente, como un titular, un párrafo o un div con texto suelto. No cuentan los iframes, ni los elementos completamente fuera del viewport, ni el fondo del body si no tiene contenido propio.

El tamaño que importa es el área visible dentro del viewport, no el tamaño real del archivo ni las dimensiones intrínsecas de la imagen. Una imagen de 4000 píxeles de ancho mostrada en un contenedor pequeño solo cuenta por el espacio que ocupa en pantalla; un bloque de texto con un salto de línea generoso puede pesar más visualmente que una imagen pequeña ubicada en la cabecera. A medida que la página renderiza, el navegador va actualizando cuál es el candidato más grande hasta que el usuario interactúa con la página con un clic, un scroll o una pulsación de tecla, o hasta que el contenido deja de cambiar; el último candidato registrado antes de esa interacción es el que se reporta como LCP.

Cómo identificar el elemento LCP en tus propias páginas

Adivinar cuál es el elemento LCP casi siempre falla, porque no siempre es lo primero que parece obvio: puede ser el titular en lugar de la imagen destacada, el fondo de una sección hero en lugar del logo, o una imagen dentro de un carrusel que carga antes que las demás. Conviene comprobarlo plantilla por plantilla, porque una página de producto y una página de blog casi nunca comparten el mismo elemento LCP aunque compartan el mismo encabezado.

• PageSpeed Insights: en la sección de diagnósticos, "Elemento de pintado de contenido más grande" señala exactamente qué nodo del DOM se está midiendo.
• Chrome DevTools, panel Performance: al grabar la carga de la página, la pista LCP marca el fotograma y resalta el elemento en el panel de captura.
• Lighthouse en modo local o en integración continua, para comprobar el elemento antes de publicar un cambio de plantilla.
• La librería web-vitals con el atributo attribution, para capturar en producción, con usuarios reales, qué elemento y qué fase están generando el LCP en cada plantilla.

Las cuatro fases del LCP

El tiempo total del LCP se descompone en cuatro fases, y cada una se arregla con un tipo de cambio distinto. Tratar el LCP como un número único lleva a aplicar la solución equivocada: precargar una imagen no ayuda si el problema real está en el servidor, y optimizar el servidor no ayuda si el problema es que la imagen se descubre tarde en el marcado.

• Time to First Byte (TTFB): desde que el navegador pide el documento HTML hasta que recibe el primer byte de respuesta. Depende del servidor, la base de datos, la caché y la distancia geográfica al usuario.
• Retraso de carga del recurso: desde que llega el HTML hasta que el navegador empieza a pedir el recurso LCP. Se dispara cuando la imagen está escondida detrás de JavaScript, CSS bloqueante o un descubrimiento tardío en el marcado.
• Tiempo de carga del recurso: cuánto tarda en descargarse ese recurso. Depende del peso del archivo, el formato, la compresión y si viene servido desde una CDN.
• Retraso de renderizado: desde que el recurso terminó de descargar hasta que el navegador lo pinta en pantalla. Aquí pesan el trabajo del hilo principal, el JavaScript que bloquea el render y el CSS que aún no ha terminado de aplicarse.

El servidor primero: por qué el TTFB es la base de todo

Ninguna optimización de imagen compensa un servidor lento, porque las otras tres fases no empiezan hasta que termina el TTFB. Si el HTML tarda 1.8 segundos en llegar, ya se ha gastado más de la mitad del presupuesto de un LCP considerado bueno antes de que el navegador haya visto una sola etiqueta de imagen.

Las causas habituales de un TTFB alto son consultas a base de datos sin índice o mal escritas, un renderizado del lado del servidor que recalcula lo mismo en cada petición sin caché, un plan de hosting compartido saturado, redirecciones innecesarias antes de llegar al documento final, y la ausencia de una CDN que sirva el HTML cerca del usuario. Las mejoras que más rinden aquí son cachear la respuesta HTML cuando el contenido no cambia por petición, revisar los índices de las consultas que arma la página, y eliminar cadenas de redirección: cada salto antes del documento final añade una ronda completa de ida y vuelta al servidor.

Precargar la imagen LCP

El navegador descubre la mayoría de las imágenes leyendo el HTML de arriba hacia abajo, así que una imagen LCP declarada de forma normal con una etiqueta img no empieza a descargarse hasta que el parser llega a esa línea. Si la imagen se inyecta con JavaScript, o está referenciada en un CSS externo como background-image, el descubrimiento se retrasa todavía más, porque el navegador primero tiene que descargar y ejecutar ese otro recurso antes de saber que la imagen existe.

Dos técnicas atacan directamente el retraso de carga del recurso: declarar un link rel="preload" as="image" en el head para que el navegador empiece a descargar la imagen LCP en paralelo con el resto del documento, y marcar la propia etiqueta img con fetchpriority="high" para indicarle al navegador que la trate como prioritaria frente a otras imágenes que compiten por el mismo ancho de banda. Ambas técnicas son complementarias: el preload adelanta el descubrimiento, y fetchpriority ajusta el orden en el que se sirven los bytes.

Tamaño correcto, formatos modernos y el error de aplicar lazy-loading a la imagen LCP

Servir una imagen más grande de lo que el layout necesita es tiempo de descarga tirado: si el contenedor mide 800 píxeles de ancho pero el archivo pesa lo que pesaría uno de 2400, el navegador descarga muchos más bytes de los que va a pintar. El atributo srcset junto con sizes deja que el navegador elija, según el ancho real del viewport, cuál de varias versiones descargar, y los formatos AVIF o WebP comprimen mejor que JPEG o PNG para un nivel de calidad visual equivalente.

El error más frecuente, y el más fácil de cometer sin darse cuenta, es aplicar el atributo de carga diferida a la imagen que resulta ser el elemento LCP. La carga diferida existe para retrasar imágenes que están fuera del viewport inicial, pero cuando se aplica de forma automática a todas las imágenes de una plantilla, por ejemplo mediante un plugin o una regla global del gestor de contenidos, también alcanza a la imagen que sí está en el viewport desde el primer fotograma. El resultado es que el navegador espera a calcular el layout antes de empezar siquiera a pedir la imagen, añadiendo justo el retraso que se estaba tratando de eliminar. La regla es simple: la imagen que ocupa la cabecera visible nunca lleva carga diferida; la carga diferida es para lo que el usuario tiene que hacer scroll para ver.

CSS y fuentes que bloquean el renderizado

Por defecto, una hoja de estilos enlazada bloquea el renderizado: el navegador no pinta nada hasta que termina de descargar y de procesar ese CSS, aunque el HTML y las imágenes ya estén listos. Cuanto más pesa la hoja de estilos, y cuantas más hojas se encadenan una detrás de otra, más se alarga el retraso de renderizado incluso cuando la imagen LCP ya terminó de descargarse.

• Insertar en línea el CSS crítico: el mínimo de estilos necesario para pintar lo que se ve sin hacer scroll, directamente en el head, para que no dependa de una petición de red aparte.
• Cargar el resto del CSS de forma diferida o asíncrona, para que no bloquee el primer pintado.
• Las fuentes web bloquean el texto mientras se descargan, salvo que se controle con la propiedad font-display. Un valor como swap muestra el texto con una fuente de sistema mientras la fuente definitiva termina de cargar, en vez de dejar el texto invisible, lo que se conoce como FOIT.
• Si el titular o un bloque de texto es el elemento LCP, precargar la fuente principal con link rel="preload" as="font" ataca el mismo retraso de renderizado que afecta a las imágenes precargadas.

Datos de campo frente a datos de laboratorio: cuál es el que cuenta

Una auditoría con Lighthouse o con la pestaña de diagnóstico de PageSpeed Insights produce datos de laboratorio: una sola carga simulada, con una configuración de red y de dispositivo fija, ejecutada en el momento en que se lanza la prueba. Es útil para depurar, porque desglosa las cuatro fases y señala el elemento exacto, pero no representa lo que experimentan los visitantes reales.

Los datos de campo vienen del Chrome UX Report (CrUX), construido a partir de visitas reales de usuarios de Chrome que han dado su consentimiento para compartir métricas de uso, agregadas por origen o por página a lo largo de una ventana móvil de varias semanas. Es el dato de campo, no el de laboratorio, el que aparece en el informe de Core Web Vitals de Search Console y el que se usa como señal de experiencia de página. Dos sitios pueden tener resultados de laboratorio idénticos y un LCP de campo muy distinto, porque el dato de campo incluye la variedad real de conexiones lentas, dispositivos de gama baja y condiciones de red que un laboratorio con una sola configuración no puede reproducir. La forma correcta de trabajar es usar el laboratorio para diagnosticar qué fase falla y qué elemento es el LCP, y usar el campo para confirmar si el cambio realmente movió la experiencia de los usuarios reales.