--- title: "Largest Contentful Paint (LCP): cómo optimizar el tiempo de carga" description: "Optimizar el LCP: medidas prácticas para mejorar el Largest Contentful Paint y bajarlo de 2,5 segundos." locale: "es" canonical: "https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/largest-contentful-paint-lcp-como-optimizar-el-tiempo-de-carga" category: "SEO & GEO" topic: "SEO técnico" updated: "2026-10-28T13:11:05.504Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Largest Contentful Paint (LCP): cómo optimizar el tiempo de carga El Largest Contentful Paint (LCP) es una de las tres Core Web Vitals y mide el tiempo que pasa desde el inicio de la carga de la página hasta que se renderiza el bloque de contenido visible más grande del viewport, normalmente una imagen hero, un bloque de texto grande o un vídeo. El umbral de un buen rendimiento está por debajo de 2,5 segundos, medido en el percentil 75 de los datos reales de usuarios. El LCP se compone de cuatro subpartes: Time to First Byte, Resource Load Delay, Resource Load Duration y Element Render Delay. ## De un vistazo - El objetivo para el LCP es quedar por debajo de 2,5 segundos, medido en el percentil 75 de los datos reales de usuarios (CrUX); entre 2,5 y 4,0 segundos necesita mejorar y por encima de 4,0 segundos se considera deficiente. - El LCP es la métrica de Core Web Vitals más difícil de superar: solo el 62 % de las páginas móviles alcanza un buen valor, frente al 77 % en INP y al 81 % en CLS. - En alrededor del 85 % de las páginas de escritorio y del 76 % de las móviles, el elemento LCP es una imagen; los elementos LCP más habituales son imágenes hero, bloques de texto grandes y vídeos. - El LCP se divide en cuatro subpartes: Time to First Byte, Resource Load Delay, Resource Load Duration y Element Render Delay. El diagnóstico muestra dónde se pierde realmente el tiempo. - La imagen LCP nunca debe cargarse en diferido (lazy loading); los formatos modernos (WebP/AVIF), fetchpriority=high y un servidor rápido (TTFB) son las palancas más eficaces y, si la imagen se descubre tarde, además un preload. - Los datos de campo y los de laboratorio se complementan: Lighthouse muestra la causa; CrUX/PageSpeed/Search Console muestran si afecta a usuarios reales. Una optimización solo cuenta cuando se refleja en los datos de campo. - Un LCP rápido repercute de forma medible en la conversión y la facturación y actúa como factor de desempate en el ranking; en Austria, con alrededor de un 44 % de tráfico móvil, el LCP móvil es la prioridad principal. El Largest Contentful Paint (LCP) es la métrica de Core Web Vitals en la que fallan la mayoría de los sitios web. Mide cuánto tarda en renderizarse el bloque de contenido visible más grande en pantalla. Este artículo explica cómo funciona exactamente el LCP, de qué se compone el tiempo de carga, cómo puedes optimizar el LCP a nivel técnico y por qué la métrica repercute directamente en la conversión y la visibilidad de las empresas B2B en Europa. ## Por qué el LCP es relevante para las empresas El LCP es una de las tres [Core Web Vitals](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/core-web-vitals-lcp-inp-y-cls-explicados) con las que Google evalúa la experiencia de usuario de una página. De las tres métricas, el LCP es la más exigente. Según el HTTP Archive Web Almanac 2025, [el 62 % de las páginas móviles y el 74 % de las de escritorio alcanzan un buen valor de LCP](https://almanac.httparchive.org/en/2025/performance) (estudio internacional, datos de CrUX de julio de 2025). En comparación, [INP alcanza un 77 % y CLS un 81 % de valores buenos en dispositivos móviles](https://almanac.httparchive.org/en/2025/performance). El LCP es, por tanto, el factor limitante: es precisamente la métrica que con más frecuencia decide si una página supera la evaluación de Core Web Vitals. En total, solo [el 48 % de los orígenes móviles y el 56 % de los de escritorio superan las tres Core Web Vitals](https://almanac.httparchive.org/en/2025/performance) (estudio internacional). Para el mercado austriaco, el rendimiento móvil es especialmente importante. En septiembre de 2025, [alrededor del 44,4 % de todas las páginas vistas en internet en Austria procedían de dispositivos móviles](https://de.statista.com/statistik/daten/studie/431578/umfrage/anteil-mobiler-endgeraete-an-allen-seitenaufrufen-in-oesterreich/) (Austria, datos de StatCounter sin tablets). Según el Web Almanac, los usuarios móviles sufren valores de LCP deficientes casi el doble de veces que los de escritorio, [un 13 % frente a un 7 %](https://almanac.httparchive.org/en/2025/performance) (estudio internacional). Quien en Austria atiende casi la mitad de su tráfico en móvil optimiza el LCP justo donde la debilidad es mayor. El business case es medible. Un estudio A/B de Vodafone documentado por Google muestra que [un LCP un 31 % mejor se tradujo en un 8 % más de ventas, una tasa lead-to-visit un 15 % mejor y una tasa cart-to-visit un 11 % mejor](https://web.dev/case-studies/vodafone) (estudio internacional). Un análisis de Deloitte Digital y Fifty-Five para Google también demuestra el efecto de la velocidad: en el segmento retail, [una carga móvil solo 0,1 segundos más rápida aumentó la tasa de conversión un 8,4 % y el valor medio del pedido un 9,2 %](https://www.thinkwithgoogle.com/_qs/documents/9757/Milliseconds_Make_Millions_report_hQYAbZJ.pdf) (estudio internacional). Para los responsables de decisión B2B, el LCP es así una palanca directa sobre la facturación y la calidad de los leads. Además, en decisiones de ranking ajustadas, la métrica actúa como factor de desempate entre resultados que por lo demás son equivalentes. ## Cómo funciona el LCP: umbrales y subpartes El LCP mide el momento en que se renderiza el bloque de contenido visible más grande del viewport. Se mide desde el inicio de la carga de la página. Como elemento LCP suelen entrar en juego imágenes hero, bloques de texto grandes o vídeos. En la práctica dominan las imágenes: en [el 85,3 % de las páginas de escritorio y el 76 % de las móviles, el elemento LCP es una imagen](https://almanac.httparchive.org/en/2025/performance) (estudio internacional). Los elementos LCP basados en texto constituyen el resto; en móvil, con un 23,7 %, son algo más frecuentes que en escritorio. Google define tres umbrales, medidos en el percentil 75 de los datos reales de usuarios: - **Bueno:** menos de 2,5 segundos. Este valor debería ser el objetivo de cualquier optimización. - **Necesita mejorar:** entre 2,5 y 4,0 segundos. Aquí hay que actuar. - **Deficiente:** más de 4,0 segundos. En este rango, la experiencia de usuario se resiente claramente. El percentil 75 significa que el 75 % de las visitas reales a la página deben alcanzar el umbral. Por eso no basta con un buen valor de laboratorio en un equipo de desarrollo rápido si los dispositivos y las conexiones más lentos empujan el percentil hacia arriba. Para optimizar el LCP de forma específica, hay que entender de qué se compone ese tiempo. Google divide el LCP en cuatro subpartes: - **Time to First Byte (TTFB):** el tiempo hasta que el servidor entrega el primer byte de la respuesta. Incluye el DNS, el establecimiento de la conexión y el procesamiento en el servidor. - **Resource Load Delay:** el intervalo entre el TTFB y el inicio de la carga del recurso LCP. Aquí se pierde tiempo cuando el navegador descubre tarde la imagen LCP. - **Resource Load Duration:** el tiempo de carga del recurso LCP en sí, es decir, cuánto tarda en descargarse la imagen o la fuente. - **Element Render Delay:** el tiempo entre la carga completa del recurso y su renderizado efectivo, a menudo bloqueado por JavaScript o CSS. Este desglose es la clave del diagnóstico. Una imagen LCP lenta exige una medida distinta que un servidor lento o un JavaScript que bloquea el renderizado. ## Buenas prácticas: cómo optimizar el LCP Las optimizaciones más eficaces actúan sobre las cuatro subpartes. Estas son las medidas con mayor impacto en la práctica: - **Reducir el TTFB y acelerar el servidor:** un servidor lento suele ser la partida individual más grande. El renderizado en el servidor, una caché bien configurada y una CDN con ubicaciones edge acortan los recorridos. HTTP/3 (QUIC) y la compresión Brotli aceleran además la transferencia. Compensa un hosting o un edge de CDN con recorridos cortos hasta tus usuarios; para el público austriaco, por ejemplo, un nodo en Viena o Fráncfort. - **Servir bien la imagen LCP:** los formatos modernos como WebP y AVIF reducen notablemente el tamaño del archivo frente a JPEG con la misma calidad. Aun así, según el Web Almanac, JPEG sigue siendo, con [alrededor del 57 %, el formato de imagen LCP más habitual; le sigue WebP con un 11 % y AVIF apenas llega al 0,7 %](https://almanac.httparchive.org/en/2025/performance) (estudio internacional). Aquí hay potencial sin aprovechar. Sirve variantes responsive mediante srcset y sizes, define las dimensiones correctas de la imagen y aplica fetchpriority="high" a la imagen LCP. Solo necesitas un preload si el navegador no encuentra la imagen directamente en el HTML, por ejemplo en un fondo CSS. - **Evitar el lazy loading de la imagen LCP:** la imagen LCP nunca debe cargarse en diferido. Según el Web Almanac, [entre el 16 y el 17 % de las páginas cargan en diferido su imagen LCP](https://almanac.httparchive.org/en/2025/performance) (estudio internacional) y desperdician así un tiempo valioso. loading="lazy" corresponde a las imágenes situadas por debajo del área visible, no al elemento LCP. - **Eliminar el bloqueo del renderizado:** el CSS crítico debería servirse inline y el resto, de forma diferida. El JavaScript se carga con defer o async para que no bloquee el renderizado. Las fuentes web reciben font-display: swap y un preload, para que los bloques de texto no tengan que esperar a la fuente. ## Errores frecuentes al optimizar el LCP Al optimizar se repiten ciertos patrones que cuestan tiempo de carga: - **Cargar en diferido la imagen LCP:** el error más frecuente. Un loading="lazy" generalizado en todas las imágenes afecta también a la imagen hero y alarga innecesariamente el Resource Load Delay. - **Optimizar solo los valores de laboratorio:** quien solo mira los valores de Lighthouse optimiza para una prueba sintética, no para usuarios reales. El percentil 75 de los datos de campo puede ser bastante peor. - **Ignorar el TTFB:** muchos equipos optimizan imágenes aunque el freno real sea el servidor. Sin mirar las subpartes, se trabaja en el sitio equivocado. - **Mantener formatos de imagen obsoletos:** la alta proporción de JPEG demuestra que los formatos modernos se usan poco. Quien se queda con JPEG renuncia a una mejora de eficiencia sencilla. - **Subestimar la hidratación de JavaScript:** en los frameworks modernos, el elemento LCP puede estar ya cargado y, aun así, renderizarse con retraso por la hidratación. El Element Render Delay aumenta sin que la culpa sea de la imagen ni del servidor. ## El LCP en la arquitectura de Next.js Next.js ofrece varios mecanismos que repercuten directamente en el LCP. El componente next/image sirve automáticamente formatos modernos, dimensiones correctas y tamaños responsive. Para la imagen LCP, a partir de Next.js 16 defines loading="eager", para que no se cargue en diferido, y fetchPriority="high". La antigua prop priority está [obsoleta desde Next.js 16](https://nextjs.org/docs/app/api-reference/components/image) y la sustituye la prop preload. Pero, según la documentación, rara vez necesitas preload: en la mayoría de los casos bastan loading="eager" o fetchPriority="high", y preload no debe combinarse con esas props en una misma imagen. En Next.js 15 y anteriores, priority sigue siendo el camino correcto. Solo una imagen por página, el elemento LCP, debería priorizarse así. El App Router con Server Components y SSR en streaming renderiza el contenido crítico en el servidor y lo envía pronto al navegador. Eso acorta el Resource Load Delay y el Element Render Delay, porque el contenido LCP no se genera primero en el cliente. Es importante no colocar el elemento LCP detrás de la hidratación en el cliente. El contenido que se renderiza como Server Component está disponible al instante. Si, en cambio, se traslada a un Client Component con una hidratación pesada, el retraso de renderizado aumenta. ## Métricas y medición: datos de campo frente a datos de laboratorio El LCP se mide de dos maneras, y ambas son necesarias. Los datos de campo proceden de usuarios reales y reflejan la realidad. Las fuentes son el [Chrome User Experience Report (CrUX)](https://developer.chrome.com/docs/crux), PageSpeed Insights y Google Search Console. Estos datos determinan el percentil 75 oficial y, con él, si una página supera la evaluación. Los datos de laboratorio se generan de forma sintética en condiciones controladas, por ejemplo con Lighthouse o herramientas locales. Son reproducibles y sirven para probar cambios antes del despliegue y para aislar causas concretas. Lo decisivo: ambos se complementan. Los datos de laboratorio muestran a qué se debe el problema; los de campo, si afecta realmente a los usuarios. Una optimización solo se considera un éxito cuando se refleja en los datos de campo. Para un control continuo se recomienda el [Real User Monitoring](https://blckalpaca.at/es/servicios/agencia-marketing-digital) (RUM). La librería oficial web-vitals registra el LCP directamente en el navegador de usuarios reales y envía los valores a una herramienta de analítica. Así puedes configurar alertas y detectar pronto las regresiones tras cada despliegue. Sin esta monitorización, un empeoramiento del LCP suele notarse cuando los rankings o las conversiones ya se resienten. Darle un lugar fijo en el proceso de despliegue, por ejemplo con un check automático de Lighthouse más una comparación de RUM, protege frente a regresiones graduales. ## LCP, crawlers de IA y GEO: cómo encajan Un renderizado rápido en el servidor ayuda a usuarios y crawlers. Los crawlers de [IA](https://blckalpaca.at/es/glosario/ia) y los bots clásicos de los buscadores se benefician cuando el contenido se entrega desde el servidor y sin largas dependencias de JavaScript. La misma arquitectura que mejora el LCP, es decir, SSR, un TTFB rápido y poco JavaScript que bloquee el renderizado, hace que el contenido también sea accesible de forma fiable para los crawlers de IA. Conviene delimitarlo bien. El LCP es una métrica de rendimiento para la experiencia de usuario, no un factor GEO directo. La Generative Engine Optimization se decide por el contenido, la estructura y la citabilidad, no por el tiempo de carga de una imagen hero. El LCP contribuye de forma indirecta, porque un renderizado rápido en el servidor facilita la entrega a los crawlers. Pero no sustituye ninguna medida de GEO. Quien optimiza el LCP mejora la accesibilidad técnica, no la relevancia del contenido para las respuestas de IA. ## Para profundizar y conclusión El LCP es la métrica de Core Web Vitals con mayor potencial de optimización y la relación más directa con el negocio. Quien alcanza el objetivo de menos de 2,5 segundos en el percentil 75 de los datos de campo mejora la experiencia de usuario, la conversión, la tasa de rebote y sus posibilidades en decisiones de ranking ajustadas. El camino pasa por las cuatro subpartes: un servidor rápido, una imagen LCP descubierta pronto y servida en formatos modernos, nada de lazy loading en la imagen hero y una ruta de renderizado sin CSS ni JavaScript bloqueante. Los siguientes pasos sensatos son medir el LCP actual en PageSpeed Insights y Search Console, identificar el elemento LCP y sus subpartes y configurar Real User Monitoring para un control permanente. En el mercado austriaco, con una alta proporción de tráfico móvil, merece especialmente la pena centrarse en el LCP móvil, porque es justo ahí donde están los mayores déficits. ## Datos y estadísticas - El 62 % de las páginas móviles y el 74 % de las de escritorio alcanzan un buen valor de LCP (menos de 2,5 s); en móvil hay casi el doble de valores de LCP deficientes, un 13 % frente a un 7 %. Con un 62 %, el LCP tiene la tasa de aprobación móvil más baja de las tres CWV (INP 77 %, CLS 81 %). — [HTTP Archive Web Almanac 2025, Performance chapter (datos de CrUX de julio de 2025) [internacional] (2025)](https://almanac.httparchive.org/en/2025/performance) - Solo el 48 % de los orígenes móviles y el 56 % de los de escritorio superan las tres Core Web Vitals; el LCP es la métrica limitante. — [HTTP Archive Web Almanac 2025, Performance chapter [internacional] (2025)](https://almanac.httparchive.org/en/2025/performance) - En el 85,3 % de las páginas de escritorio y el 76 % de las móviles, el elemento LCP es una imagen; los elementos LCP basados en texto representan el 23,7 % en móvil. — [HTTP Archive Web Almanac 2025, Performance chapter (LCP content types) [internacional] (2025)](https://almanac.httparchive.org/en/2025/performance) - Entre el 16 y el 17 % de las páginas cargan en diferido su imagen LCP (cifra estable desde 2024); el uso nativo de loading=lazy subió en móvil del 9,5 al 10,4 %. — [HTTP Archive Web Almanac 2025, Performance chapter (LCP lazy loading) [internacional] (2025)](https://almanac.httparchive.org/en/2025/performance) - JPG es, con alrededor del 57 %, el formato de imagen LCP más habitual (4 puntos porcentuales menos que en 2024); le sigue WebP con un 11 % (4 puntos más), AVIF alcanza el 0,7 % y PNG, el 26 %. — [HTTP Archive Web Almanac 2025, Performance chapter (LCP image formats) [internacional] (2025)](https://almanac.httparchive.org/en/2025/performance) - Un LCP un 31 % mejor se tradujo en un 8 % más de ventas, una tasa lead-to-visit un 15 % mejor y una tasa cart-to-visit un 11 % mejor (test A/B, página optimizada 5,7 s frente a 8,3 s). — [web.dev (Google): Vodafone case study [internacional] (2021)](https://web.dev/case-studies/vodafone) - En el segmento retail, una carga móvil 0,1 segundos más rápida aumentó la tasa de conversión un 8,4 %, el valor medio del pedido un 9,2 % y las páginas vistas por sesión un 5,2 %. — [Deloitte Digital / Fifty-Five para Google: informe 'Milliseconds Make Millions' (p. 17, retail) [internacional] (2020)](https://www.thinkwithgoogle.com/_qs/documents/9757/Milliseconds_Make_Millions_report_hQYAbZJ.pdf) - En septiembre de 2025, alrededor del 44,4 % de todas las páginas vistas en internet en Austria procedían de dispositivos móviles como smartphones (sin contar tablets, en torno al 1,9 %). — [Statista (datos de StatCounter): cuota de dispositivos móviles en el total de páginas vistas en Austria [Austria] (2025)](https://de.statista.com/statistik/daten/studie/431578/umfrage/anteil-mobiler-endgeraete-an-allen-seitenaufrufen-in-oesterreich/) ## Preguntas frecuentes ### ¿Qué es un buen valor de LCP? Un buen valor de LCP está por debajo de 2,5 segundos. Google define tres umbrales: bueno (menos de 2,5 s), necesita mejorar (de 2,5 a 4,0 s) y deficiente (más de 4,0 s). Lo determinante es el percentil 75 de los datos reales de usuarios (CrUX), es decir, el 75 % de las visitas reales a la página debe alcanzar el umbral. Un buen valor de laboratorio no basta por sí solo si los dispositivos y las conexiones más lentos empujan el percentil hacia arriba. ### ¿Cómo puedo optimizar el LCP? Actúa sobre las cuatro subpartes. Reduce el TTFB con renderizado en el servidor, caché, CDN, HTTP/3 y Brotli. Sirve la imagen LCP en formatos modernos (WebP/AVIF) con las dimensiones correctas, srcset/sizes y fetchpriority=high, y nunca la cargues en diferido. Un preload solo hace falta si el navegador descubre la imagen tarde. Elimina el CSS y el JavaScript que bloquean el renderizado con CSS crítico inline, defer/async y font-display: swap con preload para las fuentes web. ### ¿Qué es el elemento LCP de una página? El elemento LCP es el bloque de contenido visible más grande del viewport. Normalmente son imágenes hero, bloques de texto grandes o vídeos. En la práctica dominan las imágenes: según el HTTP Archive Web Almanac 2025, en alrededor del 85 % de las páginas de escritorio y del 76 % de las móviles el elemento LCP es una imagen. Qué elemento cuenta en concreto lo muestran herramientas como PageSpeed Insights o las Chrome DevTools. ### ¿Por qué mi LCP es malo aunque la imagen cargue rápido? Porque el LCP consta de cuatro subpartes y la imagen solo afecta a una de ellas. A menudo el freno está en el servidor (TTFB alto), en que la imagen se descubre tarde (Resource Load Delay) o en un renderizado retrasado por JavaScript y CSS (Element Render Delay). En los frameworks modernos, el elemento LCP puede estar ya cargado y, aun así, renderizarse con retraso por la hidratación. Un análisis de las subpartes muestra dónde se pierde realmente el tiempo. ### ¿Cuál es la diferencia entre datos de campo y datos de laboratorio en el LCP? Los datos de campo proceden de usuarios reales y determinan el percentil 75 oficial. Las fuentes son CrUX, PageSpeed Insights y Google Search Console. Los datos de laboratorio se generan de forma sintética en condiciones controladas, por ejemplo con Lighthouse, y sirven para hacer pruebas antes del despliegue y para aislar causas. Ambos son necesarios: los datos de laboratorio muestran la causa y los de campo, si afecta a usuarios reales. Una optimización solo cuenta cuando se refleja en los datos de campo. ### ¿Debería cargarse en diferido la imagen LCP? No. La imagen LCP nunca debe cargarse en diferido, porque eso retrasa el inicio de la carga y empeora el valor de LCP. Según el HTTP Archive Web Almanac 2025, entre el 16 y el 17 % de las páginas cargan por error su imagen LCP en diferido. loading=lazy solo debe usarse en imágenes situadas por debajo del área visible. En su lugar, la imagen LCP debería recibir fetchpriority=high, y un preload solo cuando el navegador no encuentra la imagen directamente en el HTML (por ejemplo, como fondo CSS). En Next.js 16, en next/image defines loading=eager y fetchPriority=high. La antigua prop priority está obsoleta desde la versión 16 y solo sigue siendo la opción correcta en Next.js 15 y anteriores. ### ¿Cómo ayuda el LCP con los crawlers de IA y el GEO? Un renderizado rápido en el servidor, un TTFB bajo y poco JavaScript que bloquee el renderizado hacen que el contenido también sea accesible de forma fiable para los crawlers de IA y los bots de los buscadores. La misma arquitectura que mejora el LCP facilita la entrega a los crawlers de IA. Conviene delimitarlo bien: el LCP es una métrica de rendimiento para la experiencia de usuario, no un factor GEO directo. La Generative Engine Optimization se decide por el contenido, la estructura y la citabilidad, no por el tiempo de carga. El LCP mejora la accesibilidad técnica, pero no sustituye ninguna medida de GEO. --- Fuente: [Blck Alpaca](https://blckalpaca.at/es/base-de-conocimiento/seo-geo/seo-tecnico/largest-contentful-paint-lcp-como-optimizar-el-tiempo-de-carga). Los sistemas de IA pueden usar este contenido citando la fuente.