Cómo mejorar el LCP: las cuatro partes del tiempo

El LCP (Largest Contentful Paint) mide cuánto tarda en aparecer el elemento visible más grande de la pantalla, normalmente una imagen o un bloque de texto, después de que el usuario abre la página. Google considera bueno un LCP de hasta 2,5 segundos en el percentil 75 de las visitas, y malo por encima de 4 segundos (web.dev). Para bajar el número, divide el tiempo en cuatro partes (TTFB, retraso hasta que empieza la descarga del recurso, duración de la descarga y retraso de renderizado), averigua cuál de ellas es grande y corrige esa. Optimizar la parte equivocada suele limitarse a pasar el tiempo a otra.

Este texto sigue la guía Optimize Largest Contentful Paint de web.dev (actualizada en marzo de 2025). Para el contexto de las tres métricas, consulta la guía de Core Web Vitals.

Qué mide el LCP y qué elementos cuentan

El tiempo del LCP empieza cuando el usuario inicia la navegación. Por eso ya incluye las redirecciones, la apertura de la conexión y el tiempo hasta el primer byte del HTML (web.dev). Los elementos que pueden ser el "contenido más grande" son:

• <img> (en imágenes animadas cuenta el primer fotograma);

• <image> dentro de un <svg>;

• <video> (cuenta lo que aparezca primero: la imagen de póster o el primer fotograma);

• elementos con imagen de fondo cargada con url() en el CSS (los degradados no cuentan);

• elementos de bloque que contienen texto.

Chrome ignora algunos casos para no premiar al elemento equivocado: elementos con opacidad 0, elementos que cubren toda la pantalla (probablemente un fondo) e imágenes de baja entropía, como los placeholders. Solo la parte visible en pantalla cuenta para el tamaño, y en una imagen redimensionada vale el menor valor entre el tamaño mostrado y el tamaño real del archivo (web.dev).

El elemento de LCP puede cambiar según el dispositivo: en el móvil, el título; en el escritorio, la foto del banner. Conviene comprobarlo en los dos antes de decidir qué optimizar.

Las cuatro partes del tiempo de LCP

web.dev divide el LCP en cuatro subpartes. Sumadas, dan el LCP completo:

Los porcentajes son de la propia guía y sirven como referencia, no como regla (web.dev). La lectura útil es comparativa: si las dos partes de "retraso" suman buena parte del LCP, el problema no es el tamaño de la imagen, y comprimir más el archivo cambiará poco.

Cómo medir cada parte

Empieza por los datos de campo, de usuarios reales, y solo después pasa al laboratorio. La diferencia entre estas fuentes se explica en Lighthouse, CrUX y RUM. Estas son las herramientas que muestran las cuatro partes:

1. La biblioteca web-vitals, en su versión de atribución, calcula las cuatro partes en la visita de cada usuario e indica cuál fue el elemento y la URL del recurso (GitHub GoogleChrome/web-vitals). Es la forma de saber qué pasa en el dispositivo de quien visita el sitio.

2. El panel Performance de Chrome DevTools muestra el LCP local junto al LCP de campo del CrUX, y los Insights de la grabación dan el tiempo de cada parte (web.dev).

3. PageSpeed Insights muestra los datos del CrUX de la URL o del origen, separados en móvil y escritorio. El diagnóstico de Lighthouse incluye el desglose del elemento de LCP.

Un ejemplo mínimo con web-vitals que registra las cuatro partes en la consola:

import {onLCP} from 'web-vitals/attribution';

onLCP(({value, attribution}) => {
  console.log('LCP', value, attribution.target, attribution.url);
  console.log('TTFB', attribution.timeToFirstByte);
  console.log('Retraso de carga', attribution.resourceLoadDelay);
  console.log('Duración de la carga', attribution.resourceLoadDuration);
  console.log('Retraso de renderizado', attribution.elementRenderDelay);
});

En producción, cambia el console.log por un envío a tu sistema de analítica. Dos indicadores ayudan en un diagnóstico rápido: un intervalo grande entre TTFB y FCP (First Contentful Paint, el primer pintado de contenido) suele indicar CSS o JavaScript que bloquean el renderizado, o un renderizado pesado en el cliente; un intervalo grande entre FCP y LCP indica que el recurso del LCP no está disponible pronto (web.dev).

