Corrige e identifica problemas del Largest Contentful Paint (LCP)

Esta guía es parte del hub de Largest Contentful Paint (LCP). El LCP mide qué tan rápido se renderiza el elemento visible más grande. Google exige menos de 2,5 segundos. A continuación detallo el proceso de diagnóstico exacto que utilizo en mis consultorías de velocidad de página.

Guía de un consultor para diagnosticar y corregir el LCP

Me llamo Arjen Karel y soy consultor de velocidad de página. A lo largo de los años he auditado cientos de sitios web. Uno de los problemas más persistentes es el Largest Contentful Paint (LCP). En esta guía comparto la metodología exacta que uso para diagnosticar y resolver problemas de LCP. Verás menciones a CoreDash, una herramienta RUM que creé para obtener los datos precisos que requiere este proceso. Estos principios son universales, pero prefiero mostrar ejemplos reales con las herramientas que construyo y utilizo a diario.

Mejorar el LCP es un proceso de eliminación. Según el Web Almanac de 2025, solo el 66% de los orígenes móviles aprueban el LCP. Esto significa que un tercio de la web tiene un problema de carga. Encuentra la fase más lenta, corrígela y vuelve a medir.

La metodología de diagnóstico: primero el field data, luego el lab data

Para optimizar de forma eficaz, debes adoptar un flujo de trabajo de diagnóstico en dos pasos. Así te aseguras de resolver problemas que tus usuarios enfrentan realmente, y no solo perseguir puntuaciones en un entorno de laboratorio.

1. El field data (RUM y CrUX) te muestra QUÉ está pasando. El field data se recopila de usuarios reales que visitan tu sitio. Te dice si tienes un problema de LCP, qué páginas están afectadas y qué usuarios (móvil o escritorio) lo están experimentando. Debes empezar siempre por aquí para confirmar que existe un problema real.
2. El lab data (Lighthouse, DevTools) te ayuda a diagnosticar POR QUÉ está pasando. El lab data se recopila en un entorno controlado y simulado. Una vez que tu field data confirma un problema en una página específica, puedes usar herramientas de laboratorio para replicar el problema de manera consistente y diseccionar el proceso de carga para encontrar la causa raíz.

Empieza con el field data para que tus esfuerzos de optimización se centren en cambios que impacten realmente a usuarios reales.

Paso 1: Identifica problemas de LCP con el field data

Tu primera tarea es usar datos de usuarios reales para confirmar qué páginas, si las hay, tienen un LCP deficiente.

Un punto de partida accesible: Google Search Console

Un lugar válido para empezar es el informe de Core Web Vitals en Google Search Console. Inicia sesión, navega al informe y revisa los gráficos de móvil y escritorio. Si Google está marcando URLs con "Problema de LCP: superior a 2,5 s", tienes la confirmación por parte del Chrome User Experience (CrUX) Report de que un porcentaje de tus usuarios está teniendo una mala experiencia.

Search Console confirma el problema, pero se actualiza lentamente y agrupa las URLs. Para tener un nivel de detalle por página en tiempo real, necesitas una herramienta RUM.

Real User Monitoring (RUM): detalle a nivel de página

Puedes construir tu propia configuración RUM usando la librería web-vitals para enviar datos a tu backend de analítica, pero eso supone un gran esfuerzo de ingeniería.

Creé CoreDash específicamente para esto. Añades una etiqueta script y empieza a recopilar datos de LCP de cada visitante real, desglosados por página, dispositivo y elemento.

Una buena herramienta RUM te permite ver:

• Tu puntuación LCP precisa para cualquier URL específica.
• Un desglose de cada elemento LCP (ej. una imagen, un titular) y cuáles se asocian con más frecuencia a un LCP lento.
• Los tiempos exactos de cada una de las cuatro fases del LCP para cada vista de página, localizando así el cuello de botella.

Mirar más allá del propio elemento LCP es importante. En un caso de estudio bien documentado, Vodafone mejoró su LCP en un 31%, lo que contribuyó directamente a un aumento del 8% en sus ventas. Su optimización se centró en identificar y resolver el cuello de botella específico del LCP en landing pages clave mediante una combinación de análisis de field data y correcciones dirigidas. La optimización del LCP no se trata solo de la imagen. Necesitas entender todo el pipeline de carga: respuesta del servidor, descubrimiento de recursos, descarga y renderizado.

Por ejemplo, en CoreDash, puedes ir a la página de LCP y ver una tabla de datos que muestra tus elementos LCP más lentos. Al hacer clic en un elemento específico (como una clase CSS en particular para una hero image), puedes filtrar todas las métricas para ver los datos de rendimiento solo de las páginas donde ese elemento fue el LCP.

