Solucionar e Identificar Problemas de Largest Contentful Paint (LCP)

Esta guía forma parte del centro de recursos sobre Largest Contentful Paint (LCP). El LCP mide qué tan rápido se renderiza el elemento visible más grande. Google quiere que esté por debajo de 2,5 segundos. A continuación se detalla el proceso de diagnóstico exacto que utilizo cuando ofrezco consultoría sobre velocidad de página.

Guía de un Consultor para Diagnosticar y Solucionar el LCP

Mi nombre es Arjen Karel y soy consultor de velocidad de página. A lo largo de los años, he auditado cientos de sitios web, y uno de los desafíos más persistentes es el Largest Contentful Paint (LCP). En esta guía, compartiré la metodología exacta que utilizo para diagnosticar y resolver problemas de LCP. Verás menciones a CoreDash, una herramienta RUM que creé para obtener los datos precisos necesarios para este proceso. Los principios aquí son universales, pero creo en mostrar ejemplos reales de 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. Eso significa que un tercio de la web tiene un problema de carga. Encuentra la fase más lenta, soluciónala y vuelve a medir.

La Metodología de Diagnóstico: Datos de Campo Primero, Datos de Laboratorio Después

Para optimizar de manera efectiva, debes adoptar un flujo de trabajo de diagnóstico en dos pasos. Esto garantiza que estés resolviendo problemas a los que tus usuarios se enfrentan realmente, no solo persiguiendo puntuaciones en un entorno de laboratorio.

1. Los Datos de Campo (RUM y CrUX) te muestran QUÉ está sucediendo. Los datos de campo se recopilan de usuarios reales que visitan tu sitio. Te indican si tienes un problema de LCP, qué páginas están afectadas y qué usuarios (móviles o de escritorio) lo están experimentando. Siempre debes comenzar aquí para confirmar que existe un problema real.
2. Los Datos de Laboratorio (Lighthouse, DevTools) te ayudan a diagnosticar POR QUÉ está sucediendo. Los datos de laboratorio se recopilan en un entorno controlado y simulado. Una vez que tus datos de campo han confirmado un problema en una página específica, puedes usar herramientas de laboratorio para replicar de manera consistente el problema y desglosar el proceso de carga para encontrar la causa raíz.

Comienza con los datos de campo para que tus esfuerzos de optimización se centren en cambios que realmente impacten a los usuarios reales.

Paso 1: Identifica Problemas de LCP con Datos de Campo

Tu primera tarea es utilizar 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 comenzar es el informe de Core Web Vitals en Google Search Console. Inicia sesión, navega hasta el informe y revisa los gráficos para móviles y escritorio. Si Google marca URLs con el "Problema de LCP: más de 2,5s", tienes confirmación del Informe de Experiencia de Usuario de Chrome (CrUX) 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 detalles a nivel de página en tiempo real, necesitas una herramienta RUM.

Real User Monitoring (RUM): Detalles a Nivel de Página

Puedes construir tu propia configuración RUM usando la biblioteca web-vitals para enviar datos a tu backend de análisis, pero eso supone un esfuerzo de ingeniería considerable.

Creé CoreDash específicamente para esto. Añades una etiqueta de script y comienza 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 (por ejemplo, una imagen, un titular) y cuáles están asociados con mayor frecuencia a un LCP lento.
• El tiempo exacto para cada una de las cuatro fases de LCP para cada visita a la página, identificando 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 páginas de destino clave utilizando una combinación de análisis de datos de campo y soluciones específicas. La optimización del LCP no se trata solo de la imagen. Debes entender todo el flujo de carga: la respuesta del servidor, el descubrimiento de recursos, la descarga y el renderizado (paint).

Por ejemplo, en CoreDash, puedes navegar 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 concreta 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: usar los datos de campo 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 API Performance Observer

La API Performance Observer te da acceso directo a las entradas de LCP en JavaScript. Esta es la misma API que las herramientas RUM usan internamente para recopilar datos de campo. El siguiente fragmento de código registra cada candidato a LCP que el navegador identifica, 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('Elemento LCP:', lastEntry.element);
  console.log('Tiempo LCP:', lastEntry.renderTime || lastEntry.loadTime);
  console.log('Tamaño LCP:', lastEntry.size);
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });

