Renderizado del contenido visible más grande (LCP)

TL;DR — La mayor pintura de contenido (LCP) mide cuánto tiempo tarda en aparecer el elemento más grande en pantalla — normalmente una imagen principal o un gran bloque de texto — después de que alguien hace clic en tu página. Menos de 2,5 segundos es bueno. Es una de las tres Core Web Vitals de Google, y es la que más problemas causa a la mayoría de los sitios.

Qué es LCP

La primera impresión que la gente tiene de tu sitio es lo rápido que parece cargar. LCP intenta poner un número a eso. Mide la cantidad de tiempo que tarda en cargar el elemento visible más grande en el viewport — la parte de la página que puedes ver sin desplazarte.

Ese “elemento más grande” suele ser una de dos cosas:

• Una imagen grande — un banner principal, una foto de producto, una imagen destacada.
• Un gran bloque de texto — común en páginas de artículos que no comienzan con una imagen.

LCP es el momento en que ese elemento termina de renderizarse, medido desde que la página empezó a cargar. Cuanto menor sea el número, más rápida se siente tu página.

La puntuación

Google clasifica LCP en tres categorías:

• Bueno: 2,5 segundos o menos
• Necesita mejoras: de 2,5 a 4 segundos
• Pobre: más de 4 segundos

Tu objetivo es esa marca de 2,5 segundos. Y se evalúa con visitantes reales de tu sitio, no con una prueba que ejecutas una vez — así que es la experiencia que tu audiencia real obtiene en sus teléfonos y conexiones reales.

Por qué puede ser difícil

LCP es la Core Web Vital con la que la gente tiene más problemas. Eso se debe a que tiene la mayor cantidad de partes móviles: tu servidor tiene que responder, el navegador tiene que encontrar y descargar la imagen, y luego tiene que pintarla. Una ralentización en cualquiera de esos pasos arrastra todo el número hacia arriba. Comprimir tus imágenes es una primera suposición común — y a veces ayuda — pero a menudo no es el verdadero cuello de botella.

También es más difícil en móvil que en escritorio, porque los teléfonos tienen conexiones más lentas y menos potencia de procesamiento.

Qué hacer primero

Tres victorias rápidas que corrigen los errores más comunes:

1. No hagas lazy-load de tu imagen principal. El “lazy loading” le dice al navegador que espere antes de obtener una imagen. Eso es genial para cosas que están más abajo en la página — pero si lo haces con tu imagen principal, estás retrasando deliberadamente lo más importante en pantalla. Evidence for this claim An LCP image should not be lazy-loaded, and reducing resource load delay is a primary LCP optimization. Scope: web.dev guidance for image-based LCP elements. Confidence: high · Verified: 2026-07-14 web.dev: Optimize LCP
2. Dile al navegador que la imagen principal es importante — hay un atributo (fetchpriority="high") que hace exactamente eso. Ponlo en la única imagen que sea realmente tu candidata a LCP; ponerlo en varias imágenes diluye la señal.
3. Acelera tu servidor. Si tu servidor tarda en responder, nada más que hagas importa mucho.

¿Quieres el modelo mental completo — las cuatro subpartes de LCP, cómo encontrar tu elemento LCP, lo relacionado con el renderizado y las fuentes, y cuánto importa esto realmente para los rankings? Cambia a la pestaña Avanzado.

TL;DR — LCP es el tiempo de renderizado del elemento más grande (imagen o bloque de texto) visible en el viewport, relativo a cuando la página empezó a cargar. Bueno es ≤ 2,5 s en el percentil 75 de usuarios reales (dividido por dispositivo); 2,5–4 s necesita trabajo, más de 4 s es pobre. Es una de las tres Core Web Vitals y se divide en cuatro subpartes — TTFB, retraso de carga de recursos, duración de carga de recursos, retraso de renderizado del elemento — donde TTFB y la duración de carga suelen dominar (pautas, no proporciones fijas — diagnostica tu propia página). Principales correcciones: nunca hagas lazy-load de la imagen LCP, añade fetchpriority="high" en el candidato real, precárgala cuando no esté en el HTML, elimina CSS/JS que bloqueen el renderizado y corrige TTFB. Es una métrica de campo — las herramientas de laboratorio solo la aproximan — y el elemento LCP puede cambiar durante la carga. Google confirma que las Core Web Vitals alimentan los sistemas de ranking pero no publica un peso exacto de LCP ni lo llama desempate; la relevancia del contenido sigue dominando.

Qué mide realmente LCP

El LCP informa el tiempo de renderizado de la imagen o bloque de texto más grande visible en el viewport, medido en relación con el momento en que el usuario navegó por primera vez a la página. El propio marco de Google: es el proxy estandarizado más cercano a cuándo aparece el contenido principal al usuario. Reemplazó métricas anteriores más difusas como First Meaningful Paint y Speed Index.