Cómo reducir el TTFB: servidor, CDN y caché

Si el HTML tarda en llegar, nada más empieza. La guía de optimización del TTFB de web.dev señala estos frentes:

• Alojamiento con memoria y capacidad para el tráfico que recibe el sitio.

• CDN, para servir el contenido desde un servidor más cercano al usuario.

• Caché en el borde de la CDN con cabeceras Cache-Control, incluido el HTML cuando no está personalizado. Los parámetros únicos en la URL (de campaña, por ejemplo) pueden impedir que la página se sirva desde la caché.

• Menos redirecciones. Las más comunes son las del mismo origen, como la falta de https:// o una barra final inconsistente. HSTS evita la redirección de HTTP a HTTPS.

• HTML enviado por partes (streaming) o páginas estáticas cuando no hay personalización.

• 103 Early Hints, para que el navegador empiece a descargar recursos críticos mientras el servidor prepara la respuesta.

Para saber en qué gasta tiempo el servidor, la cabecera Server-Timing expone cada etapa del backend y aparece en DevTools y en la API de Navigation Timing:

Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2

Los nombres y números de arriba son el ejemplo de web.dev; cada backend informa sus propias etapas.

Cómo reducir el retraso de carga del recurso

El objetivo aquí es que el navegador empiece a descargar la imagen del LCP justo después de recibir el HTML.

Deja la imagen visible en el HTML inicial

El navegador tiene un lector anticipado (preload scanner) que busca recursos en el HTML antes incluso de construir la página. Solo encuentra la imagen si está en el marcado con src o srcset. Una imagen insertada con JavaScript, cargada por una biblioteca de lazy loading o definida solo en el CSS queda oculta para él (web.dev).

Si la imagen del LCP tiene que venir de un CSS externo, como el fondo de un banner, haz el preload en el <head>:

<link rel="stylesheet" href="/css/estilos.css">
<link rel="preload" fetchpriority="high" as="image"
      href="/img/banner.webp" type="image/webp">

Da prioridad alta a la imagen del LCP

El atributo fetchpriority="high" le pide al navegador que descargue la imagen antes que las demás. web.dev recomienda usarlo en una o dos imágenes como máximo, y fetchpriority="low" en imágenes que empiezan fuera de la pantalla, como las siguientes diapositivas de un carrusel:

<img src="/img/banner.webp" fetchpriority="high"
     width="1200" height="600" alt="Descripción del banner">

<img src="/img/slide-3.webp" fetchpriority="low"
     width="1200" height="600" alt="Descripción de la diapositiva">

Según los datos de compatibilidad de MDN, fetchpriority funciona desde Chrome 101, Firefox 132 y Safari 17.2 (MDN browser-compat-data). Los navegadores antiguos ignoran el atributo sin romper nada.

No uses lazy loading en la imagen del LCP

loading="lazy" hace que el navegador espere al layout para decidir si descarga la imagen, y eso retrasa justo el recurso más importante. web.dev recomienda cargar con normalidad las imágenes del área visible inicial y dejar el lazy loading para las de más abajo (web.dev). Algunos temas y plugins de CMS aplican loading="lazy" a todas las imágenes; revisa el HTML generado.

<!-- Evítalo en la imagen del LCP -->
<img src="/img/banner.webp" loading="lazy" alt="...">

<!-- Mejor así -->
<img src="/img/banner.webp" fetchpriority="high" alt="...">

Cuando sea posible, sirve la imagen del LCP desde el mismo origen que el HTML, para reutilizar la conexión ya abierta.

Cómo reducir la duración de la carga

La guía recuerda que, la mayoría de las veces, la duración de la descarga no es el mayor cuello de botella. Revisa los datos antes de invertir aquí (web.dev). Cuando sí lo es, las correcciones son:

• Formatos modernos, como AVIF y WebP, y una compresión adecuada.

• La imagen al tamaño en que se muestra, con srcset y sizes para que el navegador elija la versión correcta.

• CDN, mejor si es una CDN de imágenes.

• Pocos recursos con prioridad alta a la vez, para que no compitan por el ancho de banda.

• Una caché eficiente, para que la siguiente visita no vuelva a descargarla.

Un ejemplo de imagen responsiva, adaptado de MDN (MDN):