Esto es útil para validaciones rápidas durante el desarrollo, pero para la medición en producción deberías usar la biblioteca web-vitals, que maneja casos límite como los cambios en la visibilidad de la pestaña y la restauración desde la bfcache (back/forward cache).

Paso 2: Diagnostica el Cuello de Botella con Herramientas de Laboratorio

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

En el informe, desplázate hasta la sección "Diagnósticos" (Diagnostics) y busca la auditoría "Elemento Largest Contentful Paint". Este gráfico de cascada desglosa tu tiempo de LCP en sus cuatro sub-partes. Tu herramienta RUM debería mostrar un desglose similar basado en tus datos de campo.

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

Paso 3: Entendiendo las Cuatro Fases del LCP

Cada puntuación 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ápidamente. Aprende más sobre la optimización del TTFB.
• Resource Load Delay: Este es el "problema de descubrimiento" y uno de los problemas más comunes. El navegador no puede descargar un recurso que no conoce. Si tu imagen 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 recurso LCP en sí. Las imágenes grandes y sin comprimir o las condiciones lentas de la red pueden hacer que esta fase sea un cuello de botella. Lee la guía completa sobre Resource Load Duration.
• Element Render Delay: Este es el problema de estar "demasiado ocupado para pintar". El archivo de imagen LCP puede estar completamente descargado, pero si el hilo principal (main thread) del navegador está bloqueado por una fuerte ejecución de JavaScript, simplemente no podrá dibujar la imagen en la pantalla. Lee la guía completa sobre Element Render Delay.

Comienza siempre asegurándote de que tu TTFB sea rápido y tu recurso LCP sea detectable antes de pasar a las optimizaciones de tamaño de archivo y renderizado.

Paso 4: Ejecuta la Corrección

Una vez identificado el cuello de botella, aplica la solución. La implementación depende de tu stack tecnológico. A continuación, cada fase abarca primero los principios universales y después las particularidades para WordPress y los frameworks de JS.

1. Optimizar el Time to First Byte (TTFB)

Si tu TTFB es lento (un buen objetivo es menos de 800ms), establece un nivel base muy alto para tu LCP. Mejorar el TTFB mejorará cualquier otra métrica de carga.

Soluciones Universales para el TTFB

• Habilitar el Almacenamiento en Caché (Caching): Esta es una de las maneras más eficaces de mejorar el TTFB. El almacenamiento en caché genera y guarda una copia de la página para poder servirla de manera instantánea, sin tener que esperar a que el servidor la genere desde cero en cada visita.
• Usar una CDN: Una Red de Distribución de Contenido (CDN) entrega tu contenido desde un servidor físicamente cercano a tu usuario, lo que reduce la latencia de la red. Almacenar en caché tus páginas HTML completas en el edge de la CDN es una estrategia poderosa para obtener un TTFB rápido a nivel global. Para obtener consejos detallados sobre la configuración de una CDN, consulta nuestra guía sobre cómo configurar Cloudflare para un rendimiento óptimo.
• Usar Compresión Brotli o Gzip: Asegúrate de que tu servidor esté comprimiendo los archivos basados en texto como el HTML, el CSS y el JavaScript. Brotli ofrece una mejor compresión que Gzip y debería preferirse.
• Usar HTTP/3 con 0-RTT: Asegúrate de que tu servidor esté configurado para utilizar HTTP/3. Ofrece importantes ventajas de rendimiento, incluyendo una mejor multiplexación. Soporta 0-RTT (Zero Round Trip Time Resumption), lo que elimina el tiempo de establecimiento de la conexión para los visitantes recurrentes, proporcionando un impulso instantáneo al TTFB.
• Usar 103 Early Hints: Para un impulso avanzado, utiliza el código de estado 103 Early Hints. Esto permite a tu servidor o a tu CDN enviar pistas (hints) sobre el CSS y JS críticos al navegador mientras todavía está preparando el documento HTML completo, lo que permite que las descargas comiencen aún más pronto. Para obtener una guía de implementación completa, consulta nuestro artículo sobre 103 Early Hints.