Algunas cosas que confunden a la gente de inmediato:

• No es el “tiempo de carga de la página”. Una página puede tener todos los recursos obtenidos y aún así mostrar un LCP lento si el renderizado del elemento más grande fue bloqueado. El LCP se trata de ese elemento, no de toda la página.
• No es lo mismo que el FCP. El First Contentful Paint se dispara cuando cualquier contenido aparece por primera vez; el LCP espera al elemento más grande. Una página puede tener un FCP rápido (la barra de navegación se pinta) y un LCP lento (la imagen principal carga tarde).
• Es una métrica dinámica. El navegador envía un nuevo candidato de LCP cada vez que un elemento más grande se vuelve visible. La última entrada antes de que el usuario interactúe (toque, desplazamiento, pulsación de tecla) o de que la página se descargue es el valor que cuenta: la interacción a menudo cambia lo que es visible, por lo que el informe se detiene ahí. Un candidato que luego se elimina del DOM no borra su propia entrada: sigue siendo el elemento informado a menos que un elemento aún más grande se renderice antes de que el informe se detenga.

Los umbrales — y por qué 2,5 segundos

Evaluado en el percentil 75 de las cargas de página de usuarios reales, segmentado por tipo de dispositivo. Así que tres de cada cuatro visitas deben llegar a menos de 2,5 s para que un origen pase. Evidence for this claim A good LCP is 2.5 seconds or less at the 75th percentile of page loads, segmented by device type. Scope: Current web.dev LCP field threshold and assessment method. Confidence: high · Verified: 2026-07-14 web.dev: Largest Contentful Paint

¿Por qué 2,5 específicamente? La metodología de umbrales de Google se apoyó en dos cosas: investigación de percepción humana que apunta a aproximadamente 1–3 segundos como la banda que se siente “inmediata”, y datos de viabilidad de CrUX que muestran que 2,5 s era consistentemente alcanzable para sitios bien optimizados sin ser trivialmente fácil. Objetivos más estrictos como 1,5 s o 2,0 s no eran consistentemente alcanzables en suficientes orígenes, por lo que no pasaron el corte.

Qué cuenta como elemento LCP

Los tipos de elementos considerados para el LCP:

• Elementos <img>
• Elementos <image> dentro de un <svg>
• Elementos <video> (el tiempo de carga de la imagen del póster, o el primer fotograma, lo que ocurra antes)
• Un elemento con una imagen de fondo cargada mediante la función CSS url()
• Elementos a nivel de bloque que contienen nodos de texto u otros hijos de texto en línea

El tamaño informado es lo que realmente es visible en el viewport: las porciones recortadas o desplazadas fuera no cuentan, y para las imágenes es el tamaño visible o el tamaño intrínseco, el que sea menor. Los márgenes, el relleno y los bordes se ignoran. Un puñado de elementos se excluyen mediante heurísticas: cualquier cosa con opacity: 0, elementos que cubren todo el viewport (tratados como fondos) e imágenes de marcador de posición de baja entropía.

Alrededor de tres cuartas partes de las páginas tienen una imagen como su elemento LCP, por lo que el trabajo de imagen suele ser el primer movimiento correcto. Pero no siempre, y no siempre compresión (más sobre eso a continuación). El resto son LCP de texto, donde la palanca es completamente diferente: es la carga de fuentes, no el peso de la imagen.

Las cuatro subpartes — la parte que la mayoría de los artículos omiten

Este es el marco con el que comenzaría cualquier diagnóstico de LCP. web.dev divide el LCP en cuatro subpartes secuenciales:

1. Tiempo hasta el primer byte (TTFB) — desde que el usuario comienza a cargar la página hasta que el navegador recibe el primer byte de HTML. Participación típica: ~40 % del LCP total.
2. Retraso de carga del recurso — la brecha entre el TTFB y el momento en que el navegador comienza a cargar el recurso LCP. Este es el tiempo de descubrimiento. Participación típica: menos del 10 %.
3. Duración de la carga del recurso — cuánto tarda el recurso LCP en descargarse. Participación típica: ~40 %.
4. Retraso de renderizado del elemento — desde que el recurso termina de cargarse hasta que el elemento realmente se pinta. Participación típica: menos del 10 %.

El principio detrás de la tabla: la gran mayoría del tiempo de LCP debería dedicarse a cargar el documento HTML y el recurso LCP. Cualquier tramo en el que ni uno ni el otro se esté cargando es una oportunidad para mejorar.

web.dev es explícito en que estos porcentajes son pautas, no reglas estrictas — no los conviertas en objetivos de segundos absolutos y no fuerces a cada página a coincidir con la división. Solo tienen sentido en relación entre sí, y si tu LCP ya está constantemente dentro de 2,5 segundos, las proporciones relativas no importan en absoluto. Usa la tabla para detectar qué subparte está consumiendo una parte desproporcionada en tu página y luego corrige esa — no para perseguir una división exacta de 40/10/40/10.