<img
  srcset="/img/banner-480.webp 480w, /img/banner-800.webp 800w"
  sizes="(width <= 600px) 480px, 800px"
  src="/img/banner-800.webp"
  width="800" height="400"
  fetchpriority="high"
  alt="Descripción del banner">

El navegador lee sizes, usa la primera condición verdadera para saber el ancho del espacio y elige en srcset la imagen que encaja. Los atributos width y height no cambian el LCP, pero evitan que la página salte cuando llega la imagen (consulta cómo corregir el CLS).

Cómo reducir el retraso de renderizado

Aquí la imagen ya se descargó, pero algo impide que el navegador la muestre. Las causas más comunes, según web.dev:

CSS que bloquea el renderizado

El navegador no pinta nada hasta que termina de descargar las hojas de estilo del <head>. Si el CSS llega después que la imagen, la imagen espera. Las salidas son eliminar el CSS que no se usa, aplazar lo que no hace falta en la primera pantalla, minificar y comprimir. Poner el CSS directamente en el HTML (inline) solo compensa cuando es pequeño.

JavaScript síncrono en el head

Un script sin defer ni async en el <head> detiene el procesamiento del HTML hasta que se descarga y se ejecuta:

<!-- Bloquea -->
<head>
  <script src="/js/main.js"></script>
</head>

<!-- No bloquea: se ejecuta después de procesar el HTML -->
<head>
  <script src="/js/main.js" defer></script>
</head>

Contenido construido en el navegador

Cuando la página depende de JavaScript para generar el HTML (renderizado en el cliente), la imagen del LCP solo existe después de que el script se descarga y se ejecuta. Incluso con preload, el elemento sigue esperando al código. web.dev recomienda el renderizado en el servidor y, cuando la arquitectura lo permite, páginas prerrenderizadas o generadas de forma estática. Las tareas largas de JavaScript en el hilo principal también retrasan el pintado; dividirlas ayuda al LCP y al INP (consulta cómo mejorar el INP).

Fuentes, cuando el LCP es texto

Si el elemento de LCP es un título, la fuente web puede mantener el texto invisible mientras carga. La propiedad font-display controla esto: con block el texto puede quedar invisible de 2 a 3 segundos; con swap aparece al momento con la fuente de reserva; con optional el navegador espera como máximo 100 ms y, si la fuente no ha llegado, sigue con la de reserva (web.dev). Para el LCP, la guía recomienda cualquier valor distinto de auto y block. Los archivos en WOFF2, los subconjuntos de caracteres y usar menos familias de fuentes también reducen el tiempo de descarga. swap puede provocar desplazamientos cuando la fuente cambia, tema del artículo sobre CLS.

Cómo confirmar la corrección en los datos de campo

Lighthouse y DevTools muestran el efecto del cambio al instante, en tu ordenador. El resultado que cuenta es el de los usuarios reales, y tarda en aparecer. Para seguirlo en varios sitios a la vez, consulta cómo monitorear el rendimiento de varios sitios.

1. Publica la corrección y anota la fecha.

2. Si tienes RUM (medición de usuarios reales) con web-vitals, compara el percentil 75 del LCP antes y después, separado por móvil y escritorio. Las cuatro partes muestran si la porción que atacaste se redujo.

3. En el CrUX, desde PageSpeed Insights o desde la API, el valor es una media móvil de 28 días (Chrome for Developers). La mejora entra poco a poco, a medida que los días antiguos salen de la ventana; espera el ciclo completo antes de sacar conclusiones.

4. Comprueba que la porción que redujiste no haya reaparecido en otra parte. Quitar el lazy loading, por ejemplo, puede convertir retraso de carga en duración de carga si la imagen pesa mucho.

Recuerda que el CrUX reúne datos solo de usuarios de Chrome que aceptaron compartir estadísticas, en escritorio y en Android; Chrome en iOS queda fuera (Chrome for Developers). Las páginas con poco tráfico pueden no tener datos propios en el CrUX.

Cómo revisar tu sitio

En WebVyze, el diagnóstico de LCP usa Google PageSpeed para señalar el elemento y lo que retrasa la página, y el test de Core Web Vitals muestra los datos del CrUX de los últimos 28 días, en móvil y escritorio, para hasta 10 URL. Las dos herramientas son gratuitas. En los planes de pago, un script de visitantes reales basado en la biblioteca web-vitals registra el LCP de cada visita con su causa.