LCP lento: cómo encontrar el elemento responsable y corregir la cadena crítica

Lectura ejecutiva

Conclusiones principales

• El elemento de LCP puede cambiar entre dispositivos y visitas.
• Descompón el tiempo antes de elegir la corrección.
• Descubre el recurso pronto y prioriza solo el candidato correcto.
• No uses lazy-loading en el elemento visible que determina LCP.

Largest Contentful Paint mide cuándo termina de renderizarse el mayor elemento visible. Corregirlo exige más que “optimizar imágenes”: identifica el elemento medido y dónde se consume el tiempo.

El límite recomendado es 2,5 segundos en el percentil 75. Usa campo y laboratorio juntos: campo confirma alcance y laboratorio expone la cadena crítica.

Identifica el elemento de LCP

Puede ser imagen hero, imagen de carrusel, poster de video, bloque de texto, imagen de fondo compatible u otro elemento grande en el viewport inicial.

Puede cambiar entre mobile y desktop por layout, recorte, texto y recursos. También cambia con experimentos, consentimiento, personalización o fallos de carga.

Usa Performance de Chrome, PageSpeed Insights o atribución de web-vitals para registrar elemento y URL. No asumas que la imagen más llamativa fue el candidato.

Descompón el tiempo de LCP

Time to First Byte

Incluye navegación, conexión, procesamiento del servidor e inicio del documento. Si el HTML llega tarde, todos los recursos empiezan tarde.

Investiga redirecciones, caché, renderizado del servidor, consultas bloqueantes, distancia, cold starts y middleware.

Retraso de descubrimiento

Es el intervalo entre recibir HTML y descubrir el recurso. Crece si la imagen es insertada por JavaScript, depende de carrusel hidratado, aparece en CSS tardío o espera una API.

El mejor escenario incluye el candidato principal directamente en el HTML inicial.

Duración de transferencia

Después de descubrirse, el recurso debe descargarse. Peso, formato, dimensiones, caché, CDN y conexión afectan esta fase.

Retraso de renderizado

El archivo puede estar disponible y no aparecer porque CSS, fuentes, JavaScript o trabajo de la thread principal bloquean el paint. Comprimir más la imagen solo resuelve una parte pequeña.

Corrige el documento antes de acelerar el recurso

Un TTFB alto desplaza toda la cascada. Antes de añadir preload, elimina redirecciones de entrada, usa caché cuando corresponda, sirve contenido estático, acerca contenido con CDN, paraleliza datos independientes y pospone trabajo no necesario.

Mide efectos en actualización y personalización. Una caché incorrecta puede servir datos obsoletos o privados.

Haz que el navegador descubra pronto el candidato

Renderiza la primera imagen en HTML y usa srcset y sizes:

<img
  src="/hero-1280.webp"
  srcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
  sizes="100vw"
  width="1280"
  height="720"
  alt="Diagnóstico priorizado de un sitio"
  fetchpriority="high"
>

fetchpriority="high" puede ayudar, pero úsalo solo en el candidato probable. Muchas imágenes con prioridad alta eliminan el valor de la señal.

Para recursos descubiertos por CSS, preload puede servir. Confirma en waterfall que anticipa la solicitud y no crea descarga duplicada.

No uses lazy-loading en el LCP visible

loading="lazy" pospone recursos cercanos o fuera del viewport. En el candidato visible suele ser contraproducente.

Mantén lazy-loading debajo del fold. Prueba variaciones responsivas: una imagen inferior en desktop puede ser el LCP móvil.

Sirve el archivo correcto

Genera dimensiones cercanas al espacio renderizado, usa formatos modernos, comprime con revisión visual, evita descargar imagen desktop en pantallas pequeñas, configura caché duradera y elimina metadata innecesaria.

El objetivo no es el archivo más pequeño, sino equilibrar calidad, decodificación y transferencia.

Elimina bloqueos de renderizado

Si el candidato es texto, fuentes y CSS importan. Entrega estilos críticos pronto, evita hojas enormes y revisa fuentes.

Si JavaScript ocupa la thread cuando el recurso está listo, renderiza contenido en servidor, divide componentes no críticos, pospone terceros, evita hidratar áreas estáticas y reduce efectos iniciales.

Atención con carruseles

Los carruseles suelen esconder la primera imagen detrás de JavaScript y cargar todos los slides con prioridad similar.

Una implementación robusta renderiza el primer slide en HTML, prioriza solo su imagen, reserva dimensiones, carga los demás con menor prioridad, mantiene controles accesibles y no cambia el candidato antes de estabilizar.

Considera si el carrusel es necesario. Un único mensaje principal suele ser más simple.

Valida la corrección

Repite pruebas comparables y registra elemento, URL, TTFB, solicitud, renderizado, bytes y tareas largas. Prueba varias páginas del template. Después acompaña campo y negocio sin asumir causalidad inmediata.

Observación: en mobile, la imagen principal de producto es LCP y se descarga después de hidratar el carrusel. Acción: renderizar el primer slide en servidor con srcset, dimensiones y prioridad; cargar los demás bajo demanda. Aceptación: aparece sin JavaScript, no hay descarga duplicada y la mediana de cinco pruebas mejora.

LCP lento es una cadena, no un archivo. Descomponer el tiempo permite atacar el componente que realmente domina la experiencia.

Respuestas directas

Preguntas frecuentes

¿Cuál es un buen LCP?

La recomendación actual es LCP de hasta 2,5 segundos en el percentil 75, separado entre mobile y desktop.

¿Preload siempre mejora LCP?

No. Ayuda cuando el recurso crítico se descubriría tarde. Preloads excesivos compiten por banda y pueden empeorar otras solicitudes.

¿Comprimir una imagen resuelve LCP?

Solo cuando la transferencia domina el retraso. TTFB alto, descubrimiento tardío, CSS bloqueante o renderizado cliente pueden seguir dominando.