El objetivo: usa el field data para encontrar tu página más lenta y su elemento LCP más común. Ese es tu objetivo.

Medición del LCP con la Performance Observer API

La Performance Observer API te da acceso directo a las entradas de LCP en JavaScript. Es la misma API que usan las herramientas RUM por debajo para recopilar field data. El siguiente fragmento registra cada candidato a LCP que identifica el navegador, incluyendo el elemento, su tamaño y el tiempo de renderizado.

const observer = new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];
  console.log('LCP element:', lastEntry.element);
  console.log('LCP time:', lastEntry.renderTime || lastEntry.loadTime);
  console.log('LCP size:', lastEntry.size);
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });

Esto es útil para una validación rápida durante el desarrollo, pero para la medición en producción deberías usar la librería web-vitals, que gestiona casos extremos como cambios de visibilidad de pestañas y restauraciones de la back/forward cache.

Paso 2: Diagnostica el cuello de botella con herramientas de laboratorio

Ya sabes qué página corregir. Ahora averigua por qué es lenta. Ejecuta una prueba con PageSpeed Insights o el panel de Lighthouse en Chrome DevTools.

En el informe, baja a la sección "Diagnósticos" y encuentra la auditoría "Elemento Largest Contentful Paint". Este gráfico de cascada desglosa tu tiempo de LCP en sus cuatro subpartes. Tu herramienta RUM debería mostrar un desglose similar basado en tu field data.

Tu objetivo es encontrar la fase más larga en este desglose. Ese es tu cuello de botella principal, y ahí es donde debes centrar tus esfuerzos de optimización primero.

Guía paso a paso: ¿prefieres trabajar en DevTools? Diagnosticar el LCP con el panel de Performance de Chrome DevTools muestra cómo registrar un trace con throttling y leer las mismas cuatro subpartes del desglose del LCP.

Paso 3: Entiende las cuatro fases del LCP

Cada puntuación de LCP es la suma de cuatro fases secuenciales. Cada fase tiene una guía dedicada en este sitio que cubre técnicas de optimización específicas.

• Time to First Byte (TTFB): Esta es la base ineludible. Una respuesta lenta del servidor es una suma directa, milisegundo a milisegundo, a tu LCP. Antes de optimizar una sola imagen, debes asegurarte de que tu servidor responda rápido. Aprende más sobre cómo optimizar el TTFB.
• Resource Load Delay: Este es el "problema de descubrimiento" y uno de los más comunes. El navegador no puede descargar un recurso que desconoce. Si tu imagen de LCP está oculta en un archivo CSS o JavaScript, o incluso si está en el HTML pero se solicitan otros recursos primero, el navegador la encuentra demasiado tarde, perdiendo un tiempo valioso. Lee la guía completa sobre Resource Load Delay.
• Resource Load Duration: Este es el tiempo de descarga del propio recurso LCP. Imágenes grandes sin comprimir o condiciones de red lentas pueden convertir esta fase en un cuello de botella. Lee la guía completa sobre Resource Load Duration.
• Element Render Delay: Este es el problema de "demasiado ocupado para pintar". El archivo de la imagen LCP puede estar totalmente descargado, pero si el main thread del navegador está bloqueado por una ejecución pesada de JavaScript, simplemente no puede pintar la imagen en la pantalla. Lee la guía completa sobre Element Render Delay.

Empieza siempre por asegurarte de que tu TTFB sea rápido y tu recurso LCP sea descubrible antes de pasar a optimizaciones de tamaño de archivo y renderizado.

Paso 4: Ejecuta la corrección

Con el cuello de botella identificado, aplica la solución. La implementación depende de tu stack. Cada fase a continuación cubre primero principios universales, y luego especificidades de WordPress y frameworks JS.

1. Optimización del Time to First Byte (TTFB)

Si tu TTFB es lento (un buen objetivo es menos de 800 ms), establece un piso alto para tu LCP. Mejorar el TTFB mejorará todas las demás métricas de carga.

Soluciones universales para el TTFB

