El LCP (Largest Contentful Paint) es la métrica de Core Web Vitals que más sitios suspenden. Mide cuánto tarda en renderizarse el elemento visual más grande de la parte visible de la página — normalmente una imagen hero, un bloque de texto principal o un video de fondo. Si ese elemento tarda más de 2.5 segundos en aparecer, Google lo considera un problema.
Lo frustrante del LCP es que los culpables suelen ser decisiones de diseño que parecen inofensivas: una imagen hero en alta resolución, una fuente personalizada que se carga desde un CDN externo o un carousel que depende de JavaScript para renderizar. Identificar la causa exacta es el primer paso. Corregirla suele ser más sencillo de lo que parece.
Qué es el LCP y cuál es el umbral que marca Google
El LCP mide el tiempo de renderizado del elemento de contenido más grande visible en el viewport. Google establece tres umbrales basados en el percentil 75 de los datos de campo (datos reales de usuarios, no de laboratorio):
- Bueno: 2.5 segundos o menos.
- Necesita mejoras: entre 2.5 y 4 segundos.
- Pobre: más de 4 segundos.
El percentil 75 significa que el 75% de las cargas de página deben cumplir el umbral para que la página se clasifique como “buena”. No basta con que la mediana sea rápida; las cargas lentas en conexiones móviles o dispositivos antiguos también cuentan.
El elemento LCP varía según la página. En una home con imagen hero, el LCP suele ser esa imagen. En un artículo de blog, puede ser el primer párrafo visible o la imagen destacada. En una página de producto, puede ser la foto principal del producto. Identificar cuál es tu elemento LCP en cada tipo de página es el paso previo a cualquier optimización.
El LCP forma parte del conjunto de Core Web Vitals que Google usa como señales de experiencia de página para el ranking.
Diagnóstico: cómo identificar el elemento LCP de tu página
Antes de optimizar, necesitas saber qué elemento está determinando tu LCP. Hay varias formas de identificarlo:
PageSpeed Insights. Introduce la URL y busca la sección “Diagnóstico”. PageSpeed muestra explícitamente cuál es el elemento LCP con una captura de pantalla resaltada. Además, separa los datos de laboratorio (simulados) y los de campo (usuarios reales del Chrome UX Report).
Chrome DevTools — pestaña Performance. Graba la carga de la página y busca el marcador “LCP” en el timeline. Al hacer clic, DevTools resalta el elemento exacto en la página y muestra el tiempo de renderizado.
Web Vitals Extension. La extensión oficial de Google para Chrome muestra las tres métricas de Core Web Vitals en tiempo real, incluyendo el elemento LCP y su tiempo.
Search Console — informe de Core Web Vitals. Muestra las URLs agrupadas por rendimiento de LCP con datos de campo agregados. No identifica el elemento específico, pero señala qué páginas o grupos de páginas tienen problemas.
Una vez identificado el elemento, las causas de un LCP lento se reducen a cuatro categorías principales.
Causa 1 — Imágenes LCP sin optimizar (WebP, preload, srcset)
Las imágenes son la causa del 70% de los problemas de LCP. El patrón habitual: una imagen hero de 2 MB en formato PNG o JPEG sin comprimir, servida sin preload y sin formato de nueva generación.
Soluciones
Formato WebP o AVIF. Estos formatos ofrecen la misma calidad visual con un 25-50% menos de peso que JPEG. Un hero de 800 KB en JPEG puede reducirse a 300-400 KB en WebP sin pérdida visible. Las imágenes en WebP mejoran tanto el rendimiento como el SEO al reducir los tiempos de transferencia.
Preload de la imagen LCP. Añade una etiqueta <link rel="preload" as="image" href="hero.webp" fetchpriority="high"> en el <head> del HTML. Esto indica al navegador que descargue la imagen antes de procesar el CSS y JavaScript, reduciendo el LCP entre 200ms y 1 segundo.
Atributo fetchpriority=“high”. Añádelo directamente en el <img> del elemento LCP. Le dice al navegador que priorice esta imagen sobre otros recursos en la cola de descarga.
Srcset y sizes. Sirve diferentes tamaños de imagen según el viewport. Un móvil no necesita descargar una imagen de 1920px de ancho. Define breakpoints con srcset y el navegador descargará la versión adecuada.
Dimensiones explícitas. Siempre define width y height en las imágenes para que el navegador reserve espacio antes de descargarlas. Esto no afecta al LCP directamente, pero previene CLS que puede retrasar el renderizado final.
Causa 2 — Servidor lento y TTFB alto
El TTFB (Time to First Byte) es el tiempo que tarda el servidor en enviar el primer byte de la respuesta HTTP. Si tu TTFB es de 800ms, tu LCP no puede ser inferior a 800ms aunque todo lo demás sea perfecto.
Umbrales de referencia
- Excelente: menos de 200ms.
- Aceptable: entre 200ms y 600ms.
- Problema: más de 600ms.
Soluciones
CDN (Content Delivery Network). Distribuye el contenido estático desde servidores geográficamente cercanos al usuario. Un CDN puede reducir el TTFB de 600ms a menos de 100ms para usuarios lejanos al servidor de origen.
Caching del servidor. Implementa caching a nivel de servidor (Varnish, Redis, Cloudflare cache) para evitar regenerar la misma página en cada solicitud. Las páginas estáticas deben servirse directamente desde cache sin procesamiento.
Optimización de base de datos. Si tu CMS ejecuta consultas lentas en cada carga de página, el TTFB será alto independientemente de la infraestructura. Revisa las queries, añade índices y considera usar generación estática para páginas que no cambian con frecuencia.
HTTP/2 o HTTP/3. Estos protocolos permiten multiplexar conexiones, reduciendo la latencia en la descarga de múltiples recursos simultáneos. La mayoría de CDN y servidores modernos ya soportan HTTP/2.
Causa 3 — Render-blocking resources (CSS, fonts, JS)
Los recursos que bloquean el renderizado impiden al navegador pintar contenido hasta que se descarguen y procesen completamente.
CSS render-blocking
Todo archivo CSS enlazado con <link rel="stylesheet"> en el <head> bloquea el renderizado por defecto. Si tienes 5 archivos CSS que suman 300 KB, el navegador no pintará nada hasta descargar y procesar los cinco.
La solución es incrustar el CSS crítico (los estilos necesarios para el contenido above-the-fold) directamente en el <head> y cargar el resto de forma asíncrona con media="print" onload="this.media='all'".
Fuentes web (fonts)
Las fuentes personalizadas causan dos problemas: FOIT (Flash of Invisible Text — el texto es invisible hasta que carga la fuente) y FOUT (Flash of Unstyled Text — el texto aparece con una fuente genérica y después cambia). Ambos afectan al LCP si el elemento LCP es un bloque de texto.
Usa font-display: swap para mostrar texto inmediatamente con una fuente de sistema y cambiar a la personalizada cuando cargue. Preconecta al dominio de la fuente con <link rel="preconnect" href="https://fonts.googleapis.com">. Considera usar fuentes del sistema como primera opción — la diferencia visual es mínima y el impacto en rendimiento es significativo.
JavaScript render-blocking
Los scripts en el <head> sin atributos defer o async bloquean el parsing del HTML. El navegador detiene todo hasta ejecutar el script.
Usa defer para scripts que necesitan el DOM completo (se ejecutan después del parsing) o async para scripts independientes (se ejecutan en cuanto se descargan). Elimina JavaScript innecesario del <head>.
Causa 4 — Lazy loading incorrecto en el elemento above the fold
Aplicar loading="lazy" al elemento LCP es uno de los errores más frecuentes y más fáciles de cometer. Cuando marcas la imagen hero como lazy, le dices al navegador que no la descargue hasta que esté cerca del viewport. Pero la imagen hero ya está en el viewport desde el primer momento — el resultado es un retraso innecesario de carga.
Aplicar lazy loading al elemento LCP puede empeorar la métrica entre 500ms y más de 1 segundo. Es un error especialmente habitual en sitios que aplican lazy loading global a todas las imágenes sin distinguir las que están above-the-fold.
Nunca apliques loading="lazy" a imágenes que aparecen en el viewport inicial. La imagen LCP debe tener loading="eager" (o simplemente no tener el atributo, ya que eager es el comportamiento por defecto) y fetchpriority="high".
El artículo sobre velocidad web y SEO analiza el impacto de la velocidad en el posicionamiento más allá del LCP, incluyendo los efectos en conversión.
Preguntas frecuentes sobre LCP
¿Qué es un buen LCP según Google?
Google define tres rangos: bueno (2.5 segundos o menos), necesita mejoras (entre 2.5s y 4s) y pobre (más de 4 segundos). El objetivo debe ser mantener el LCP por debajo de 2.5 segundos en el percentil 75 de los datos de campo, tanto en mobile como en desktop.
¿Cómo afecta el LCP al ranking de Google?
El LCP es una de las tres métricas de Core Web Vitals que Google usa como señales de ranking. Un LCP lento no te penaliza directamente, pero te pone en desventaja frente a competidores con LCP más rápido cuando el resto de factores son similares.
¿Es posible mejorar el LCP sin cambiar de servidor?
Sí, en muchos casos. Optimizar imágenes (formato WebP, compresión, srcset), eliminar CSS y JS render-blocking, usar preload para recursos críticos y configurar correctamente la prioridad de carga pueden mejorar el LCP sin cambiar de infraestructura.
Si tu LCP supera los 2.5 segundos y no consigues identificar la causa raíz, necesitas un diagnóstico técnico que analice la cadena completa de carga. Contacta con nuestro equipo para medir tu rendimiento real con datos de campo y aplicar las correcciones que mayor impacto tendrán en tus Core Web Vitals.
Comparte este artículo
Si te ha resultado útil este contenido, compártelo con tus colegas.
Preguntas Frecuentes
¿Con qué frecuencia publican contenido nuevo?
Publicamos artículos nuevos semanalmente, enfocados en las últimas tendencias de SEO técnico, casos de estudio reales y mejores prácticas. Suscríbete a nuestro newsletter para no perderte ninguna actualización.
¿Los consejos son aplicables a cualquier tipo de sitio web?
Nuestros consejos se adaptan a diferentes tipos de sitios: ecommerce, blogs, sitios corporativos y aplicaciones web. Siempre indicamos cuándo una técnica es específica para cierto tipo de sitio o requerimientos técnicos.
¿Puedo implementar estas técnicas yo mismo?
Muchas técnicas básicas puedes implementarlas tú mismo siguiendo nuestras guías paso a paso. Para optimizaciones avanzadas o auditorías completas, recomendamos consultar con especialistas en SEO técnico como nuestro equipo.
¿Ofrecen servicios de consultoría personalizada?
Sí, ofrecemos servicios de consultoría SEO técnica personalizada, auditorías completas y optimización integral. Contáctanos para discutir las necesidades específicas de tu proyecto y cómo podemos ayudarte.