Y aquí está el detalle que trastoca la suposición común: a partir de febrero de 2025, estas cuatro subpartes están disponibles en la API de CrUX para LCP de imágenes, y el análisis del equipo de Chrome de los datos de HTTP Archive encontró que el tiempo de descarga de la imagen a menudo era la parte más pequeña del tiempo de LCP. En otras palabras, “solo comprime mis imágenes” con frecuencia corrige la subparte equivocada. El TTFB y el retraso de descubrimiento suelen ser las palancas más grandes.

Cómo encontrar tu elemento LCP

Antes de optimizar cualquier cosa, averigua cuál elemento es tu LCP y cuál subparte es el cuello de botella:

• PageSpeed Insights — la sección Diagnóstico señala el elemento LCP, y la pestaña de datos de campo muestra tu puntuación de usuarios reales.
• Chrome DevTools — el panel Rendimiento marca el nodo LCP en la línea de tiempo.
• La biblioteca JS web-vitals — registra el LCP (y el elemento) desde tu propio monitoreo de usuarios reales.

Cómo mejorar el LCP

Asocia cada corrección con la subparte a la que se dirige:

Corrige el retraso en la carga de recursos (descubrimiento). Esta es la de mayor apalancamiento y la más comúnmente rota.

• Nunca cargues de forma diferida tu imagen LCP. loading="lazy" en el elemento LCP siempre añade un retraso de carga innecesario. Reserva la carga diferida para imágenes debajo del pliegue.
• Añade fetchpriority="high" a la imagen LCP probable para que el navegador la obtenga temprano con alta prioridad.
• Precárgala con <link rel="preload"> cuando la imagen no sea descubrible en el HTML inicial — por ejemplo, cuando se carga mediante CSS o JavaScript. Cargar la imagen principal mediante JS es un antipatrón precisamente porque oculta la URL del escáner de precarga del navegador.
• Aloja los recursos críticos en el mismo origen para que el navegador no pague una configuración de conexión adicional.

La precarga y fetchpriority resuelven problemas diferentes, así que no recurras a ambos por costumbre. La precarga expone un recurso que el escáner de precarga del navegador de otro modo descubriría tarde (una imagen cargada por JS o CSS, por ejemplo); fetchpriority cambia la prioridad de obtención de un recurso que el navegador ya encontró. Si el descubrimiento y la prioridad ya son correctos — la imagen es un <img> simple en el HTML inicial — añadir cualquiera de los dos puede hacer poco más que solicitudes adicionales. Revisa un rastro, aplica el que coincida con el problema real y confirma que el número de campo se movió.

Corrige el retraso en el renderizado del elemento.

• Reduce o integra el CSS que bloquea el renderizado; difiere los estilos no críticos.
• Evita scripts síncronos en el <head>.
• Prefiere el renderizado del lado del servidor o la generación estática para que el marcado llegue listo para pintar, y divide las tareas largas del hilo principal.

Reduce la duración de la carga de recursos.

• Formatos de imagen modernos (WebP, AVIF), compresión sensata y una CDN.
• Cache-Control eficiente. Y no ignores la contención de red — cargar de forma diferida las otras imágenes debajo del pliegue puede liberar ancho de banda para que la imagen LCP llegue antes.

Reduce el TTFB.

• Minimiza las redirecciones, elimina los parámetros de URL únicos innecesarios y optimiza el tiempo de respuesta del servidor. Ten en cuenta que el LCP incluye cualquier tiempo de descarga de la página anterior, la configuración de conexión y el tiempo de redirección — todo lo cual se suma al TTFB.

Caso especial: LCP basado en texto. Cuando el elemento más grande es texto, la ruta crítica es la carga de fuentes, no el peso de la imagen. font-display: optional o las fuentes del sistema eliminan el retraso de renderizado inducido por fuentes; font-display: swap sin precargar el archivo de fuente puede introducirlo.

Laboratorio vs. campo: esta distinción importa

LCP es fundamentalmente una métrica de campo. Google la evalúa en usuarios reales mediante CrUX, que se muestra en la pestaña de campo de PageSpeed Insights y en el informe de Core Web Vitals de Search Console. Esos datos de campo son los que alimentan los rankings.

Las herramientas de laboratorio (Lighthouse, Chrome DevTools, WebPageTest) solo la aproximan en condiciones simuladas, y ni siquiera usan la misma puntuación. Lighthouse aplica umbrales de escritorio más estrictos (Bueno ≤ 1,2 s) que el estándar de campo (≤ 2,5 s). Por lo tanto, una puntuación aprobatoria en Lighthouse no garantiza una puntuación aprobatoria en CrUX, y viceversa. Usa las herramientas de laboratorio para depurar y reproducir; confía en los datos de campo para el veredicto real.