• Habilita el caching: Esta es una de las formas más efectivas de mejorar el TTFB. El caching genera y almacena una copia de la página para que pueda servirse al instante sin esperar a que el servidor la construya desde cero en cada visita.
• Usa una CDN: Una Content Delivery Network sirve tu contenido desde un servidor físicamente cercano a tu usuario, lo cual reduce la latencia de red. Almacenar tus páginas HTML completas en el edge de la CDN es una estrategia potente para conseguir un TTFB global y rápido. Para consejos detallados de configuración de CDN, consulta nuestra guía sobre cómo configurar Cloudflare para un rendimiento óptimo.
• Usa compresión Brotli o Gzip: Asegúrate de que tu servidor comprima los recursos basados en texto como HTML, CSS y JavaScript. Brotli ofrece mejor compresión que Gzip y debería ser tu preferencia.
• Usa HTTP/3 con 0-RTT: Asegúrate de que tu servidor esté configurado para usar HTTP/3. Ofrece ventajas de rendimiento significativas, incluyendo mejor multiplexación. Soporta 0-RTT (Zero Round Trip Time Resumption), que elimina el tiempo de configuración de conexión para visitantes recurrentes, proporcionando una mejora instantánea del TTFB.
• Usa 103 Early Hints: Para una mejora avanzada, usa el código de estado 103 Early Hints. Esto permite a tu servidor o CDN enviar hints sobre archivos críticos de CSS y JS al navegador mientras aún está preparando el documento HTML completo, lo que permite que las descargas comiencen aún más pronto. Para una guía de implementación completa, mira nuestro artículo sobre 103 Early Hints.

Correcciones de TTFB por plataforma

En WordPress:

• Invierte en hosting de calidad: En WordPress, un TTFB lento suele estar relacionado con el entorno de hosting. El hosting compartido barato puede ser un cuello de botella. Considera un hosting administrado de WordPress optimizado para rendimiento.
• Usa un plugin de caché: Un plugin de caché de alta calidad (ej. WP Rocket, W3 Total Cache) es innegociable. Gestiona la generación de archivos HTML estáticos por ti, que es el núcleo de un caching efectivo en esta plataforma.

En un framework JS:

• Elige la plataforma de hosting correcta: Para aplicaciones Node.js, plataformas como Vercel o Netlify están muy optimizadas para frameworks SSR/SSG y ofrecen caching inteligente y ejecución de funciones serverless de fábrica.
• Implementa SSR caching: Si usas Server-Side Rendering, cachea las páginas renderizadas en el servidor (ej. usando Redis o una caché en memoria) para evitar volver a renderizar en cada petición.
• Cuidado con los cold starts serverless: Si usas funciones serverless para renderizar, ten en cuenta que un "cold start" (la primera petición tras un periodo de inactividad) puede tener un alto TTFB. Usa concurrencia provisionada o estrategias keep-alive para mitigar esto.

2. Reducción del Resource Load Delay

Este suele ser el mayor cuello de botella. Significa que el navegador estaba listo para trabajar, pero no pudo encontrar tu imagen o archivo de fuente principal de inmediato. Este retraso lo causa típicamente uno de dos problemas: el recurso se descubre tarde, o se le asigna una baja prioridad de descarga. Para la guía completa sobre este tema, lee nuestra guía dedicada al Resource Load Delay.

Soluciones universales para el Load Delay

La solución universal al Resource Load Delay es asegurar que tu recurso LCP sea descubrible en el marcado HTML inicial y que el navegador le dé alta prioridad. Así es como se logra:

• Haz que el recurso LCP sea descubrible: El paso más importante es asegurar que tu elemento LCP esté presente en el HTML que envía el servidor. Los navegadores usan un "preload scanner" de alta velocidad para adelantarse en el HTML crudo buscando recursos como imágenes y scripts que descargar. Si tu imagen de LCP se carga mediante una background-image de CSS o se inyecta con JavaScript, es invisible para este escáner, lo que causa un gran retraso. La solución más robusta es usar siempre una etiqueta <img> estándar con un atributo src en tu HTML renderizado en el servidor.
• Controla el orden de carga con preload: Si no puedes hacer que el recurso LCP sea directamente descubrible (un problema común con fuentes o imágenes de fondo CSS), la siguiente mejor solución es usar <link rel="preload">. Esta etiqueta actúa como una instrucción explícita en el <head> de tu HTML, diciéndole al navegador que empiece a descargar un recurso crítico mucho antes de lo que lo habría encontrado naturalmente. Para detalles de implementación y ejemplos, consulta nuestra guía sobre cómo precargar la imagen LCP.
• Asegura alta prioridad con fetchpriority: Incluso cuando un recurso es descubrible, el navegador podría no darle la prioridad de descarga más alta. Añadir fetchpriority="high" a tu etiqueta <img> o a tu etiqueta <link rel="preload"> es un hint muy potente para el navegador de que este recurso específico es el más importante para la experiencia del usuario, ayudándole a ganar la carrera por el ancho de banda frente a otros recursos.

