LCP: cómo optimizar el Largest Contentful Paint

El Largest Contentful Paint (LCP) es la métrica de Core Web Vitals que influye en el posicionamiento de Google desde 2021. No es solo un número técnico: refleja lo rápido que el usuario percibe que la página ha cargado. Un LCP malo significa que los visitantes ven una pantalla en blanco o una imagen principal sin cargar, y se van antes de que aparezca el contenido.

zoom_in

Qué es el LCP y por qué importa

El LCP mide el tiempo desde el inicio de la navegación hasta que el elemento de contenido más grande (texto o imagen) se vuelve visible en el viewport. Es el umbral que Google usa para considerar que la carga ha terminado desde el punto de vista de la experiencia de usuario.

A diferencia del FCP (First Contentful Paint), que se dispara con el primer píxel, el LCP registra específicamente el contenido relevante. Una página puede mostrar un spinner a los 0,3 s, pero si la imagen principal aparece a los 5 s, el LCP es de 5 s.

Qué elementos considera el navegador candidatos a LCP

El navegador no registra todos los elementos: observa tipos concretos y, cuando termina la carga, selecciona el de mayor área dentro del viewport.

Elementos <img>

Imágenes estándar. El candidato a LCP más común en la mayoría de las páginas. Tiempo = momento en que la imagen decodificada aparece en el viewport.

<image> dentro de SVG

Imágenes dentro de elementos SVG. Para el LCP se tratan igual que los elementos img normales.

background-image de CSS

Imágenes de fondo mediante CSS. Matiz clave: el navegador no empieza a cargar una background-image hasta que se construye el CSSOM. Es una de las principales causas del retraso del LCP.

Bloques de texto

Elementos <p>, <h1>–<h6>, <div> y otros con contenido de texto. Si un bloque de texto es más grande que cualquier imagen, se convierte en el LCP.

<video> con poster

El fotograma del atributo poster de un elemento video. Si el vídeo ocupa la mayor parte de la pantalla, el poster debe cargar lo antes posible.

Cómo se divide el tiempo de LCP

Google descompone el LCP en 4 subcomponentes. Entender cada uno es clave para diagnosticar y priorizar las optimizaciones con precisión.

Regla: ataca el componente con mayor peso. Si el TTFB supone 3 de los 5 segundos del LCP, optimizar imágenes apenas tendrá efecto. Primero arregla el tiempo de respuesta del servidor.

Causas principales de un LCP lento

El 90 % de los LCP malos comparten las mismas causas raíz. El diagnóstico lleva 15 minutos en DevTools o en PageSpeed Insights.

Cómo optimizar el LCP: plan paso a paso

Optimizar el LCP no es un truco único, sino un conjunto de mejoras relacionadas entre sí. Trabaja en orden, empezando por las de mayor impacto.

Paso 1: reduce el TTFB a 200–400 ms

El TTFB es la base. Si el servidor es lento, todas las demás optimizaciones chocan contra ese techo.

1. Configura la caché HTTP: Cache-Control: max-age=31536000 para los recursos estáticos y s-maxage para los proxies de CDN.
2. Activa la compresión: Brotli (preferido) o gzip para HTML, CSS y JS. Brotli entrega archivos entre un 15 y un 25 % más pequeños que gzip.
3. Conecta un CDN: Cloudflare, Fastly, BunnyCDN. En sitios estáticos, la caché en el edge reduce el TTFB a 20–50 ms.
4. Optimiza la base de datos: índices en los campos que más se consultan y caché de consultas con Redis o Memcached.
5. Usa HTTP/2 o HTTP/3: varias peticiones por una única conexión, sin bloqueo head-of-line.

Paso 2: optimiza la imagen del LCP

Si el elemento del LCP es una imagen (principal, de producto), esta es una rama de optimización de alto retorno.

• Pasa a formatos modernos: WebP (entre un 25 y un 35 % de ahorro frente a JPEG) o AVIF (entre un 40 y un 55 %). Usa <picture> con un respaldo.
• Añade fetchpriority="high" a la imagen del LCP: el navegador la cargará con máxima prioridad.
• Quita loading="lazy" del elemento del LCP. La carga diferida solo tiene sentido para imágenes que quedan debajo del primer viewport.
• Añade <link rel="preload" as="image"> en <head> para la imagen del LCP: el navegador empieza a cargarla antes de que termine de analizarse el body.
• Indica los atributos width y height para evitar el CLS. El navegador reserva el espacio antes de que cargue la imagen.
• Configura srcset y sizes para una carga adaptada: en móvil se sirve una imagen de 400 px en lugar de una de 1600 px.

