Core Web Vitals: LCP, INP y CLS explicados

Las Core Web Vitals son tres métricas con las que Google describe la experiencia real de los usuarios: Largest Contentful Paint (LCP) para la carga, Interaction to Next Paint (INP) para la capacidad de respuesta y Cumulative Layout Shift (CLS) para la estabilidad visual. Una página aprueba cuando al menos el 75 % de las visitas logran un LCP de 2,5 segundos o menos, un INP de 200 milisegundos o menos y un CLS de 0,1 o menos. En esta guía verás qué mide cada métrica, cómo interpretar tus resultados y qué mejoras suelen moverlos.

Las tres métricas de un vistazo

Google publica umbrales fijos para cada métrica y agrupa los resultados en tres franjas. Las cifras de la tabla proceden del resumen de Core Web Vitals de web.dev (en inglés).

Hay dos detalles que importan más de lo que la mayoría cree:

• Decide el percentil 75. Google no mira tu visita más rápida ni la media. Toma el valor que alcanzan o mejoran el 75 % de las cargas de página, por separado para móvil y escritorio. Unos pocos móviles lentos con mala conexión pueden bastar para que una página caiga en "necesita mejorar".
• INP sustituyó a FID en marzo de 2024. First Input Delay solo medía el retraso antes de que se atendiera la primera interacción. INP tiene en cuenta la latencia de las interacciones durante toda la visita, una prueba mucho más exigente para las páginas cargadas de JavaScript.

Datos de campo frente a datos de laboratorio

Cuando pruebas una página en corewebvitals.page, ves dos tipos de resultados, y a menudo no coinciden.

• Los datos de campo proceden del Chrome User Experience Report. Recogen a usuarios reales de Chrome durante una ventana móvil de 28 días. Son los que cuentan para la evaluación de Core Web Vitals en Search Console.
• Los datos de laboratorio (la puntuación de Lighthouse) son una única carga simulada en un dispositivo con limitaciones de CPU y red. Son muy útiles para depurar porque se pueden repetir, pero no pueden medir el INP, porque nadie hace clic durante la prueba. Lighthouse usa el Total Blocking Time como sustituto aproximado.

Como los datos de campo van con hasta 28 días de retraso, una mejora que publiques hoy aparecerá poco a poco. Usa las pruebas de laboratorio para confirmar que el cambio funciona y luego observa cómo se estabilizan las cifras de campo. Nuestra guía sobre cómo medir bien la velocidad de una web explica paso a paso una prueba de antes y después en la que puedas confiar.

Cómo mejorar el LCP

El LCP suele ser la métrica más difícil de aprobar, pero normalmente es la más fácil de diagnosticar. Google lo divide en cuatro partes, descritas en el artículo sobre el LCP de web.dev (en inglés):

1. Time to First Byte: lo que tarda el servidor en empezar a enviar el HTML.
2. Retraso de carga del recurso: el hueco entre el primer byte y el momento en que el navegador empieza a cargar la imagen del LCP.
3. Duración de carga del recurso: lo que tarda en descargarse la propia imagen del LCP.
4. Retraso de renderizado del elemento: el tiempo entre que llega la imagen y que se pinta de verdad.

Mira qué parte domina antes de cambiar nada. El panel Performance de Chrome DevTools muestra el elemento del LCP y cómo se reparte su tiempo.

Respuesta lenta del servidor

Si el TTFB por sí solo ya se come un segundo o más, por mucho que ajustes las imágenes no bajarás de 2,5 segundos. Las causas habituales son páginas sin caché que PHP y una base de datos generan en cada petición, un servidor lejos de la mayoría de visitantes y plugins o extensiones lentos. La solución habitual es la caché de página, en el servidor o en el edge. Tienes la lista completa en cómo reducir el TTFB.

La imagen del LCP se descubre tarde

Los navegadores encuentran las imágenes mientras analizan el HTML. Si tu imagen principal se pone como fondo en CSS, la inyecta JavaScript o tiene lazy loading, el navegador se entera tarde. Soluciones:

• Usa un elemento <img> normal para la imagen principal.
• No añadas nunca loading="lazy" a la imagen del LCP.
• Añade fetchpriority="high" o una indicación de precarga para que el navegador la pida pronto:

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

La imagen del LCP pesa demasiado

Un JPEG de 3000 píxeles de ancho que se muestra a 1200 píxeles desperdicia ancho de banda en cada visita. Sirve formatos modernos como WebP o AVIF, ajusta el tamaño de la imagen al diseño y usa srcset para las distintas pantallas. Nuestra guía para optimizar imágenes para la web lo trata en detalle.

CSS y fuentes que bloquean el renderizado

Las hojas de estilo grandes y los scripts síncronos en el <head> retrasan el pintado incluso cuando la imagen ya está lista. Incluye en línea el CSS crítico, aplaza los scripts que no sean imprescindibles y mantén ligeras las fuentes web.

Cómo mejorar el INP

El INP mide el tiempo desde una interacción del usuario hasta el siguiente fotograma que pinta el navegador. Casi siempre es un problema de JavaScript, no de red. El artículo de web.dev sobre el INP lo divide en retraso de entrada, tiempo de procesamiento y retraso de presentación.

Causas y soluciones típicas:

• Tareas largas en el hilo principal. Cualquier script que se ejecute durante más de 50 ms impide que la página responda. Divide el trabajo largo en trozos más pequeños y devuelve el control al navegador entre ellos.
• Demasiado JavaScript de terceros. Los widgets de chat, los gestores de etiquetas, las herramientas de test A/B y los scripts de anuncios compiten por el hilo principal. Revisa qué se carga y quita lo que nadie usa.
• Manejadores de eventos pesados. Un clic que provoca una gran actualización del DOM, que vuelve a renderizar un listado completo de productos o que hace lecturas síncronas del layout se sentirá torpe. Actualiza solo lo que ha cambiado y muestra una respuesta visual inmediata antes de hacer el trabajo costoso.
• Un DOM enorme. Las páginas con muchos miles de elementos tardan más en recalcular estilos y layout tras cada interacción. Los maquetadores visuales son una fuente frecuente.