Correcciones de Load Delay por plataforma

En WordPress:

• Evita las imágenes de fondo en los page builders: Muchos page builders facilitan configurar una hero image como background-image de CSS en un div. Esto la hace invisible para el preload scanner del navegador. Si es posible, usa un bloque <img> estándar en su lugar. Si no, podrías necesitar un plugin o código personalizado para precargar esa imagen específica.
• Desactiva el lazy loading para la imagen LCP: Muchos plugins de optimización aplicarán lazy loading a todas las imágenes automáticamente. Debes encontrar la configuración en tu plugin para excluir la imagen LCP (y a menudo las primeras imágenes de la página) del lazy loading. Este es un error tan común que tenemos un artículo dedicado a corregir imágenes LCP con lazy loading.

En un framework JS:

• Usa Server-Side Rendering (SSR): Esta suele ser la corrección más impactante. Una app de React renderizada en el cliente (CSR) por defecto envía un HTML mínimo, y el elemento LCP solo existe después de que se descarga y ejecuta un gran bundle JS. Los frameworks SSR como Next.js o Remix entregan el HTML completo, incluyendo la etiqueta <img>, para que el navegador pueda descubrirlo de inmediato.
• Usa componentes de imagen específicos del framework: Frameworks como Next.js ofrecen un componente de imagen con una prop priority. Usar la prop priority aplica automáticamente fetchpriority="high" y otras optimizaciones a tu imagen LCP.

3. Reducción del Resource Load Duration

Asegurar que tu recurso LCP sea lo más pequeño posible sigue siendo una parte esencial del proceso. Esta fase trata sobre cuánto tarda en descargarse el archivo del recurso LCP a través de la red. Para una guía completa sobre técnicas de optimización de imágenes, consulta nuestro artículo sobre cómo optimizar la imagen LCP, y para más detalles sobre Resource Load Duration en particular.

Soluciones universales para el tiempo de carga

• Reduce el tamaño del archivo con formatos modernos e imágenes responsivas: La forma más directa de acortar el tiempo de descarga es hacer el archivo más pequeño. Para imágenes, esto significa usar formatos modernos y muy eficientes como AVIF o WebP. También debes servir imágenes responsivas usando el elemento <picture> o los atributos srcset y sizes. Esto asegura que un usuario en un dispositivo móvil reciba una imagen con el tamaño adecuado para su pantalla más pequeña, en lugar de verse obligado a descargar una imagen enorme diseñada para escritorio. Una pantalla móvil de 400 píxeles de ancho simplemente no necesita un archivo de imagen de 2000 píxeles de ancho. Para LCPs basados en texto, asegúrate de que tus fuentes estén en el formato eficiente WOFF2 y usen subsetting para eliminar caracteres no utilizados.
• Reduce la contención de red: El recurso LCP tiene que competir por el limitado ancho de banda de la red del usuario. Diferir recursos no críticos, como scripts de analítica o CSS para el contenido below-the-fold, libera ancho de banda para que el navegador se enfoque en descargar el recurso LCP más rápido.
• Aloja los recursos críticos en tu dominio principal: Evita cargar tu recurso LCP desde un dominio diferente si es posible. Configurar una nueva conexión a otro servidor añade resoluciones DNS y handshakes que consumen tiempo.

Correcciones de tiempo de carga por plataforma

En WordPress:

• Usa un plugin de optimización de imágenes: Herramientas como ShortPixel o Smush pueden comprimir imágenes automáticamente al subirlas, convertirlas a formatos modernos como WebP/AVIF y generar tamaños responsivos para el srcset.
• Redimensiona imágenes manualmente: Antes de subir, redimensiona tus imágenes para que no sean más grandes de lo necesario. No subas una imagen de 4000 px de ancho para un espacio que solo tiene 1200 px de ancho en las pantallas más grandes.

En un framework JS:

• Usa una CDN de imágenes: Esta es una solución potente. Servicios como Cloudinary, Imgix, o el Image & Video Manager de Akamai pueden automatizar todo el proceso de optimización. Subes una imagen de alta calidad, y ellos entregan una versión perfectamente dimensionada, comprimida y formateada a cada usuario a través de una CDN rápida.
• Aprovecha las build tools: Cuando importas una imagen en un componente en un framework moderno, la build tool (como Webpack o Vite) puede hashear y optimizar el archivo automáticamente como parte del proceso de build.

4. Acortamiento del Element Render Delay

El recurso ha terminado de descargarse, pero aún no está en la pantalla. Esto significa que el main thread del navegador está ocupado con otras tareas y no puede pintar el elemento. Este es otro cuello de botella muy común y significativo. Para la guía completa, lee nuestra guía sobre Element Render Delay.

