El umbral de 2,5 segundos que decide la visibilidad de tu página
Imagina la siguiente situación: un usuario busca “zapatillas running pronación” en Google, hace clic en tu página de producto y durante 3,8 segundos ve una pantalla en blanco o un layout parcial sin la imagen principal. Según datos de Think with Google, la probabilidad de que ese usuario abandone la página ha crecido un 32% solo por haber superado los 3 segundos de espera. Ese elemento visual que no cargó a tiempo — la imagen hero, el banner principal, el vídeo de cabecera — es exactamente lo que Google mide con el LCP.
El Largest Contentful Paint es la métrica de Core Web Vitals que cuantifica cuánto tarda en renderizarse el elemento visual más grande visible en el viewport. Google establece un umbral claro: por debajo de 2,5 segundos es bueno, entre 2,5 y 4 segundos necesita mejora, y por encima de 4 segundos es deficiente. En 2026, según HTTPArchive, solo el 58% de los sitios web a nivel global consiguen un LCP inferior a 2,5 segundos en móvil, lo que significa que el 42% restante está entregando una experiencia que Google considera mejorable o directamente mala.
Lo relevante para el SEO es que Google evalúa el LCP con datos de campo reales — el percentil 75 de las visitas recogidas por Chrome UX Report durante los últimos 28 días — y lo utiliza como señal de ranking dentro de la experiencia de página. No es un factor teórico: es una métrica que Googlebot consulta antes de decidir qué posición merece tu página en los resultados.
Diagnóstico: cómo identificar el elemento LCP de tu página
Antes de optimizar el LCP, necesitas saber con exactitud qué elemento está siendo medido. El error más frecuente es asumir que el LCP corresponde siempre a la imagen hero, cuando en realidad depende del contenido visible en el viewport al momento de la carga. En una página de blog, el elemento LCP puede ser un bloque de texto H1. En una ficha de producto, suele ser la imagen principal. En una landing page, puede ser un vídeo o un banner promocional.
Chrome DevTools ofrece el diagnóstico más directo. Abre la pestaña Performance, graba una carga de página y busca el marcador LCP en la sección Timings. DevTools te señala exactamente qué nodo del DOM es el elemento LCP, cuánto tardó en renderizarse y qué recursos estaban en la ruta crítica. Este diagnóstico en laboratorio es el punto de partida, pero no sustituye a los datos de campo.
PageSpeed Insights (pagespeed.web.dev) combina datos de laboratorio con datos de campo de CrUX. La sección “Diagnóstico” identifica el elemento LCP y las oportunidades de mejora ordenadas por impacto estimado. El dato más valioso es el LCP de campo (el percentil 75 real) porque es el que Google utiliza para ranking.
Google Search Console reporta el estado de los Core Web Vitals a nivel de dominio, agrupando URLs con experiencia similar. Si ves un grupo de URLs marcadas como “Deficiente” en LCP, es probable que compartan una causa raíz: el mismo template, las mismas imágenes sin optimizar, el mismo servidor lento.
La Web Vitals Extension de Chrome muestra el LCP en tiempo real mientras navegas, marcando visualmente el elemento medido. Es la forma más rápida de verificar qué elemento está siendo evaluado en cualquier página.
Un diagnóstico completo debe cubrir tanto desktop como móvil, porque el elemento LCP puede variar entre dispositivos. Una imagen que en desktop es la tercera más grande del viewport puede ser el elemento dominante en la vista móvil, alterando completamente el LCP reportado.
Causa 1 — Imágenes LCP sin optimizar (WebP, preload, srcset)
Las imágenes son responsables del 72% de los elementos LCP en la web, según un análisis de HTTPArchive sobre 8 millones de URLs publicado en 2025. Esto convierte a la optimización de imágenes en la acción de mayor impacto para mejorar el LCP en la mayoría de los sitios.
Los problemas de imagen que causan un LCP lento se agrupan en cuatro categorías:
Formato inadecuado. Servir imágenes en JPEG o PNG cuando WebP ofrece una reducción de tamaño del 25-35% y AVIF del 40-50% sin pérdida perceptible de calidad. En 2026, WebP tiene un soporte del 97% en navegadores y AVIF del 92%, lo que elimina las excusas técnicas para no usarlos. Un retailer europeo reportó que migrar sus imágenes de producto de JPEG a WebP redujo el peso medio de imagen de 380 KB a 112 KB, mejorando el LCP de 3,2 a 2,1 segundos en conexiones 4G.
Ausencia de preload. El navegador no puede solicitar una imagen hasta que descubre la etiqueta <img> o la referencia CSS que la contiene, lo que ocurre después de parsear el HTML y potencialmente después de descargar y procesar hojas de estilo. Añadir <link rel="preload" as="image" href="hero.webp"> en el <head> permite al navegador comenzar la descarga inmediatamente, sin esperar al descubrimiento natural. Según web.dev, el preload de la imagen LCP puede ahorrar entre 200 y 600 ms en conexiones típicas de móvil.
Falta de srcset y sizes. Servir la misma imagen de 1920px a un dispositivo móvil de 375px de ancho es desperdiciar hasta el 80% del ancho de banda. El atributo srcset con múltiples resoluciones y sizes con las dimensiones reales del elemento permite al navegador seleccionar la imagen más adecuada. La combinación de WebP + srcset es la optimización de imagen más completa.
Dimensiones no declaradas. Las imágenes sin atributos width y height explícitos obligan al navegador a recalcular el layout cuando la imagen carga, generando no solo un LCP tardío sino también CLS adicional.
Causa 2 — Servidor lento y TTFB alto
El Time to First Byte (TTFB) es el tiempo que transcurre desde que el navegador envía la solicitud HTTP hasta que recibe el primer byte de respuesta del servidor. Es el punto de partida de toda la cascada de carga: si el TTFB es lento, absolutamente todo lo demás se retrasa proporcionalmente.
Google recomienda un TTFB inferior a 800 ms como objetivo, y web.dev lo documenta como una de las sub-métricas más determinantes del LCP. La razón es matemática: si el servidor tarda 1.200 ms en responder, el navegador tiene menos de 1.300 ms para descargar, parsear y renderizar todo el contenido visible antes de superar el umbral de 2,5 segundos del LCP. En la práctica, con ese TTFB, es casi imposible conseguir un buen LCP.
Las causas de un TTFB alto son variadas pero bien documentadas. Los servidores compartidos de bajo coste suelen tener tiempos de respuesta entre 800 y 2.000 ms durante picos de tráfico. Los CMS como WordPress con múltiples plugins que ejecutan consultas a base de datos en cada petición pueden añadir 300-800 ms al TTFB. Las aplicaciones con renderizado dinámico que no implementan caché a nivel de servidor regeneran toda la página en cada visita.
Las soluciones escalan en complejidad y coste:
CDN (Content Delivery Network): Distribuir el contenido desde servidores geográficamente cercanos al usuario puede reducir el TTFB entre 100 y 400 ms. Cloudflare, Fastly y AWS CloudFront son las opciones más comunes. Para sitios estáticos o con caché agresiva, el CDN es la solución de mayor impacto-coste.
Caché a nivel de servidor: Implementar caché de página completa (full-page cache) con Varnish, Redis o el propio caché del CDN elimina la necesidad de generar la página dinámicamente en cada petición. Un sitio WordPress con WP Super Cache o LiteSpeed Cache puede reducir su TTFB de 1.200 ms a 150 ms.
Upgrade de hosting: Cuando el servidor es el cuello de botella real — CPU insuficiente, memoria limitada, discos lentos — la única solución es migrar a un hosting con más recursos. Los VPS con NVMe y 4+ GB de RAM suelen ofrecer TTFB consistentemente por debajo de 300 ms.
Generación estática (SSG): Para sitios cuyo contenido no cambia en cada petición — blogs, documentación, catálogos con actualizaciones periódicas — generar el HTML en tiempo de build elimina completamente el procesamiento en servidor. Frameworks como Astro, Next.js (export estático) o Hugo entregan TTFB de 20-80 ms desde CDN.
Mejorar la velocidad web requiere abordar el TTFB como primer paso, ya que condiciona el techo de rendimiento de todas las demás optimizaciones.
Causa 3 — Render-blocking resources (CSS, fonts, JS)
Incluso con imágenes optimizadas y un TTFB rápido, el LCP puede ser alto si recursos en la ruta crítica de renderizado bloquean al navegador. Los tres tipos de recursos que más frecuentemente causan bloqueo son las hojas de estilo CSS, las fuentes web y los scripts JavaScript síncronos.
CSS render-blocking. Las hojas de estilo son render-blocking por defecto: el navegador no pintará ningún contenido hasta que haya descargado y procesado todas las hojas CSS referenciadas en el <head>. En sitios con múltiples archivos CSS o una sola hoja de 200+ KB sin minificar, este bloqueo puede añadir 300-800 ms al LCP. Las soluciones incluyen: inlinear el CSS crítico (el necesario para el contenido above the fold) en el <head>, cargar el resto con media="print" onload="this.media='all'", y eliminar CSS no utilizado con herramientas como PurgeCSS. Según datos de web.dev, la extracción de CSS crítico puede reducir el LCP entre 150 y 500 ms.
Fuentes web bloqueantes. Las fuentes personalizadas se descargan después de que el navegador procesa el CSS que las referencia. Sin la directiva font-display: swap, el navegador puede ocultar el texto durante la descarga de la fuente, causando un flash de texto invisible (FOIT) que retrasa el LCP si el elemento principal es texto. La directiva swap indica al navegador que muestre el texto con una fuente de sistema inmediatamente y cambie a la fuente personalizada cuando esté disponible. Combinada con <link rel="preload" as="font" crossorigin>, esta configuración puede reducir el impacto de las fuentes en el LCP en 100-300 ms.
JavaScript síncrono. Los scripts sin atributos async o defer bloquean tanto el parsing del HTML como el renderizado. Un script de analytics de 150 KB cargado de forma síncrona en el <head> puede retrasar todo el renderizado de la página en 200-500 ms. La solución es cargar scripts de terceros con defer (se ejecutan tras el parsing) o async (se ejecutan cuando terminan de descargarse), y mover los scripts que no son necesarios para el renderizado inicial al final del <body>.
La herramienta más eficaz para diagnosticar recursos bloqueantes es la pestaña Coverage de Chrome DevTools, que muestra exactamente cuántos bytes de cada archivo CSS o JS se utilizan realmente durante la carga de la página. Porcentajes de uso inferiores al 30% indican archivos que son candidatos a optimización o división en chunks.
Causa 4 — Lazy loading incorrecto en el elemento above the fold
Esta es la causa de LCP lento más irónica porque se origina en una buena intención. El lazy loading con loading="lazy" es una técnica de optimización legítima que retrasa la carga de imágenes fuera del viewport hasta que el usuario se desplaza hacia ellas, ahorrando ancho de banda y acelerando la carga inicial. El problema surge cuando se aplica indiscriminadamente a todas las imágenes, incluida la imagen que es el elemento LCP.
Cuando el atributo loading="lazy" está presente en la imagen hero — la que generalmente es el elemento LCP — el navegador la excluye intencionalmente de la carga prioritaria. En lugar de comenzar su descarga inmediatamente, espera a confirmar que está en el viewport, añadiendo un retraso de 200-500 ms que se suma directamente al LCP.
Google documenta este problema de forma explícita en su guía de optimización del LCP en web.dev: “No uses lazy-load en imágenes que están en el viewport. Esto es particularmente importante para el elemento Largest Contentful Paint.” La recomendación es clara: el atributo loading="lazy" nunca debe aplicarse a imágenes above the fold, y el elemento LCP debería tener loading="eager" (o simplemente no tener el atributo, ya que eager es el comportamiento por defecto) junto con fetchpriority="high".
Un patrón que se repite en CMSs y frameworks es la aplicación automática de loading="lazy" a todas las etiquetas <img> generadas por el sistema. WordPress, por ejemplo, añadió lazy loading nativo a todas las imágenes a partir de la versión 5.5, y aunque versiones posteriores excluyeron la primera imagen del contenido, muchos temas y plugins sobrescriben este comportamiento. Auditar el HTML renderizado — no el código fuente del template — es imprescindible para detectar este problema.
La combinación óptima para la imagen LCP es: formato WebP o AVIF, preload con <link rel="preload"> en el <head>, atributo fetchpriority="high", sin loading="lazy", y con width y height explícitos. Esta configuración garantiza que el navegador prioriza la imagen LCP desde el primer momento del parsing.
Checklist de optimización LCP en 30 minutos
Esta checklist está ordenada por impacto descendente. Cada paso incluye la herramienta de diagnóstico y la acción correctiva. Un profesional familiarizado con las herramientas puede completar todo el proceso en una sesión de 30 minutos.
Paso 1: Identificar el elemento LCP (2 minutos). Abre Chrome DevTools → Performance → graba la carga → busca el marcador LCP en Timings. Anota qué elemento del DOM es el LCP y cuál es el tiempo actual.
Paso 2: Verificar el formato y tamaño de imagen (5 minutos). Si el elemento LCP es una imagen, comprueba su formato (WebP o AVIF preferible), su peso (objetivo: menos de 150 KB para hero en móvil), y si tiene srcset con múltiples resoluciones. Usa Squoosh (squoosh.app) para comparar formatos y calidades.
Paso 3: Verificar preload y fetchpriority (3 minutos). Inspecciona el <head> del HTML renderizado. El elemento LCP debe tener un <link rel="preload"> correspondiente si es una imagen. El atributo fetchpriority="high" debe estar en la etiqueta del elemento LCP. Verifica que no tenga loading="lazy".
Paso 4: Medir el TTFB (3 minutos). En la pestaña Network de DevTools, observa el primer documento HTML. El timing “Waiting for server response” es tu TTFB. Si supera los 800 ms, la solución requiere caché de servidor o CDN antes de optimizar otros aspectos.
Paso 5: Auditar recursos render-blocking (5 minutos). En PageSpeed Insights, revisa las secciones “Eliminate render-blocking resources” y “Reduce unused CSS/JS”. En DevTools → Coverage, identifica archivos CSS y JS con uso inferior al 30%.
Paso 6: Verificar fuentes web (3 minutos). Comprueba que todas las declaraciones @font-face incluyan font-display: swap. Verifica si las fuentes tienen preload. Considera usar fuentes de sistema para el contenido above the fold.
Paso 7: Medir el resultado (5 minutos). Repite la medición en DevTools y verifica el LCP. Compara con la medición inicial. Para datos de campo, la actualización en CrUX tarda 28 días, pero PageSpeed Insights muestra una estimación inmediata basada en lab data.
Paso 8: Documentar y monitorizar (4 minutos). Registra los cambios realizados, el LCP antes y después, y configura alertas en Google Search Console para detectar regresiones futuras en Core Web Vitals.
La optimización del LCP no es un proyecto único sino un proceso continuo. Cada actualización de contenido, cada nuevo script de terceros, cada cambio en el hosting puede afectar al LCP. Incorporar la verificación de Core Web Vitals en el flujo de deployment (automatizada con Lighthouse CI o Web Vitals Reporter) es la forma más fiable de mantener el rendimiento a largo plazo.