Solucionar el LCP con un agente de IA: de los datos de campo a la corrección del código

Un Largest Contentful Paint lento tiene cuatro causas posibles. Un agente de IA conectado a datos de campo puede identificar cuál es tu verdadero cuello de botella, rastrearlo en Chrome y generar la solución. Este es el flujo de trabajo completo de diagnóstico del LCP usando CWV Superpowers.

Última revisión por Arjen Karel en marzo de 2026

Las cuatro fases del LCP

Google divide el LCP en cuatro fases. Cada una tiene diferentes causas y diferentes soluciones.

TTFB es el tiempo desde el inicio de la navegación hasta el primer byte de la respuesta HTML. Servidores lentos, falta de CDN, sin caché, consultas largas a la base de datos. Si el TTFB es el cuello de botella, nada más importa hasta que arregles el servidor.

Load Delay es la brecha entre la recepción del HTML y la solicitud del recurso LCP por parte del navegador. Este es el problema de descubrimiento. Si la imagen LCP está en un fondo CSS, se carga mediante JavaScript o está enterrada tras una cadena de redirecciones, el navegador no puede empezar a buscarla hasta que descubre que la necesita.

Load Time es el tiempo que tarda el recurso LCP en descargarse una vez solicitado. Imágenes grandes, falta de compresión, CDN lenta, sin srcset responsive.

Render Delay es la brecha entre el momento en que el recurso termina de descargarse y el navegador lo pinta realmente en la pantalla. Scripts que bloquean el renderizado, carga de fuentes web o JavaScript que manipula el DOM antes de que el elemento LCP se vuelva visible.

Encontrar el cuello de botella con razonamiento proporcional

Los datos públicos sobre los Core Web Vitals no son lo suficientemente buenos para ayudarte a encontrar los problemas reales de tus Core Web Vitals.  Lighthouse ejecuta una prueba sintética en un Moto G Power simulado e informa un solo tiempo de LCP. CrUX agrega 28 días de datos reales de Chrome en un solo valor p75 por URL. Ninguno te dice qué arreglar.

Y es peor: ninguno puede segmentar de forma significativa. CrUX combina las vistas de página en caché, las vistas sin caché, las nuevas visitas y las recargas de página en un solo p75. Estos deberían tratarse como problemas separados. Las vistas de página en caché podrían tener un cuello de botella de TTFB debido a la validación de caché obsoleta. Las recargas de página podrían ocultar un problema de descubrimiento de recursos donde el navegador encuentra la imagen LCP tarde en cada visita. El p75 combinado enmascara ambos.

CrUX añadió subpartes del LCP en 2025, lo cual ayuda. Pero sigue siendo un p75 de 28 días sin filtrar por elemento, viewport o cualquier otro filtro. Ves las proporciones de las fases para "todos los visitantes de esta URL durante el último mes". No ves lo que está pasando en el tipo de dispositivo específico, país o plantilla de página donde reside el problema.

Los datos de RUM segmentan por todas estas dimensiones. CWV Superpowers consulta esos datos segmentados y los interpreta proporcionalmente. El cuello de botella es la fase que consume la mayor parte del tiempo total para el segmento específico que está fallando. No un promedio sin sentido o una simulación de Lighthouse. ¡Datos reales!

Ejemplo concreto. El LCP es de 3,800ms en las páginas de productos para móviles. El desglose de usuarios reales para los primeros visitantes en vistas de página en caché:

• TTFB: 600ms (28.7%)
• Load Delay: 1,900ms (44.6%)
• Load Time: 800ms (19.3%)
• Render Delay: 500ms (7.4%)

El Load Delay es el cuello de botella obvio. La mitad del tiempo total del LCP es el navegador esperando descubrir que la imagen existe. A Lighthouse, CrUX o una investigación manual les habría costado mucho encontrar esta combinación exacta de características de los visitantes que causó este problema.

Para una explicación completa de este enfoque, consulta el razonamiento proporcional para el rendimiento web.

Por qué el navegador encuentra tu imagen tarde

El Load Delay es el cuello de botella del LCP más común que veo. Significa que el navegador recibió el HTML pero no sabía que necesitaba la imagen principal hasta mucho después.

Tres causas comunes. La imagen es una imagen de fondo CSS invisible para el escáner de precarga. La URL de la imagen se construye en JavaScript. O la imagen está técnicamente en el HTML pero tiene un atributo lazy loading que el navegador respeta de manera demasiado entusiasta.

Abre la traza de Chrome. Verás una gran brecha en la cascada de red entre la llegada del HTML y el disparo de la solicitud de la imagen. Esa brecha es tu Load Delay. En los sitios que audito, es de 1,500 a 2,500ms en móviles. Dos segundos completos en los que el navegador tiene el HTML pero no tiene ni idea de que necesita la imagen principal.

El agente ve la misma brecha. Hace coincidir la cascada con el desglose de CoreDash y te dice exactamente por qué la imagen llegó tarde.

Cómo se ve el diagnóstico

Así es como se ve el resultado:

Causa identificada por la IA: La imagen del LCP div.hero-banner > img.product-main en /product/running-shoes-42 se descubre con 1,980ms de retraso porque carece de una pista de precarga (preload hint) y no tiene fetchpriority="high". Datos de CoreDash: El LCP es de 3,820ms (pobre) en móviles, p75. El Load Delay es el cuello de botella con el 52% del total. La traza de Chrome lo confirma: una brecha de 1,940ms entre el primer byte del HTML y la solicitud de la imagen en la cascada de red.

Ese es todo el diagnóstico. El agente encontró el archivo, escribió el diff. Tú lo revisas y lo despliegas.

Soluciones típicas por fase

Load Delay: Añade un preload hint en el <head>. Establece fetchpriority="high" en la imagen LCP. Mueve la imagen del fondo CSS o JavaScript al HTML donde el escáner de precarga pueda encontrarla.

Load Time: Conviértela a WebP o AVIF. Reduce las dimensiones de la imagen para que coincidan con el tamaño de visualización real. Añade un srcset responsive para que los usuarios de móviles no descarguen una imagen de tamaño de escritorio. Consulta optimizar imágenes para los Core Web Vitals.

Render Delay: Elimina o pospón los scripts que bloquean el renderizado y se ejecutan antes de que el elemento LCP sea visible. Comprueba el font-display en las fuentes web que afectan al elemento de texto del LCP. Utiliza 103 Early Hints para entregar el CSS antes.

TTFB: Añade una CDN. Habilita el almacenamiento en caché del lado del servidor. Reduce el tiempo de consulta a la base de datos. Utiliza 103 Early Hints para permitir que el navegador comience a precargar los recursos mientras el servidor sigue generando la respuesta.

Verificar la solución

Después de desplegar, consulta los datos de campo de CoreDash para la misma página y segmento de dispositivo. Los datos de campo se actualizan a medida que los usuarios reales cargan la página. Normalmente lo compruebo después de 24 a 48 horas de tráfico. El p75 del LCP debería caer, y la distribución de la fase del cuello de botella debería cambiar.

Esta es la diferencia entre arreglar un número y arreglar la experiencia. No esperas 28 días para una actualización de CrUX ni vuelves a ejecutar Lighthouse esperando que la puntuación haya subido. Ves la mejora en los números de usuarios reales, en los segmentos de dispositivo y red donde estaba el problema.

Para el diagnóstico del INP (la métrica que no se puede medir en un laboratorio), se aplica el mismo flujo de trabajo segmentado. Para una visión más amplia de cómo los agentes de IA utilizan los datos de campo frente a los datos de laboratorio en los tres Core Web Vitals, consulta depuración de los Core Web Vitals con agentes de IA.