LCP

Qué elemento se está midiendo

El LCP no mide cuándo termina de cargar la página. Mide cuándo se pinta el elemento de contenido más grande que hay dentro de la parte visible de la pantalla, sin necesidad de bajar. Es una aproximación deliberadamente sencilla a la pregunta que se hace cualquier persona al abrir una web: ¿esto ya está o sigue en blanco?

Los candidatos a ser ese elemento son pocos: imágenes, imágenes de fondo cargadas por CSS, vídeos con su fotograma de portada y bloques de texto. Se comparan por el área que ocupan en pantalla y gana el mayor. Como el contenido va apareciendo por partes, el candidato puede cambiar durante la carga: entra el titular, se marca como el mayor, y medio segundo después entra la fotografía de cabecera y le quita el puesto. La medición se cierra en la primera interacción de la persona, porque a partir de ahí ya no se está midiendo la carga sino otra cosa.

Google considera bueno un LCP por debajo de 2,5 segundos, necesita mejorar entre 2,5 y 4 segundos, y malo por encima de 4. Como el resto de Core Web Vitals, se evalúa en el percentil 75 de las visitas reales, no en la media.

En qué se descompone el tiempo

Para arreglarlo hay que dejar de verlo como un número y verlo como una suma de cuatro tramos. Es lo primero que dibujo en una pizarra cuando explico esto:

1. Tiempo hasta el primer byte. Lo que tarda el servidor en empezar a responder. Aquí entran el alojamiento, la base de datos, la caché y la distancia física.
2. Retraso de carga del recurso. Lo que pasa desde que el navegador empieza a leer el documento hasta que descubre que existe esa imagen y la pide. Si la imagen aparece tarde en el HTML, o solo después de ejecutar un script, este tramo se dispara.
3. Carga del recurso. Lo que tarda en descargarse la imagen. Depende del peso del archivo, del formato y de la conexión.
4. Retraso de pintado. Lo que va desde que el archivo está en el navegador hasta que se ve en pantalla, normalmente bloqueado por hojas de estilo o scripts pendientes.

Es imposible optimizar sin saber cuál de los cuatro se lleva el tiempo. He visto comprimir imágenes durante días en sitios cuyo problema estaba entero en el primer tramo.

En un operador de excursiones marítimas lo medimos y el resultado no admitía discusión: su WordPress en producción tardaba entre 5,7 y 6,7 segundos en empezar a responder, según la página. Ninguna optimización de imagen sirve de nada con ese punto de partida. Tras pasar a un sitio estático, el primer byte quedó en 0,2 segundos; el HTML bajó de unos 1,9 MB a 108 KB y los recursos que bloquean el renderizado, de 86 scripts a 4. Conviene decirlo con la honestidad con la que lo escribimos en el informe: fue una medición única por URL, así que sirve como orden de magnitud, no como banco de pruebas.

Lo que me encuentro al auditar

Tres patrones se repiten con una insistencia casi cómica.

La imagen de cabecera cargada en diferido. La técnica de retrasar la carga de las imágenes hasta que se acercan a la pantalla es excelente para todo lo que hay más abajo y desastrosa para el elemento de LCP. Se aplica el ajuste en masa desde un plugin, se aplica también a la imagen principal, y esa imagen pasa a pedirse tarde a propósito. Es un error de un minuto de arreglar que cuesta un segundo entero.

El carrusel de la portada. Precioso en la presentación de diseño. En la práctica carga tres o cuatro imágenes grandes, necesita código para funcionar y la primera diapositiva es casi siempre el elemento de LCP. Cuando puedo convencer al cliente de sustituirlo por una imagen fija con un mensaje claro, la mejora en la métrica y en la conversión suele llegar junta.

La fuente tipográfica externa. Si el elemento mayor es un titular de texto y la tipografía se descarga de un servidor de terceros sin previsión, el texto no se pinta hasta que llega la fuente. El titular está listo desde el principio y se queda esperando por un capricho de estilo.

Mi diagnóstico empieza siempre por identificar qué elemento concreto está siendo el LCP en móvil, que rara vez es el que la gente supone. A partir de ahí, todo lo que no sea ese elemento pasa a ser secundario: en esta métrica solo se compite por una plaza.

Por qué le importa a un negocio

Porque es la métrica que mejor se corresponde con la sensación de «esta web va lenta», y esa sensación se traduce en gente que se marcha antes de leer nada. Quien llega desde una búsqueda no tiene ningún vínculo contigo: si la pantalla está en blanco, vuelve atrás y prueba con el siguiente resultado. No hay mensaje comercial que sobreviva a eso, porque nunca llega a leerse.

Es además la métrica de Core Web Vitals con más impacto en la percepción de velocidad: es la que decide si la web se siente rápida o lenta. Y a veces se mueve con un solo cambio bien elegido. En una inmobiliaria industrial —naves y suelo en alquiler y venta—, el lastre era Google Tag Manager, que arrastraba GA4 y el Consent Mode: 130 KB de JavaScript sin usar compitiendo con la cabecera. Lo movimos para que no cargue hasta la primera interacción de la persona —scroll, movimiento del ratón, pulsación o toque— o, si no la hay, hasta que el navegador esté ocioso, con un techo de 3,5 segundos. Ese único cambio bajó el LCP de 3,9 a 2,9 segundos y subió la puntuación de rendimiento en móvil de 87 a 95.

Y hay un efecto colateral que se agradece: una web que carga rápido gasta menos datos y menos batería de quien la visita. En accesibilidad esto importa más de lo que parece, porque la conexión mala y el dispositivo antiguo no son casos raros, son la norma de mucha gente.

Errores frecuentes

Perseguir el número en lugar del elemento. Si no sabes qué está midiendo el LCP de esa plantilla, cualquier optimización es a ciegas. Identificar el elemento es el paso uno y no es opcional.

Aplicar carga diferida a la imagen principal. El ajuste global que mejora todo el sitio empeora justo la métrica que quieres arreglar. La imagen de cabecera va con prioridad alta y sin diferir; el resto, en diferido.

Confundir LCP con velocidad de carga total. Se puede tener un LCP excelente y una página que sigue trabajando diez segundos por detrás. Y al revés: una página ligera puede tener mal LCP si el elemento principal se pide tarde.

Optimizar solo la imagen y no el servidor. Si el primer byte tarda un segundo y medio, ya has consumido más de la mitad del presupuesto antes de empezar. Caché, alojamiento y consultas a base de datos forman parte de esta métrica aunque no lo parezca.

Medir en escritorio y dar el trabajo por terminado. El presupuesto de 2,5 segundos se gasta muchísimo antes en un móvil de gama media con red irregular, que es donde está la mayoría de tu tráfico.