Un CDN o una caché solo ayudan al INP de forma indirecta: si se tarda menos en descargar, los scripts están listos antes, pero el código sigue teniendo que ejecutarse en el dispositivo del visitante.

Cómo mejorar el CLS

El CLS puntúa la mayor ráfaga de desplazamientos inesperados del diseño mientras la página está abierta. Los desplazamientos que ocurren en los 500 ms posteriores a una interacción del usuario no cuentan, así que un acordeón que se abre tras un clic no es un problema. El artículo de web.dev sobre el CLS explica cómo se puntúa.

Los sospechosos habituales:

• Imágenes y vídeos sin dimensiones. Sin los atributos width y height (o un aspect-ratio en CSS), el navegador no reserva espacio y empuja el contenido hacia abajo cuando llega el archivo.
• Anuncios, contenidos incrustados y banners insertados encima del contenido. Resérvales un hueco fijo o colócalos por debajo del pliegue.
• Banners de cookies que empujan la página. Muéstralos superpuestos en lugar de insertarlos al principio del documento.
• Fuentes web que se cambian al cargar. Cuando la fuente web sustituye a la de reserva, el texto se puede recolocar. font-display: swap mantiene el texto visible desde el principio; ajustar las métricas de la fuente de reserva (por ejemplo con size-adjust) evita que el cambio mueva cosas.

¿Influyen las Core Web Vitals en el posicionamiento?

Las Core Web Vitals forman parte de las señales de experiencia de página de Google (en inglés). Google afirma que sus sistemas de ranking premian una buena experiencia de página, pero también que la relevancia y la calidad del contenido van primero. En la práctica, aprobar las Core Web Vitals no subirá al primer puesto una página floja, y suspenderlas no hundirá una página que es claramente la mejor respuesta.

La mejor razón para preocuparte son tus visitantes. Una carga lenta, botones que tardan en responder y diseños que saltan te cuestan consultas y ventas, haga lo que haga cualquier algoritmo. Toma los umbrales como un listón de calidad para los usuarios, no como un truco de SEO.

Cómo te ayuda fast.site

fast.site se coloca delante de tu hosting actual, así que mantienes tu proveedor y tu CMS. Apuntas los servidores de nombres de tu dominio a fast.site y, a partir de ahí, el tráfico pasa por una red edge con regiones en Norteamérica, Europa, Asia-Pacífico y Sudamérica, según tu plan.

Para el LCP, Fast Edge Cache™ sirve las páginas y los recursos en caché desde el edge más cercano al visitante, de modo que un cache HIT no espera a tu servidor de origen. Eso actúa sobre las partes del LCP que corresponden al TTFB y a la descarga. La optimización de imágenes convierte JPEG y PNG a WebP sobre la marcha para los navegadores compatibles, con AVIF disponible según tu plan.

La optimización de HTML, que se activa de forma opcional, ataca directamente problemas habituales de LCP y CLS: precarga la imagen principal detectada, añade ancho y alto a las imágenes para reducir los saltos de diseño y añade font-display: swap a las fuentes web. Tienes los detalles en la documentación de optimización de HTML.

fast.site no puede arreglar un JavaScript lento, así que el trabajo sobre el INP sigue estando en tu código. Mide antes y después en tu propia web: la cabecera fs-cache muestra HIT, MISS o BYPASS, y la analítica informa del TTFB y de la tasa de aciertos de caché. Puedes probar todo esto con una prueba gratuita de 7 días, sin tarjeta de crédito. Consulta los planes para ver los detalles.

Preguntas frecuentes

¿Qué es una buena puntuación de Core Web Vitals?

Una página aprueba cuando, en el percentil 75 de las visitas, el LCP es de 2,5 segundos o menos, el INP de 200 milisegundos o menos y el CLS de 0,1 o menos. Las tres tienen que estar en "bueno" para aprobar la evaluación. Móvil y escritorio se evalúan por separado.

¿Por qué mi puntuación de PageSpeed es buena pero Search Console dice que suspendo?

La puntuación de Lighthouse es una única prueba de laboratorio en un dispositivo simulado, mientras que Search Console usa 28 días de datos de usuarios reales de Chrome. Los visitantes reales usan móviles y redes más lentos que la prueba, y las pruebas de laboratorio no pueden medir el INP. Fíate de los datos de campo para la evaluación y usa la prueba de laboratorio para depurar.

¿Cuánto tardan en notarse las mejoras de Core Web Vitals?

Los datos de campo son una ventana móvil de 28 días, así que las mejoras aparecen poco a poco a lo largo de unas cuatro semanas. Search Console puede tardar algo más en actualizar sus informes. Las pruebas de laboratorio muestran el cambio al momento.

¿Un CDN mejora las Core Web Vitals?

Un CDN ayuda sobre todo al LCP, porque reduce el tiempo de respuesta del servidor y el de descarga para los visitantes alejados de tu origen. Puede reducir el CLS de forma indirecta si ofrece optimizaciones de HTML como añadir las dimensiones de las imágenes. El INP depende sobre todo del JavaScript que se ejecuta en el navegador, así que ahí un CDN apenas tiene efecto directo.

¿Qué ha sustituido a First Input Delay (FID)?

Interaction to Next Paint (INP) sustituyó a FID como Core Web Vital en marzo de 2024. INP tiene en cuenta las interacciones de toda la visita en lugar de solo la primera, e incluye el tiempo que se tarda en pintar el resultado.