¿Qué es el LCP?

El Largest Contentful Paint mide el momento en que termina de dibujarse el elemento de contenido más grande que se ve en pantalla sin desplazarse. El reloj arranca cuando el usuario empieza a cargar la página y se detiene en ese elemento, no en el último que llega.

Google considera candidatos a un conjunto cerrado de elementos: imágenes <img>, imágenes dentro de un <svg>, el fotograma de portada de un <video>, cualquier elemento con una imagen de fondo cargada por CSS, y los bloques que contienen texto. El navegador va anotando el candidato más grande a medida que pinta, y el valor final se fija en cuanto el usuario interactúa por primera vez.

Esto tiene una consecuencia práctica que sorprende a mucha gente: el elemento que marca el LCP casi nunca es el que uno cree. En una ficha de producto suele ser la foto principal; en un artículo, el titular o la imagen de cabecera; en una portada con vídeo, el póster. Antes de optimizar hay que saber cuál es, y eso se consulta, no se supone.

Conviene separar dos preguntas que suelen mezclarse. Una es qué tarda en cargar la página entera, que es el terreno de page speed en general. La otra es cuándo el visitante ve algo que reconoce como la página, y esa es la que mide el LCP. Un sitio puede seguir descargando scripts de Google Tag Manager durante varios segundos más sin que eso afecte al valor, siempre que el elemento principal ya esté dibujado.

Esa distinción explica por qué el LCP entró en Core Web Vitals y no una métrica de carga total. Lo que se intenta capturar es la percepción, no el trabajo del navegador. Para el tráfico que llega desde búsqueda, el momento en que la página parece útil pesa más que el momento en que termina de trabajar.

Google fija tres tramos: hasta 2,5 segundos el LCP se considera bueno, entre 2,5 y 4,0 segundos necesita mejoras, y por encima de 4,0 segundos es deficiente. Los mismos umbrales valen para móvil y para escritorio, aunque los valores reales se agrupan por separado.

La parte que más se malinterpreta es cómo se agrega. No se usa la media, sino el percentil 75 de todas las visitas de los últimos 28 días: el valor por debajo del cual quedan tres de cada cuatro cargas. Una media esconde a los usuarios lentos detrás de los rápidos; el percentil 75 obliga a que la experiencia sea aceptable también para el cuarto peor servido.

Por eso una web puede sentirse rápida en la oficina y suspender igualmente. El portátil del equipo con fibra está en el percentil 20, no en el 75. Los datos que cuentan salen del informe de experiencia de usuario de Chrome, recogidos de navegadores reales, y se consultan en Google Search Console o en PageSpeed Insights.

El LCP no es un número opaco: se descompone en cuatro tramos consecutivos, y saber cuál pesa más dice exactamente dónde hay que trabajar.

1. Tiempo hasta el primer byte: lo que tarda el servidor en empezar a responder.
2. Retraso de carga del recurso: el hueco entre el primer byte y el momento en que el navegador empieza a pedir la imagen o la fuente del elemento LCP.
3. Duración de carga del recurso: lo que tarda esa descarga.
4. Retraso de renderizado: el tiempo entre tener el recurso y poder dibujarlo, normalmente bloqueado por CSS o JavaScript.

En la mayoría de las webs medidas, los dos primeros tramos se llevan la mayor parte del total. Eso desplaza el trabajo del lado de la imagen al lado del servidor y del orden de carga, que es SEO técnico puro y no diseño.

Los dos últimos tramos son los que más se confunden con un problema de imagen. Si el retraso de renderizado domina, la causa está en la hoja de estilos o en un script que bloquea, no en el archivo. Cambiar el JPEG por WebP en ese caso no mueve el número, y es la razón más común por la que un equipo cree que la métrica está rota.

Ese diagnóstico pertenece al SEO on-page en su parte técnica y se cruza con el trabajo del crawler: lo que retrasa al navegador humano suele retrasar también al robot, y con presupuestos de rastreo ajustados eso se nota en la indexación.