Hay una segunda razón por la que los números de laboratorio y de campo pueden divergir, que vale la pena conocer para que una lectura extraña no te haga perseguir un error fantasma: la API actual del navegador LargestContentfulPaint (aún un Borrador de Trabajo del W3C) está limitada a una sola carga de documento. No se reinicia en restauraciones de caché de retroceso/avance (bfcache) ni en navegaciones SPA del mismo documento, y las páginas que comienzan fuera de pantalla (pestañas en segundo plano, páginas prerenderizadas) pueden informar valores inflados porque el tiempo se mide desde la carga, no desde cuando la página realmente se hizo visible. El algoritmo de informe también se detiene ante la entrada de usuario calificada, por lo que si un usuario interactúa antes de que se muestre tu contenido principal, LCP no lo capturará. Nada de esto cambia la tabla de umbrales anterior; explica por qué el número de una sesión específica puede parecer incorrecto cuando la navegación subyacente no es una primera carga simple.

¿Afecta LCP a los rankings?

Sí, en el sentido de que Google confirma que Core Web Vitals alimentan sus sistemas de ranking y recomienda lograr buenas puntuaciones. Pero la documentación actual de Search Central no publica un peso exacto para LCP ni lo describe como un desempate: el propio marco de Google es que la experiencia de página “can contribute to success in Search” (traducción) «puede contribuir al éxito en la Búsqueda» para consultas donde varias páginas ya ofrecen contenido comparable y relevante, y que una buena puntuación no garantiza un impulso en el ranking. La relevancia y la calidad del contenido siguen dominando. Optimiza LCP porque una página que se siente más rápida es genuinamente mejor para los usuarios (y las conversiones), no porque el mecanismo esté documentado como un desempate de rankings, porque no lo está.

Un par de realidades de los datos: de los Core Web Vitals, LCP es el que más cuesta mejorar a los sitios, y es notablemente más difícil en móvil que en escritorio (CPU y conexiones más lentas). En 3G o más lento, el umbral de 2,5 s puede sentirse casi imposible de alcanzar.

Dónde encaja esto

LCP es uno de los tres Core Web Vitals, junto con Interaction to Next Paint y Cumulative Layout Shift. Su primera subparte, Time to First Byte, es su propia métrica de diagnóstico, y First Contentful Paint se sitúa justo al lado en la línea de tiempo de carga. Verás todos estos en PageSpeed Insights, Lighthouse y el Chrome User Experience Report (CrUX). Cada uno es su propio análisis profundo en este clúster.

Resumen de IA

Una versión condensada de la versión avanzada:

• LCP = tiempo de renderizado del bloque de imagen o texto visible más grande, relativo al momento en que la página comienza a cargarse. Es el proxy estandarizado más cercano a “cuándo aparece el contenido principal”.
• Umbrales: Bueno ≤ 2,5 s, Necesita mejoras 2,5–4 s, Pobre > 4 s — en el percentil 75 de usuarios reales, dividido por dispositivo. Es una de las tres Core Web Vitals.
• No es el tiempo de carga de la página, ni FCP. FCP = primer píxel de cualquier contenido; LCP = el elemento más grande. LCP también es dinámico — el candidato más grande puede cambiar durante la carga; el último antes de la interacción del usuario cuenta.
• Elementos LCP: <img>, <image> en <svg>, póster de <video>, CSS background-image: url(), o un elemento de texto a nivel de bloque. ~3 de cada 4 páginas tienen una imagen como LCP; el resto son texto (donde las fuentes, no el peso de la imagen, son la palanca).
• Cuatro subpartes: TTFB (~40 %), retardo de carga del recurso (<10 %), duración de carga del recurso (~40 %), retardo de renderizado del elemento (<10 %) — web.dev las llama pautas, no proporciones fijas; diagnostica por página en lugar de perseguir una división exacta. Datos de CrUX 2025: la descarga de imágenes suele ser la parte más pequeña — así que “solo comprime imágenes” a menudo arregla lo que no es.
• Principales correcciones: nunca cargues de forma diferida la imagen LCP; añade fetchpriority="high" en el candidato real; precárgala cuando no esté en el HTML (preload y fetchpriority resuelven problemas diferentes — no recurras a ambos por costumbre); reduce el CSS/JS que bloquea el renderizado; reduce el TTFB.
• De campo, no de laboratorio. CrUX/Search Console impulsan los rankings; Lighthouse solo aproxima y usa umbrales de escritorio más estrictos (≤ 1,2 s). La API actual LargestContentfulPaint está limitada a cargas de documentos y no se reinicia por sí sola para restauraciones de bfcache ni navegaciones SPA del mismo documento.
• Rankings: Google confirma que los sistemas de ranking usan las CWV, pero no publica un peso exacto para LCP ni lo llama desempate; la relevancia del contenido sigue dominando. Es la CWV más difícil de mejorar, y más en móvil.

Documentación oficial

