Core Web Vitals: Cómo Optimizar LCP

Sep 22, 2025 · 4 min read

Largest Contentful Paint (LCP) mide qué tan rápido carga tu contenido principal: la imagen hero, el titular o el video que los visitantes ven primero. Cuando esto toma más de 2.5 segundos, los usuarios perciben tu sitio como lento, las tasas de rebote aumentan y tus puntuaciones de Core Web Vitals se ven afectadas. Esta guía desglosa exactamente cómo diagnosticar y solucionar problemas de LCP a través de las cuatro fases del proceso de carga.

Puntos Clave

LCP mide el tiempo de renderizado del elemento de contenido visible más grande antes de la interacción del usuario
Google requiere que el 75% de las visitas a la página logren un LCP menor a 2.5 segundos para obtener buenos Core Web Vitals
La optimización involucra cuatro fases: TTFB, descubrimiento de recursos, duración de carga y retraso de renderizado
Nunca uses lazy-loading en contenido above-the-fold—es el error más común de LCP

¿Qué es Largest Contentful Paint (LCP)?

LCP rastrea el tiempo de renderizado del elemento de contenido visible más grande en el viewport antes de la interacción del usuario. Esto podría ser un <img>, <video> o bloque de texto. A diferencia de métricas abstractas, LCP refleja lo que los usuarios realmente experimentan: cuando la página “se siente” cargada.

Google establece umbrales claros:

Bueno: Menos de 2.5 segundos
Necesita Mejora: 2.5-4.0 segundos
Pobre: Más de 4.0 segundos

Para aprobar Core Web Vitals, el 75% de las visitas a tu página deben lograr puntuaciones LCP “buenas”. Esto impacta directamente los rankings SEO, ya que Google usa Core Web Vitals como señal de ranking.

Las Cuatro Fases de Optimización LCP

LCP no es una métrica única—es la suma de cuatro fases distintas. Entender este desglose es crucial para una optimización dirigida:

Time to First Byte (TTFB): Tiempo de respuesta del servidor (~40% del LCP total)
Retraso de Carga de Recursos: Tiempo entre TTFB e inicio de descarga del recurso LCP (<10%)
Duración de Carga de Recursos: Tiempo real de descarga (~40%)
Retraso de Renderizado de Elementos: Tiempo desde completar la descarga hasta el renderizado visual (<10%)

Las fases de “retraso” deberían acercarse a cero. Cualquier tiempo de espera es puro desperdicio.

Fase 1: Optimizar el Tiempo de Respuesta del Servidor (TTFB)

Un TTFB lento socava todo lo demás. Si tu servidor toma 3 segundos en responder, lograr un LCP de 2.5 segundos se vuelve imposible.

Problemas comunes de TTFB:

Múltiples redirecciones (cada una añade 100-500 milisegundos)
Servidores distantes de los usuarios
Código backend ineficiente
Cuellos de botella en la base de datos

Soluciones:

Implementar caché del lado del servidor
Usar un CDN para servir contenido desde ubicaciones edge
Minimizar redirecciones—usar el formato de URL final directamente
Optimizar consultas de base de datos y procesamiento backend

Consejo profesional: Los CDNs pueden enmascarar problemas del servidor. Prueba con parámetros de URL (ej., ?test=123) para evitar cachés CDN y revelar el rendimiento real del servidor.

Fase 2: Eliminar Retrasos de Descubrimiento de Recursos

El navegador debe encontrar tu recurso LCP inmediatamente. Cualquier retraso de descubrimiento es tiempo perdido.

Error crítico: Aplicar lazy-loading a la imagen LCP. Nunca uses loading="lazy" en contenido above-the-fold—retrasa intencionalmente tu elemento más importante.

Hacer recursos descubribles:

<!-- Bueno: Imagen en HTML -->
<img fetchpriority="high" src="/hero.webp" alt="...">

<!-- Malo: Oculto en CSS -->
.hero { background-image: url('/hero.webp'); }

Para imágenes de fondo CSS (evita estas para LCP cuando sea posible), precárgalas:

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

El atributo fetchpriority="high" le dice a los navegadores que prioricen este recurso sobre otros. Sin él, las imágenes a menudo se descargan con prioridad “Low” por defecto.

Fase 3: Reducir la Duración de Carga de Recursos

