Cómo mejorar Largest Contentful Paint corrigiendo la etapa más lenta de LCP

Para mejorar Largest Contentful Paint, identifica el elemento que determina LCP y mide qué retrasa su aparición. Si es una imagen, separa la espera del HTML, el retraso hasta iniciar la solicitud, la descarga y la espera restante hasta el renderizado. Corrige la etapa realmente lenta en lugar de aplicar todas las optimizaciones de imágenes a la vez.

Un LCP bueno es de 2,5 segundos o menos en el percentil 75. Ese objetivo describe un resultado para los visitantes. No indica si la causa es un servidor lento, una fotografía descubierta tarde o una página que oculta contenido ya descargado hasta que termina JavaScript.

Encuentra el elemento antes de cambiar su entrega

Graba la carga en Chrome DevTools con el tamaño de ventana que necesitas investigar. Inspecciona el evento LCP y su elemento asociado. Compáralo con lo visible en la grabación: el navegador puede elegir después un candidato mayor conforme avanza la carga.

Entre los candidatos hay imágenes y bloques de texto, con reglas adicionales para fondos y vídeo. LCP no es simplemente el nodo DOM más grande ni la última solicitud de red. Un contenedor lleno de espacio vacío no se convierte en contenido significativo por sus dimensiones.

Repite la comprobación en las plantillas y dispositivos pertinentes. Un titular puede determinar LCP móvil y una imagen de producto el de escritorio. Un experimento o el estado de consentimiento también puede cambiar lo visible. Registra las condiciones junto al elemento para repetir el mismo escenario.

En un proyecto que incorpora la versión de atribución de web-vitals, este módulo registra la URL de imagen y los tiempos de cada etapa cuando están disponibles.

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

onLCP(({ value, attribution }) => {
  console.table({
    lcp: value,
    resource: attribution.url ?? 'Text or no image resource',
    ttfb: attribution.timeToFirstByte,
    loadDelay: attribution.resourceLoadDelay,
    loadDuration: attribution.resourceLoadDuration,
    renderDelay: attribution.elementRenderDelay
  });
});

Es una ayuda de observación, no un servicio completo de monitorización. Necesita un paquete compatible instalado y una compilación que resuelva sus importaciones. La recopilación de campo requiere además un endpoint y una agregación cuidadosamente diseñados. Comprueba la versión y su interfaz de atribución al incorporar el ejemplo.

Utiliza las cuatro etapas para elegir el primer arreglo

La guía de optimización de LCP de Google divide el LCP de imágenes en etapas correspondientes a distintos trabajos. En un LCP de texto puede no haber descarga de imagen: no inventes una para adaptar el caso al modelo.

Un cambio útil acorta el recorrido completo hasta el contenido visible. Supón que la imagen termina antes pero espera la misma tarea larga de renderizado. Mejora la descarga y aumenta el retraso posterior, dejando LCP casi igual. Es un diagnóstico real, no una demostración de que comprimir imágenes nunca sirva.

Conserva la traza original. La comparación debe mostrar qué etapa cambió y si el mismo elemento sigue determinando LCP. Si cambia el candidato, investiga esa transición en lugar de comparar recursos distintos sin explicarlo.

Reduce el tiempo hasta la llegada del HTML

El navegador no descubre recursos ordinarios del documento hasta recibir suficiente HTML para identificarlos. Sigue la navegación por redirecciones, conexión y respuesta final. Una cadena de redirecciones retrasa el descubrimiento aunque la aplicación sea rápida.

Compara respuestas con y sin caché. Un inicio ya almacenado puede ocultar ejecución lenta en URL menos populares. Comprueba si el CDN almacena HTML o solo archivos estáticos y si alguna cookie evita inesperadamente la caché pública.

No conviertas páginas personales en públicas para mejorar una medición. La caché debe conservar sesiones, permisos y contenido correcto. La guía de tiempo de respuesta del servidor explica cómo separar estas cuestiones y medir el trabajo que evita un acierto.