Soluciones de TTFB Específicas por Plataforma

En WordPress:

• Invierte en Hosting de Calidad: En WordPress, un TTFB lento a menudo está relacionado con el entorno de alojamiento. El alojamiento compartido barato puede ser un cuello de botella. Considera un host de WordPress administrado que esté optimizado para el rendimiento.
• Usa un Plugin de Caché: Un plugin de caché de alta calidad (por ejemplo, WP Rocket, W3 Total Cache) es innegociable. Se encarga de la generación de archivos HTML estáticos por ti, lo cual es el núcleo de un almacenamiento en caché eficaz en esta plataforma.

En un Framework de JS:

• Elige la Plataforma de Hosting Adecuada: Para aplicaciones Node.js, plataformas como Vercel o Netlify están altamente optimizadas para frameworks SSR/SSG y ofrecen almacenamiento en caché inteligente y ejecución de funciones serverless desde el primer momento.
• Implementar Caché SSR: Si utilizas el Renderizado del Lado del Servidor (SSR), almacena en caché las páginas renderizadas en el servidor (por ejemplo, usando Redis o un caché en memoria) para evitar volver a renderizar en cada petición.
• Cuidado con los Inicios en Frío (Cold Starts) de Serverless: Si utilizas funciones sin servidor para el renderizado, ten en cuenta que un "inicio en frío" (la primera solicitud tras un periodo de inactividad) puede tener un TTFB elevado. Utiliza estrategias de concurrencia aprovisionada o keep-alive para mitigarlo.

2. Reducir el Resource Load Delay

A menudo, este es el mayor cuello de botella. Significa que el navegador estaba listo para trabajar, pero no pudo encontrar tu imagen principal o archivo de fuente de inmediato. Este retraso se suele deber a uno de estos 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 sobre el Resource Load Delay.

Soluciones Universales para el Load Delay

La solución universal para el Resource Load Delay es garantizar que tu recurso LCP sea detectable en el HTML inicial y que el navegador le otorgue una alta prioridad. A continuación te explicamos cómo lograrlo:

• Haz que el Recurso LCP sea Detectable: El paso más importante es asegurarte de que tu elemento LCP esté presente en el HTML que envía el servidor. Los navegadores utilizan un "escáner de precarga" de alta velocidad para buscar en el HTML recursos como imágenes y scripts para descargar. Si tu imagen LCP se carga a través de un background-image CSS o se inyecta con JavaScript, es invisible para este escáner, lo que provoca un retraso importante. La solución más robusta es usar siempre una etiqueta <img> estándar con un atributo src en tu HTML renderizado por el servidor.
• Controla el Orden de Carga con preload: Si no puedes hacer que el recurso LCP sea directamente detectable (un problema común con las fuentes o las imágenes de fondo en CSS), la siguiente mejor solución es usar <link rel="preload">. Esta etiqueta actúa como una instrucción explícita en tu <head> HTML, indicándole al navegador que empiece a descargar un recurso crítico mucho antes de lo que lo habría encontrado de forma natural. 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 detectable, es posible que el navegador no le dé la máxima prioridad de descarga. Añadir fetchpriority="high" a tu etiqueta <img> o a tu etiqueta <link rel="preload"> es una instrucción fuerte 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.

Soluciones de Load Delay Específicas por Plataforma

En WordPress:

• Evita las Imágenes de Fondo (Background Images) de los Page Builders: Muchos constructores de páginas facilitan el establecer una imagen hero como background-image CSS en un div. Esto la hace invisible para el escáner de precarga del navegador. Si es posible, utiliza un bloque de <img> estándar en su lugar. De lo contrario, es posible que necesites un plugin o código personalizado para precargar esa imagen en concreto.
• Desactiva el Lazy-Loading para la Imagen LCP: Muchos plugins de optimización aplicarán automáticamente lazy-load a todas las imágenes. Debes localizar el ajuste de tu plugin para excluir la imagen LCP (y a menudo las primeras imágenes de la página) de la carga diferida. Este es un error tan habitual que tenemos un artículo específico sobre cómo solucionar el lazy-load en las imágenes LCP.