Orientación de fuentes primarias de los equipos de Chrome y Search de Google.

web.dev (equipo de Chrome)

• Renderizado del contenido visible más grande (LCP) — la definición canónica: qué cuenta como elemento LCP, cómo se calcula el tamaño, cuándo se detiene el informe y las APIs de medición.
• Optimizar el renderizado del contenido visible más grande — el marco de las cuatro subpartes y el manual completo de optimización.
• Core Web Vitals — dónde encaja LCP entre las tres Core Web Vitals.
• Cómo se definieron los umbrales de Core Web Vitals — la investigación y los datos de viabilidad detrás de la marca de 2,5 s.

Chrome for Developers

• Subpartes de imágenes LCP y RTT disponibles en CrUX — el lanzamiento de datos de campo de febrero de 2025 de las cuatro subpartes (solo imágenes LCP).
• Renderizado del contenido visible más grande en Lighthouse — la métrica de laboratorio y su puntuación específica por dispositivo.

Google Search Central

• Comprender Core Web Vitals y los resultados de la Búsqueda de Google — cómo influyen las Core Web Vitals en la Búsqueda.

Citas de la fuente

Declaraciones registradas de la documentación y el equipo de Google. Cada enlace es un enlace profundo que salta al pasaje citado.

web.dev — definición y comportamiento (Philip Walton y Barry Pollard, Google)

• “LCP reports the render time of the largest image, text block, or video visible in the viewport, measured relative to when the user first navigated to the page.” (traducción) «LCP informa el tiempo de renderizado de la imagen, el bloque de texto o el video más grande visible en el viewport, medido en relación con el momento en que el usuario navegó por primera vez a la página.» Ir a la cita
• Sobre lo que se mide: “LCP doesn’t consider margins, paddings, or borders applied using CSS.” (traducción) «LCP no considera márgenes, rellenos ni bordes aplicados con CSS.» Ir a la cita
• Sobre cuándo se detiene el informe: “The browser will stop reporting new entries as soon as the user interacts with the page (via a tap, scroll, or keypress), as user interaction often changes what’s visible to the user.” (traducción) «El navegador dejará de informar nuevas entradas en cuanto el usuario interactúe con la página (mediante un toque, un desplazamiento o una pulsación de tecla), ya que la interacción del usuario suele cambiar lo que es visible para él.» Ir a la cita
• Sobre lo que se incluye en el tiempo: “It is important to note that LCP includes any unload time from the previous page, connection set up time, redirect time, and other Time To First Byte (TTFB) delays.” (traducción) «Es importante señalar que LCP incluye cualquier tiempo de descarga de la página anterior, el tiempo de configuración de la conexión, el tiempo de redirección y otros retrasos de Time To First Byte (TTFB).» Ir a la cita

web.dev — optimización (Philip Walton y Barry Pollard, Google)

• La regla más importante de la carga diferida: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” (traducción) «Nunca cargues de forma diferida tu imagen LCP, ya que eso siempre provocará un retraso innecesario en la carga de recursos.» Ir a la cita
• El principio detrás de los objetivos de subpartes: “The vast majority of the LCP time should be spent loading the HTML document and LCP source.” (traducción) «La gran mayoría del tiempo de LCP debería dedicarse a cargar el documento HTML y la fuente de LCP.» Ir a la cita

Google Search Central — rankings

• “We highly recommend site owners achieve good Core Web Vitals for success with Search and to ensure a great user experience generally.” (traducción) «Recomendamos encarecidamente que los propietarios de sitios logren buenos Core Web Vitals para tener éxito en la Búsqueda y garantizar una excelente experiencia de usuario en general.» (Transmitido desde el documento de Core Web Vitals de Search Central; confírmalo contra la página en vivo antes de tratarlo como definitivo.)

Lista de verificación para corregir LCP

Trabájala aproximadamente de arriba a abajo: primero el descubrimiento y el TTFB, porque suelen ser las palancas más grandes y las que más a menudo se rompen.

• Encontré el elemento LCP real (Diagnostics de PageSpeed Insights, panel de rendimiento de DevTools o la librería web-vitals) — no optimices a ciegas.
• Comprobé las cuatro subpartes para ver cuál es el cuello de botella antes de cambiar nada.
• La imagen LCP no tiene loading="lazy" (la carga diferida solo es para contenido bajo el pliegue).
• La imagen LCP tiene fetchpriority="high".
• La imagen LCP es detectable en el HTML inicial — o está precargada (<link rel="preload">) si se carga mediante CSS/JS.
• No se carga la imagen principal mediante JavaScript (la oculta del escáner de precarga).
• CSS que bloquea el renderizado minimizado/incrustado; estilos no críticos diferidos.
• Sin scripts síncronos en el <head>; tareas largas divididas.
• Formato de imagen moderno (WebP/AVIF), compresión razonable, servida mediante CDN con buen Cache-Control.
• Imágenes bajo el pliegue con carga diferida para que no compitan por ancho de banda con la imagen LCP.
• TTFB abordado: redirecciones minimizadas, respuesta del servidor optimizada, parámetros de URL basura eliminados.
• ¿LCP de texto? Usando font-display: optional o fuentes del sistema, y precargando cualquier archivo de fuente intercambiado.
• Verificado con datos de campo (CrUX / Search Console), no solo con una ejecución de laboratorio de Lighthouse.