El renderizado del servidor también necesita contexto. Entregar HTML útil reduce descubrimiento en el cliente, pero una generación costosa puede aumentar TTFB. Mide respuesta y aparición final. Una estructura vacía rápida no es el objetivo.

Haz que la imagen importante se descubra inmediatamente

Una URL de imagen en el HTML inicial está disponible para el mecanismo de descubrimiento del navegador. Una imagen creada después de ejecutar JavaScript hereda esa dependencia. Un fondo CSS puede requerir recibir y procesar la hoja de estilos antes de descubrir su URL.

Prefiere un elemento de imagen normal para contenido significativo cuando encaje con diseño y semántica. Añade texto alternativo preciso y dimensiones. No pongas loading="lazy" en la imagen que debe aparecer en la primera pantalla solo porque el resto de los medios use carga diferida.

Este ejemplo supone una imagen de hasta 960 píxeles CSS y una disposición móvil más estrecha. Los archivos son recursos ilustrativos que debe proporcionar tu compilación.

<img
  src="/images/guide-960.webp"
  srcset="/images/guide-640.webp 640w,
          /images/guide-960.webp 960w,
          /images/guide-1600.webp 1600w"
  sizes="(max-width: 960px) 100vw, 960px"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="A browser displaying a highlighted content panel"
>

El navegador utiliza sizes, las anchuras candidatas y las características del dispositivo para elegir. sizes debe describir el diseño real; no establece el ancho CSS. Si la imagen ocupa media columna y la describes como el ancho completo de ventana, puedes provocar una descarga excesiva.

fetchpriority="high" señala que la solicitud es importante. No hace descubrible un recurso oculto. Asignarlo a muchas imágenes competidoras debilita la prioridad pretendida. Empieza por el candidato LCP medido y revisa después la cascada.

Precarga solo cuando el descubrimiento anticipado resuelva un retraso

La precarga sirve para un recurso crítico que de otro modo se descubriría tarde. No es una instrucción para solicitar todo lo visible antes de que el navegador organice su trabajo.

En un fondo CSS realmente crítico, una precarga de imagen puede iniciar la solicitud antes de que lo revele la hoja de estilos. Este par emplea la misma URL para reutilizar la petición prevista.

<link rel="preload" as="image" href="/images/banner.webp"
      fetchpriority="high">

.banner {
  min-height: 18rem;
  background-image: url('/images/banner.webp');
  background-size: cover;
  background-position: center;
}

Las dimensiones del ejemplo son decisiones de diseño, no umbrales de rendimiento. Usa una imagen con semántica cuando la ilustración comunique información que requiera texto alternativo.

Si precargas imágenes adaptables, su selección debe coincidir. Una URL fija puede desperdiciar ancho de banda si el elemento selecciona otra variante. Comprueba URL, tipos de recursos y comportamiento de credenciales, sin suponer que dos referencias parecidas son una sola transferencia.

Después de añadir la indicación, verifica si la solicitud útil empezó antes y si desplazó otro trabajo crítico. Una advertencia de precarga no utilizada exige investigar la implementación, no simplemente ocultarla.

Reduce bytes sin deteriorar el contenido

Cuando el descubrimiento sea oportuno, revisa dimensiones seleccionadas y tamaño transferido. Exporta variantes para el espacio real y la densidad de píxeles prevista. Una pantalla de alta densidad puede necesitar más píxeles de imagen que de ancho CSS; no se trata de igualar siempre ambas cifras.

Compara formatos y ajustes sobre la imagen real. AVIF o WebP pueden ser útiles, pero influyen el contenido, la calidad necesaria y la codificación. Texto fino, diagramas y fotografías no responden igual a la compresión.

Inspecciona el resultado al tamaño mostrado. No aceptes detalles de producto borrosos, letras dañadas o artefactos solo porque el archivo pese menos. Conserva el original y ajustes reproducibles para que futuras ediciones no deshagan la mejora.