Las mismas cuatro o cinco causas se repiten en auditoría tras auditoría.

• Carga diferida en la imagen de cabecera. El loading="lazy" aplicado a todas las imágenes por defecto también afecta a la que marca el LCP, y el navegador la pide tarde a propósito.
• Servidor lento o sin caché. Si el primer byte llega en un segundo, quedan 1,5 para todo lo demás.
• CSS y JavaScript que bloquean el dibujado. El recurso está descargado y el navegador no puede pintarlo.
• Renderizado en el cliente. La página llega vacía y el contenido aparece cuando termina de ejecutarse el JavaScript.
• Imágenes sin dimensionar ni comprimir. Un JPEG de tres megabytes sigue tardando lo que tarda, por buena que sea la conexión.

La carga diferida merece una explicación aparte, porque es la causa que más veces aparece y la que más fácil se corrige. El atributo loading="lazy" le dice al navegador que no descargue una imagen hasta que el usuario se acerque a ella. Para todo lo que está por debajo de la primera pantalla es una mejora clara: ahorra datos y libera ancho de banda para lo que sí se ve.

El problema aparece cuando el CMS lo aplica a todas las imágenes por defecto, incluida la de cabecera. El navegador deja entonces de pedir temprano justo el archivo que marca el LCP y espera a saber dónde queda en el diseño. En una plantilla con diseño responsive esa decisión llega tarde, y el valor empeora sin que nadie haya tocado el contenido. La regla práctica: carga diferida en todas las imágenes menos en la primera visible, que además conviene marcar con fetchpriority="high".

El orden importa: primero se identifica el elemento, después se mide el tramo que más pesa, y solo entonces se toca algo.

• Quitar loading="lazy" del elemento LCP y añadirle fetchpriority="high" para que el navegador lo pida antes.
• Precargar la imagen o la fuente que marca el LCP si el navegador la descubre tarde por estar en CSS.
• Servir la imagen en formato moderno y en el tamaño real que ocupa, con width y height declarados.
• Reducir el tiempo hasta el primer byte con caché de página, una red de distribución y menos trabajo por petición en el servidor.
• Sacar del camino crítico el CSS y el JavaScript que no hacen falta para pintar la primera pantalla.

Después de cada cambio conviene esperar. Los datos de campo se calculan sobre 28 días, así que una mejora real tarda semanas en verse completa en Search Console, aunque una prueba de laboratorio la muestre de inmediato.

Vale la pena separar lo que se mide de lo que se decide. El LCP es un KPI técnico: dice cuánto tarda, no si la página convence. Una landing page que carga en dos segundos y no responde a la intención de búsqueda seguirá sin convertir, y ninguna mejora de milisegundos arregla eso. Por eso el trabajo de velocidad se planifica junto al de CRO, no en su lugar.

Para saber si el cambio ha servido hay dos lecturas complementarias. Los datos de campo en Search Console confirman la evaluación real; una mapa de calor o las métricas de analítica web muestran si el comportamiento cambió de verdad, mirando tasa de rebote y tiempo de permanencia antes y después.

• Optimizar una imagen que no es la que marca el LCP, y no entender por qué el valor no se mueve.
• Tomar la puntuación de laboratorio de una herramienta como si fuera el dato real; el que cuenta para la evaluación viene de usuarios reales.
• Mirar solo el escritorio cuando la mayoría de las visitas llegan desde el móvil, donde el índice mobile-first decide.
• Aplicar carga diferida a todas las imágenes por norma general, incluida la primera.
• Repetir la medición al día siguiente y sacar conclusiones de una ventana que todavía contiene 27 días de datos antiguos.

Un último malentendido, más caro de lo que parece: tratar el LCP como una nota que hay que aprobar. Los tramos no son un examen, son una descripción. Pasar de 4,2 a 3,8 segundos mejora la experiencia de la mitad de los visitantes aunque el rótulo siga diciendo «mejorable», y en una tienda de e-commerce eso se nota en la conversión mucho antes de que cambie el color del informe.