Hoja de referencia de LCP

Umbrales (percentil 75 de usuarios reales, por dispositivo)

Las cuatro subpartes — qué es cada una y la solución

Qué puede ser el elemento LCP

• <img> · <image> dentro de <svg> · póster de <video> · CSS background-image: url() · texto a nivel de bloque

Excluidos por heurística: opacity: 0, elementos de “fondo” a pantalla completa, marcadores de posición de baja entropía.

Datos rápidos

• LCP es una métrica de campo (CrUX / Search Console impulsan los rankings); Lighthouse solo la aproxima y usa un umbral de escritorio más estricto de ≤ 1,2 s.
• El elemento LCP puede cambiar durante la carga; el último candidato antes de la interacción del usuario es el que cuenta.
• Aproximadamente 3 de cada 4 páginas tienen un LCP de imagen; el resto son de texto (las fuentes son la palanca).
• El tiempo de descarga de la imagen suele ser la subparte más pequeña — la compresión no siempre es la respuesta.
• LCP ≠ FCP; LCP ≠ tiempo total de carga de la página.

Herramientas para medir y corregir el LCP

Datos de campo (lo que usan los rankings)

• PageSpeed Insights — la pestaña de campo muestra tu LCP de CrUX de usuarios reales; Diagnostics señala el elemento LCP.
• Informe de Core Web Vitals en Search Console — estado del LCP en tus URLs, agrupado, con datos de usuarios reales.
• Chrome User Experience Report (CrUX) — el conjunto de datos de campo subyacente; desde febrero de 2025 incluye las cuatro subpartes del LCP de imagen mediante la API.
• Librería JS web-vitals — registra el LCP y el elemento LCP desde tu propio monitoreo de usuarios reales.

Datos de laboratorio (para depurar)

• Lighthouse — LCP de laboratorio rápido y una lista de oportunidades (recuerda: umbrales de escritorio más estrictos que los de campo).
• Chrome DevTools — panel de rendimiento — marca el nodo LCP y la línea de tiempo completa del renderizado.
• WebPageTest — vista de cascada para identificar qué subparte es lenta.

Rastreadores SEO

• Site Audit de Ahrefs — detecta problemas de Core Web Vitals / rendimiento en todo el sitio a escala.

Cómo puntúan las propias herramientas

Un ejemplo en vivo de la métrica que describe esta página — servicios conocidos de velocidad de página y monitoreo clasificados según su propio LCP móvil de usuarios reales (datos de campo de Chrome UX Report):

Correcciones de LCP que apuntan al problema equivocado

Carga diferida de la imagen principal

loading="lazy" retrasa el descubrimiento de una imagen sobre el pliegue que probablemente se convierta en LCP. Cárgala de forma eager, asigna fetchpriority="high" al candidato probable y reserva la carga diferida para imágenes bajo el pliegue.

Comprimir cada imagen antes de encontrar el cuello de botella

La duración de la descarga de la imagen es solo una de las cuatro subpartes del LCP y puede ser la más pequeña. Identifica el elemento LCP e inspecciona TTFB, retraso de carga, duración de carga y retraso de renderizado antes de elegir una corrección.

Cargar la imagen principal mediante JavaScript

Una imagen inyectada por JS oculta su URL al escáner de precarga del navegador y crea retraso en la carga del recurso. Coloca la imagen en el HTML inicial o precárgala cuando CSS o JS deban controlarla.

Declarar victoria con una sola ejecución de Lighthouse

Lighthouse es un diagnóstico controlado, mientras que el veredicto de CWV de Google proviene de datos de campo de CrUX. Usa ejecuciones de laboratorio para verificar el mecanismo y espera a que los datos de usuarios reales muestren si el resultado p75 mejoró.

El recurso LCP comienza tarde

Síntoma: aparece un largo intervalo entre TTFB y la solicitud del recurso LCP. Causa probable: carga diferida, descubrimiento por JS, imagen de fondo CSS o baja prioridad de búsqueda. Corrección: haz que el recurso sea descubrible en el HTML inicial, elimina la carga diferida, aplica fetchpriority="high" o precárgalo. Confirma que la solicitud se mueve antes en un trace.

El recurso se carga pero el LCP aún se dispara tarde

Síntoma: la duración de carga termina mucho antes del evento LCP. Causa probable: CSS que bloquea el renderizado, JavaScript síncrono, una tarea larga o renderizado de fuentes para un LCP de texto. Corrección: reduce el trabajo bloqueante y prueba la estrategia de fuentes para texto; confirma que el retraso de renderizado del elemento se reduce.