En un Framework de JS:

• Usa el Renderizado del Lado del Servidor (SSR): Ésta es a menudo la solución más eficaz. Una aplicación React por defecto Client-Side Rendered (CSR) envía un HTML mínimo, y el elemento LCP no existe hasta que no se descarga y ejecuta un gran paquete de JS. Los frameworks de SSR como Next.js o Remix entregan el HTML completo, incluyendo la etiqueta <img>, de tal forma que el navegador pueda localizarla en el acto.
• Usar Componentes de Imagen Específicos del Framework: Frameworks como Next.js ofrecen un componente de imagen con una propiedad (prop) priority. Utilizar esta propiedad aplica automáticamente fetchpriority="high" y otras optimizaciones a tu imagen LCP.

3. Reducir el Resource Load Duration

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

Soluciones Universales para el Load Time

• Reduce el Tamaño de Archivo con Formatos Modernos e Imágenes Responsivas: La manera más directa de acortar el tiempo de descarga es reduciendo el tamaño del archivo. En el caso de las imágenes, esto significa emplear formatos modernos de alta eficiencia como AVIF o WebP. Además, es preciso servir imágenes adaptables (responsivas) utilizando el elemento <picture> o los atributos srcset y sizes. Esto garantiza que un usuario de un dispositivo móvil reciba una imagen del tamaño adecuado para su pequeña pantalla, en vez de verse obligado a descargar un enorme archivo pensado para equipos de escritorio. Una pantalla de móvil de 400 píxeles de ancho sencillamente no precisa un archivo de imagen de 2000 píxeles de anchura. Para LCP basados en texto, asegúrate de que tus fuentes estén en el formato optimizado WOFF2 y sean reducidas a un subconjunto (subsetted) para deshacerse de los caracteres no usados.
• Reduce la Contención de Red: El recurso LCP ha de competir por el ancho de banda limitado de la red del usuario. Retrasar recursos no fundamentales, tales como los scripts de analítica o el CSS de contenido below-the-fold (debajo del pliegue), libera ancho de banda y permite al navegador concentrarse en descargar primero el recurso LCP.
• Aloja los Recursos Críticos en tu Dominio Principal: Evita cargar tu recurso LCP desde un dominio distinto si es posible. Establecer otra conexión con un nuevo servidor supone añadir tiempo de búsquedas DNS y handshakes.

Soluciones de Load Time Específicas por Plataforma

En WordPress:

• Usa un Plugin de Optimización de Imágenes: Herramientas como ShortPixel o Smush comprimen automáticamente las imágenes al subirlas, las transforman en formatos modernos tipo WebP/AVIF, a la par que generan distintos tamaños srcset responsivos.
• Redimensiona las Imágenes Manualmente: Antes de cargarlas, ajusta el tamaño de tus imágenes de modo que no sean mayores de lo necesario. No subas una imagen de 4000 píxeles para un espacio que solo tiene 1200 píxeles de anchura en las pantallas más grandes.

En un Framework de JS:

• Usa una CDN de Imágenes: Se trata de una solución muy eficaz. Servicios como Cloudinary, Imgix o Image & Video Manager de Akamai permiten automatizar el proceso íntegro de optimización. Subes una imagen original de alta calidad, y el sistema se encarga de ofrecer una versión adaptada en tamaño, comprimida y con el mejor formato a través de una veloz CDN.
• Saca Partido a las Build Tools: Al importar una imagen a un componente en un framework moderno, la propia herramienta de construcción (como Webpack o Vite) puede aplicar un hash y optimizar el archivo de manera automática durante el proceso de build.

4. Acortar el Element Render Delay