Paso 3: elimina los recursos que bloquean el renderizado

Cada recurso que bloquea el renderizado añade retraso al LCP. El objetivo: cero recursos bloqueantes en la ruta crítica.

Paso 4: optimiza las fuentes (cuando el LCP es texto)

Cuando el elemento del LCP es un bloque de texto (título o entradilla), el problema suele ser el retraso en el renderizado de la fuente.

1. Añade font-display: swap u optional a @font-face. El navegador muestra al instante la fuente del sistema y cambia a la personalizada cuando termina de cargar.
2. Usa <link rel="preload" as="font" type="font/woff2" crossorigin> para las fuentes críticas en <head>.
3. Limita el juego de caracteres: usa subsetting para cargar solo los glifos necesarios (latino, cirílico).
4. Aloja las fuentes en tu propio servidor en lugar de cargarlas desde Google Fonts: así se elimina una búsqueda DNS y una conexión adicionales.
5. Configura size-adjust, ascent-override y descent-override en @font-face para reducir el CLS durante el cambio de fuente.

Paso 5: SSR/SSG para frameworks de JavaScript

Si el sitio funciona con React, Vue o Next.js sin SSR, el LCP será alto por defecto: el navegador tiene que descargar y ejecutar el JavaScript antes de renderizar el contenido.

Renderizado en el servidor (SSR)

El HTML se genera en el servidor en cada petición. El navegador recibe el HTML ya listo, lo analiza y el elemento del LCP aparece sin esperar al JS. Es la mejor opción para contenido dinámico.

Generación de sitios estáticos (SSG)

El HTML se genera en el momento de la compilación. El servidor entrega un archivo ya listo, con la máxima velocidad de TTFB y LCP. Ideal para blogs, landing pages y páginas no personalizadas.

Regeneración estática incremental (ISR)

SSG con regeneración periódica (Next.js). Combina la velocidad de los archivos estáticos con la actualidad de los datos. Óptima para la mayoría del contenido de un CMS.

SSR en streaming

El servidor empieza a enviar el HTML antes de terminar el renderizado, así que el navegador muestra el contenido de forma progresiva. React 18 y Next.js 13+ lo soportan de serie.

Paso 6: background-image de CSS como LCP

Si el elemento del LCP usa una background-image de CSS, el navegador no puede empezar a cargarla hasta que se construye el CSSOM. Es una de las causas más traicioneras de un LCP lento.

• Sustituye la background-image de CSS por <img fetchpriority="high">: el navegador la descubre durante el análisis del HTML.
• Si no es posible sustituirla, usa <link rel="preload" as="image"> para iniciar la carga manualmente.
• Para fondos adaptables, usa imagesrcset e imagesizes en la etiqueta preload.
• Mueve el CSS que contiene la background-image del LCP a un <style> en línea: así se elimina una petición de red.

Herramientas para medir y diagnosticar el LCP

Un diagnóstico correcto importa más que optimizar a ciegas. Usa los dos tipos de herramientas: de laboratorio (pruebas sintéticas) y de campo (usuarios reales).

Cómo diagnosticar el LCP en Chrome DevTools

DevTools es la herramienta más precisa para entender qué frena exactamente el LCP en una página concreta.

1. Abre DevTools → Performance, pulsa Record, recarga la página y detén la grabación.
2. En Timings, busca el marcador del LCP: muestra el tiempo exacto y el elemento.
3. Analiza la cascada: localiza el recurso del elemento del LCP y comprueba cuándo empezó a cargarse respecto al TTFB.
4. Busca las barras rojas: son recursos que bloquean el renderizado y aparecen justo antes del LCP.
5. En la pestaña Network, filtra por tipo Image, localiza la imagen del LCP y comprueba su prioridad (debe ser High).
6. En la pestaña Coverage verás el CSS y el JS sin usar. Una gran cantidad de código sin usar significa retraso del LCP.

Preguntas frecuentes