El LCP de laboratorio es bueno pero el LCP de campo es deficiente

Síntoma: Lighthouse pasa mientras que CrUX o Search Console no. Causa probable: los usuarios reales tienen diferentes dispositivos, redes, estados de caché, geografías o elementos LCP. Corrección: segmenta los datos de campo, captura detalles de elementos/subpartes de RUM y reproduce el segmento lento en lugar de ajustar solo el perfil de laboratorio predeterminado.

El elemento LCP informado cambia entre ejecuciones

Síntoma: DevTools identifica diferentes imágenes o bloques de texto. Causa probable: puntos de interrupción responsivos, personalización, cambios tardíos en el DOM o candidatos en competencia. Corrección: prueba viewports y estados representativos, luego optimiza cada candidato recurrente en lugar de asumir que una imagen principal de escritorio cubre a todos los usuarios.

Descubrimiento de la imagen principal: retrasado vs temprano

Una implementación retrasada simplificada oculta la imagen detrás de JavaScript:

<div id="hero"></div>
<script>
  document.querySelector('#hero').innerHTML = '<img src="hero.webp" alt="">';
</script>

El navegador puede descubrir y priorizar esta versión mientras analiza el HTML:

<img src="hero.webp" alt="" fetchpriority="high" width="1200" height="675">

Imagen de fondo CSS: no revelada vs precargada

Cuando la imagen LCP debe permanecer como fondo CSS, revélala antes de que termine la hoja de estilos:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

La precarga solo ayuda cuando su URL y atributos de solicitud coinciden con el recurso real.

Listar candidatos LCP recientes en Chrome DevTools

Pega esto en la Consola de Chrome DevTools, recarga la página y observa cada candidato que el navegador informa. El último candidato antes de la interacción es el relevante.

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.table({
      lcp: Math.round(entry.startTime),
      element: entry.element?.tagName,
      url: entry.url || '',
      size: entry.size,
    });
  }
}).observe({ type: 'largest-contentful-paint', buffered: true });

Encontrar imágenes sobre el pliegue probablemente con carga diferida

Ejecuta esto en la Consola de DevTools. Lista imágenes diferidas cuyo borde superior comienza en el viewport actual; verifica el candidato LCP real antes de eliminar el atributo.

[...document.querySelectorAll('img[loading="lazy"]')]
  .filter((img) => img.getBoundingClientRect().top < innerHeight)
  .map((img) => ({ src: img.currentSrc || img.src, top: img.getBoundingClientRect().top }));

Extraer atributos de prioridad de imagen en un rastreador

Usa este XPath en la extracción personalizada de Screaming Frog para devolver imágenes marcadas como de alta prioridad:

//img[@fetchpriority='high']/@src

Probar que una corrección de LCP se implementó

Prueba de orden de descubrimiento

Prueba a ejecutar: graba un trace de rendimiento de DevTools después de cambiar la imagen principal. Resultado esperado: la solicitud LCP comienza antes y no tiene carga diferida. Interpretación de fallo: el recurso permanece oculto, despriorizado o bloqueado detrás de otra dependencia. Ventana de monitoreo: resultado de laboratorio inmediato. Disparador de reversión: el cambio retrasa otro recurso crítico o hace que el LCP de laboratorio sea consistentemente peor.

Prueba de retraso de renderizado

Prueba a ejecutar: compara la finalización del recurso LCP y el evento LCP en trazas equivalentes de antes/después. Resultado esperado: el retraso de renderizado del elemento se reduce sin un nuevo diseño o regresión visual. Interpretación del fallo: CSS, JavaScript o fuentes aún bloquean la pintura. Ventana de monitoreo: inmediata en viewports representativos. Disparador de reversión: renderizado roto, estilos faltantes o un LCP recurrente peor.

Prueba de resultado de campo

Prueba a ejecutar: monitorea el LCP p75 a nivel de URL en CrUX o RUM de primera parte después del despliegue. Resultado esperado: el p75 se mueve hacia o permanece dentro del umbral de Bueno sin regresar INP o CLS. Interpretación del fallo: el caso de laboratorio no fue representativo u otra subparte domina las visitas reales. Ventana de monitoreo: RUM puede liderar; CrUX necesita que su ventana móvil de 28 días se renueve. Disparador de reversión: una regresión de campo sostenida vinculada al lanzamiento.

Métricas de LCP que vale la pena rastrear

LCP p75 de campo

Métrica: LCP en el percentil 75 por factor de forma. Qué te dice: si los usuarios reales cumplen con el umbral de carga de Core Web Vitals. Cómo obtenerlo: CrUX, Search Console o RUM de primera parte. Referencia / rango realista: Bueno está en o por debajo de 2,5 segundos; segmenta móvil y escritorio. Cadencia: semanal, con la ventana móvil de CrUX registrada.