Soluciones universales para el Render Delay

• Difiere o elimina el JavaScript no utilizado: Cualquier JS que no sea esencial para renderizar la parte inicial y visible de la página debería diferirse usando los atributos defer o async.
• Usa Critical CSS: Una hoja de estilos grande y render blocking puede retrasar el renderizado. La técnica del critical CSS implica extraer el CSS mínimo necesario para dar estilo al contenido above-the-fold, colocarlo inline en el <head> y cargar el resto de estilos de forma asíncrona.
• Divide las long tasks: Un script de larga duración puede bloquear el main thread por un periodo prolongado, impidiendo el renderizado. Esta es también una causa principal de un mal Interaction to Next Paint (INP). Divide tu código en fragmentos asíncronos más pequeños que hagan yield de vuelta al main thread.

Correcciones de Render Delay por plataforma

En WordPress:

• Audita tus plugins: Demasiados plugins, especialmente los pesados como sliders o page builders complejos, pueden añadir un CSS y JS significativo que bloquea el main thread. Desactiva los plugins uno a uno para identificar cuáles devoran el rendimiento.
• Usa un tema ligero: Un tema hinchado con docenas de características que no usas puede ser una gran fuente de código render blocking. Elige un tema centrado en el rendimiento.
• Usa gestores de assets para plugins: Herramientas como Asset CleanUp o Perfmatters te permiten desactivar de manera condicional el CSS y JS de plugins específicos en páginas donde no son necesarios.

En un framework JS:

• El code splitting es clave: No envíes todo el JavaScript de tu app en un solo bundle gigante. Divide tu código por ruta (para que los usuarios solo descarguen el código de la página que están visitando) y por componente.
• Aplica lazy loading a los componentes: Usa React.lazy y Suspense para aplicar lazy loading a los componentes que no son visibles de inmediato (ej. componentes below-the-fold o en modales). Esto los mantiene fuera del bundle inicial.

Avanzado: Optimización del LCP para navegaciones posteriores

Corregir el LCP inicial es importante, pero puedes hacer que la navegación por tu sitio se sienta instantánea si optimizas las cargas de página posteriores.

Asegura que las páginas sean elegibles para la Back/Forward Cache (bfcache)

La bfcache es una optimización del navegador que almacena una instantánea completa de una página en memoria cuando un usuario navega fuera de ella. Si hace clic en el botón de atrás, la página se puede restaurar al instante, resultando en un LCP cercano a cero. Muchas páginas no son elegibles para esta caché debido a elementos como los event listeners de unload. Usa la auditoría "bfcache" de Lighthouse para probar tus páginas y eliminar cualquier característica bloqueante.

Usa la Speculation Rules API para prerenderizado

La Speculation Rules API te permite decirle declarativamente al navegador a qué páginas es probable que navegue un usuario a continuación. Luego, el navegador puede recuperar y prerenderizar estas páginas en segundo plano. Cuando el usuario hace clic en un enlace hacia una página prerenderizada, la navegación es instantánea, logrando un LCP cercano a cero. Puedes definir estas reglas en una etiqueta <script type="speculationrules"> dentro de tu HTML.

<script type="speculationrules">
 {
  "prerender": [{
   "source": "document",
   "where": {
    "href_matches": "/products/*"
   },
   "eagerness": "moderate"
  }]
 }
 </script>  

Este ejemplo le dice al navegador que busque en la página actual los enlaces que dirigen a páginas de productos y que empiece a prerenderizarlos cuando un usuario pasa el ratón por encima del enlace.

Avanza por las cuatro fases en orden. Corrige primero el cuello de botella más grande, vuelve a medir y repite.

Siguientes pasos: Cada fase del LCP en detalle

Cada fase del LCP tiene su propia guía:

• Optimiza la imagen LCP: Una guía completa para la selección de formatos de imagen, imágenes responsivas, precarga y errores comunes de optimización de imágenes.
• Resource Load Delay: Cómo asegurar que el navegador descubra tu recurso LCP lo antes posible usando preload, fetchpriority y la estructura HTML adecuada.
• Resource Load Duration: Cómo reducir el tiempo de descarga para tu recurso LCP mediante compresión de archivos, formatos modernos, configuración de CDN y optimización de red.
• Element Render Delay: Cómo despejar el main thread del navegador para que pueda pintar el elemento LCP inmediatamente tras la descarga, cubriendo el CSS crítico, el diferimiento de JavaScript y content-visibility.