El recurso ya se ha descargado, pero aún no está en la pantalla. Esto significa que el hilo principal (main thread) del navegador está ocupado con otras tareas y no puede pintar el elemento. Se trata de otro problema muy común y significativo. Para la guía completa, lee nuestra guía sobre el 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 posponerse usando los atributos defer o async.
• Usa CSS Crítico (Critical CSS): Una hoja de estilos grande que bloquea la renderización puede retrasar el dibujado de la página. La técnica del CSS crítico consiste en extraer el CSS mínimo necesario para dar estilo al contenido above-the-fold, colocarlo inline en el <head> y cargar el resto de los estilos de forma asíncrona.
• Divide las Tareas Largas (Long Tasks): Un script de larga duración puede bloquear el hilo principal durante un período prolongado, impidiendo el renderizado. Esta es también una de las causas principales de un mal Interaction to Next Paint (INP). Divide tu código en fragmentos más pequeños y asíncronos que devuelvan el control al hilo principal.

Soluciones de Render Delay Específicas por Plataforma

En WordPress:

• Audita tus Plugins: Demasiados plugins, especialmente los pesados como sliders o page builders complejos, pueden añadir una gran cantidad de CSS y JS que bloquean el hilo principal. Desactiva los plugins uno por uno para identificar los que consumen más rendimiento.
• Emplea un Tema Ligero: Un tema sobrecargado con docenas de funciones que no usas puede ser una fuente importante de código que bloquea la renderización. Elige un tema centrado en el rendimiento.
• Usa Administradores de Activos de Plugins (Plugin Asset Managers): Herramientas como Asset CleanUp o Perfmatters te permiten desactivar condicionalmente CSS y JS de plugins específicos en páginas donde no se necesitan.

En un Framework de JS:

• El Code Splitting es Clave: No envíes todo el JavaScript de tu aplicación en un solo paquete 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.
• Carga Lenta de Componentes (Lazy Load): Utiliza React.lazy y Suspense para cargar de forma diferida los componentes que no son visibles de inmediato (por ejemplo, componentes below the fold o modales). Esto los mantiene fuera del paquete inicial.

Avanzado: Optimizar el LCP para Navegaciones Posteriores

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

Asegura que las Páginas sean Elegibles para la bfcache (Back/Forward Cache)

La bfcache es una optimización del navegador que almacena una instantánea completa de una página en la memoria cuando el usuario navega a otra. Si hacen clic en el botón de retroceso (back), la página se puede restaurar al instante, lo que resulta en un LCP cercano a cero. Muchas páginas no son elegibles para esta caché debido a cosas como los event listeners unload. Utiliza la auditoría "bfcache" de Lighthouse para probar tus páginas y eliminar cualquier función de bloqueo.

Usa la API de Speculation Rules para el Prerenderizado

La API de Speculation Rules te permite indicar de forma declarativa al navegador a qué páginas es probable que un usuario navegue a continuación. El navegador puede entonces obtener y pre-renderizar estas páginas en segundo plano. Cuando el usuario hace clic en un enlace a una página pre-renderizada, la navegación es instantánea, lo que lleva a un LCP cercano a cero. Puedes definir estas reglas en una etiqueta <script type="speculationrules"> en tu HTML.

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

Este ejemplo le dice al navegador que busque los enlaces en la página actual que van a las páginas de productos y que comience a pre-renderizarlos cuando un usuario pasa el ratón sobre el enlace (hover).

Trabaja en las cuatro fases en orden. Repara el mayor cuello de botella primero, vuelve a medir y repite el proceso.

Pasos Siguientes: Cada Fase de LCP en Detalle

Cada fase del LCP tiene su propia guía:

• Optimizar la Imagen LCP: Una guía completa sobre la selección del formato de imagen, imágenes responsivas, precarga (preloading) y errores comunes de optimización de imágenes.
• Resource Load Delay: Cómo garantizar que el navegador descubra tu recurso LCP lo antes posible mediante preload, fetchpriority y una estructura HTML adecuada.
• Resource Load Duration: Cómo reducir el tiempo de descarga de tu recurso LCP mediante la compresión de archivos, formatos modernos, configuración de CDN y optimización de red.
• Element Render Delay: Cómo despejar el hilo principal del navegador para que pueda pintar el elemento LCP inmediatamente después de la descarga, cubriendo el CSS crítico, el diferimiento de JavaScript y content-visibility.