Distribución de subpartes de LCP

Métrica: TTFB, retraso de carga de recursos, duración de carga y retraso de renderizado del elemento para LCP. Qué te dice: qué etapa posee la espera. Cómo obtenerlo: trazas de laboratorio representativas y subpartes de imagen-LCP de CrUX/RUM donde estén disponibles. Referencia / rango realista: usa la división diagnóstica aproximada de 40/10/40/10 del artículo como guía, no una promesa universal de rendimiento. Cadencia: después de lanzamientos de plantillas y mensualmente para plantillas prioritarias.

Cobertura de URLs con LCP Bueno

Métrica: grupos de URLs importantes con LCP de campo Bueno. Qué te dice: si la mejora es amplia o limitada a una página de muestra. Cómo obtenerlo: grupos de CWV de Search Console más CrUX a nivel de URL para páginas prioritarias. Referencia / rango realista: establece una línea base por plantilla; las URLs de bajo tráfico pueden carecer de datos de campo individuales. Cadencia: semanal.

Ponte a prueba: Largest Contentful Paint

Cinco preguntas rápidas sobre la medición y el diagnóstico de LCP. Elige una respuesta para cada una y luego verifica.

Recursos que valen tu tiempo

Mis escritos relacionados

• Qué es Largest Contentful Paint (LCP) y cómo mejorarlo — mi guía completa de LCP en el blog de Ahrefs.
• Qué son Core Web Vitals y cómo mejorarlas — cómo encaja LCP con INP y CLS, y por qué es el más difícil de arreglar.
• Guía para principiantes de SEO técnico — dónde se sitúa el rendimiento de la página en el panorama general.

Oficial (Google / Chrome)

• Largest Contentful Paint (LCP) y Optimize LCP — el par canónico.
• How CWV thresholds were defined — el porqué detrás de 2,5 s.

De otros

• Corrige el Largest Contentful Paint de tu sitio optimizando la carga de imágenes — la perspectiva de MDN orientada a desarrolladores, sólida en contención de ancho de banda y el antipatrón de imágenes con JS.
• Rendimiento — Web Almanac 2025 — el análisis anual en profundidad de HTTP Archive; fuente de estadísticas de adopción sobre fetchpriority, uso de preload, desgloses de LCP por imagen frente a texto y tasas de aprobación por dispositivo.
• Largest Contentful Paint (LCP) — la documentación de DebugBear cubre el análisis de cascada para identificar subpartes, advertencias sobre JPEG progresivo y casos límite de iframes y navegación suave.
• Largest Contentful Paint (LCP): qué es, cómo medirlo y optimizarlo — corewebvitals.io; benchmarks RUM reales, estudios de caso de impacto empresarial (Vodafone Italia) y el resultado de fetchpriority en Google Flights.
• Largest Contentful Paint | Documentación web de MDN — referencia de MDN para la API LargestContentfulPaint, tipos de elementos y compatibilidad con navegadores.

Estadísticas que vale la pena citar

• LCP es la Core Web Vital más difícil de aprobar. Tiene la mayor cantidad de componentes, por eso los sitios luchan más con ella que con INP o CLS. Fuente
• El móvil es más difícil que el escritorio. Las CPU y conexiones más lentas elevan el LCP, y en conexiones 3G/lentas el umbral de 2,5 s es casi imposible de alcanzar. Fuente
• El tiempo de descarga de la imagen suele ser la parte más pequeña del LCP. El análisis de Chrome de los datos de HTTP Archive encontró que la duración de la descarga frecuentemente no es el cuello de botella — el TTFB y el retraso de descubrimiento suelen serlo. Fuente
• La cobertura de CrUX es escasa. En nuestro estudio de 42 millones de páginas, solo ~11,4 % tenían datos de campo de CrUX asociados — la mayoría de las páginas no reciben suficiente tráfico de usuarios reales para ser medidas. Fuente
• El 62 % de las páginas móviles frente al 74 % de las páginas de escritorio logran un LCP bueno (Web Almanac 2025). La brecha móvil refleja CPU y conexiones de red más lentas. Fuente
• Solo el 2,1 % de las páginas móviles precargan su imagen LCP, a pesar de que el 76 % tiene una imagen como elemento LCP — una oportunidad de optimización significativa desaprovechada (Web Almanac 2025). Fuente
• La adopción de fetchpriority="high" creció del 0,03 % de los sitios móviles en 2022 al 17,3 % en 2025, impulsada en gran medida por WordPress core al añadirlo (Web Almanac 2025). Google Flights vio una mejora de 700 ms en LCP gracias a este único atributo. Fuente

Videos

• Google Search Central (YouTube) — los explicadores de Core Web Vitals y experiencia de página, incluidos los recorridos del equipo de Chrome sobre la optimización de LCP. Canal

Registro de cambios