Un CDN de imágenes o una transformación del CMS puede automatizar variantes, pero verifica HTML generado y solicitud elegida. Una función llamada adaptable no demuestra que sizes coincida con tu tema. La guía de optimización de imágenes desarrolla formatos y marcado adaptable.

Utiliza la calculadora de ahorro en imágenes para comparar bytes. Estima ahorro de transferencia con tus valores, no milisegundos de mejora de LCP. Siguen importando carga paralela, caché y otras etapas.

Investiga la distancia entre descarga y aparición

Si la imagen llegó pero aparece mucho después, averigua qué la impide renderizar. Pueden faltar estilos, JavaScript puede ocupar el hilo principal o el componente puede permanecer oculto hasta una animación, inicialización o estado renderizado en el cliente.

Elimina dependencias de visibilidad innecesarias. Una imagen importante no debería esperar lógica de carrusel ajena si la primera diapositiva cabe en HTML ordinario. Revisa si una superposición de carga tapa contenido listo o una animación de entrada retrasa la métrica sin ayudar al visitante.

Examina con cuidado el CSS que bloquea renderizado. El objetivo no es borrar todas las hojas ni aplazar todo el estilo. La primera pantalla necesita reglas correctas para evitar destellos y movimientos. Identifica recursos no usados o secundarios y conserva los necesarios en el área inicial.

El hilo principal puede retrasar el renderizado aunque termine la red. Busca scripts grandes, hidratación e inicialización síncrona alrededor del momento relevante. La guía de recursos que bloquean el renderizado distingue dependencias de descubrimiento y ejecución que se confunden fácilmente.

Para LCP de texto, investiga fuentes y visibilidad. Una fuente puede afectar la aparición del titular y sus métricas de reserva pueden alterar la disposición. Precargar todas las fuentes no es automáticamente la solución: compiten con recursos más urgentes.

Comprueba las variantes móviles y de contenido reales

Prueba un título largo y uno corto, un artículo con imagen principal y otro sin ella. Incluye consentimiento, publicidad e idioma reales cuando cambien la disposición visible. El código compartido puede producir candidatos LCP distintos según el contenido.

Una ventana estrecha puede recortar u ocultar la imagen de escritorio mientras el navegador sigue descargándola por una discrepancia entre HTML y estilos. Una imagen específica de móvil también puede pedirse tarde si un script la elige tras iniciar. Revisa solicitudes reales, no solo la página terminada.

En páginas localizadas, cobertura de fuentes y saltos de línea pueden cambiar candidato y dependencias de renderizado. Aplica el mismo diagnóstico a cada idioma, sin asumir que una mejora en inglés demuestra mejoras en todos.

Valida una hipótesis con una grabación comparable

Escribe la hipótesis antes de editar: por ejemplo, la imagen LCP se descubre tarde porque un componente la inserta después de inicializarse. Haz el cambio más pequeño que permita comprobarlo y repite el escenario.

Compara inicio de solicitud, final de transferencia, aparición y LCP total. Repite con la misma ventana, limitación de recursos y caché. Conserva fallos y errores visibles: una función importante que dejó de cargar puede producir una rapidez engañosa.

Tras desplegar, revisa datos reales durante su período de recopilación. El LCP de campo puede diferir por hardware, conexiones, geografía y navegación. La mejora de laboratorio es una prueba útil, pero no sustituye al resultado de campo.

Facilita el mantenimiento del resultado

Documenta qué elemento importa, cómo se descubre y qué optimización es deliberada. Una nota breve puede impedir que un plugin vuelva a activar carga diferida o que un rediseño cambie el espacio sin actualizar sizes.

Conserva el caso en la revisión: una página representativa, candidato previsto, descubrimiento esperado y traza guardada. Consulta las guías de referencia de Core Web Vitals cuando otra métrica limite la experiencia. La siguiente tarea debe surgir del siguiente retraso medido, no de otro ajuste genérico.