Los archivos más pequeños se descargan más rápido. Esta fase es pura física—reduce bytes, reduce tiempo.

Optimización de imágenes:

Usar formatos modernos (WebP, AVIF)
Implementar imágenes responsivas con srcset
Comprimir sin pérdida visible de calidad
Dimensionar imágenes correctamente—no cargar imágenes 4K para móviles

Optimización de fuentes para LCP de texto:

Usar font-display: swap para mostrar texto inmediatamente
Crear subconjuntos de fuentes con caracteres requeridos
Precargar fuentes críticas

Consideraciones de CDN:

Los CDNs de imágenes optimizan automáticamente formatos y compresión
El servicio same-origin evita overhead de conexión
Usar funciones de proxy CDN cuando estén disponibles

Fase 4: Minimizar el Bloqueo de Renderizado

Incluso con recursos descargados, el renderizado puede estancarse debido a congestión del hilo principal.

Bloqueadores comunes:

CSS que bloquea renderizado en <head>
Ejecución síncrona de JavaScript
Tareas largas de scripts de terceros

Soluciones:

CSS crítico inline:

<style>
  /* Solo estilos above-the-fold */
  .hero { /* estilos */ }
</style>

Diferir JavaScript no crítico:

<script defer src="/app.js"></script>

Para elementos LCP basados en texto bloqueados por web fonts, asegurar renderizado de respaldo:

@font-face {
  font-family: 'Custom';
  font-display: swap; /* Muestra respaldo inmediatamente */
  src: url('/font.woff2') format('woff2');
}

Casos Especiales: Video e Imágenes de Fondo

Elementos de video: La imagen poster o el primer frame se convierte en candidato LCP. Optimiza la imagen poster como cualquier otra imagen, y asegúrate de que la codificación de video sea eficiente.

Imágenes de fondo CSS: Estas crean retrasos inherentes de descubrimiento. El navegador no puede precargar lo que no ha parseado. Convierte imágenes de fondo críticas a elementos <img>, o precárgalas explícitamente.

Medir y Monitorear LCP

Los datos de laboratorio (PageSpeed Insights, Lighthouse) ayudan a diagnosticar problemas, pero los datos de campo (CrUX, RUM) muestran la experiencia real del usuario. Siempre prioriza los datos de campo—es lo que Google usa para rankings.

Usa el panel Performance de Chrome DevTools para ver desgloses de LCP localmente. La librería JavaScript web-vitals permite monitoreo personalizado:

import {onLCP} from 'web-vitals';

onLCP(({value, entries}) => {
  console.log('LCP:', value, entries[0].element);
});

Conclusión

Optimizar LCP requiere atención sistemática a las cuatro fases. Comienza con TTFB—ninguna optimización importa si tu servidor es lento. Asegura descubrimiento inmediato de recursos, minimiza tamaños de archivo y elimina recursos que bloquean renderizado. Más importante aún, nunca apliques lazy-loading a tu elemento LCP. Con estas optimizaciones en su lugar, lograr un LCP sub-2.5-segundos se vuelve no solo posible, sino predecible.

Preguntas Frecuentes

Las herramientas de laboratorio como PageSpeed Insights prueban bajo condiciones controladas con velocidades de red y dispositivos específicos. Los usuarios reales tienen conexiones, dispositivos y ubicaciones geográficas variadas. Los datos de campo de CrUX reflejan experiencias reales de usuarios, que es lo que Google usa para rankings.

Sí, los frameworks de JavaScript pueden retrasar LCP si renderizan contenido del lado del cliente. El navegador debe descargar, parsear y ejecutar JavaScript antes de mostrar contenido. El renderizado del lado del servidor o la generación estática pueden mejorar significativamente LCP para sitios basados en frameworks.

Generalmente sí. El lazy loading de imágenes below-the-fold reduce el peso inicial de la página y mejora el rendimiento. Solo asegúrate de nunca aplicar lazy-loading a contenido above-the-fold, especialmente tu elemento LCP. Usa loading=lazy para imágenes fuera del viewport inicial.

Los scripts de terceros pueden bloquear el hilo principal, retrasando tanto la carga de recursos como el renderizado. También pueden inyectar recursos que bloquean renderizado. Carga scripts de terceros de forma asíncrona, difiere los no críticos y considera usar web workers para tareas de procesamiento pesado.

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.