Core Web Vitals: qué son LCP, INP y CLS, sus umbrales y cómo mejorarlas

Las Core Web Vitals son las tres métricas con las que Google mide la experiencia de una página: LCP (carga del contenido principal), INP (respuesta a clics, toques y teclas) y CLS (estabilidad visual). Una página las aprueba si, en el percentil 75 de las visitas, LCP no pasa de 2,5 s, INP de 200 ms y CLS de 0,1.

Para comprobarlo en tu web: Auditoría SEO

Son la parte medible de la velocidad dentro del posicionamiento web, y casi todas las herramientas de auditoría las muestran. Esta guía explica qué mide cada una, de dónde salen los datos y cómo se diagnostica y se arregla cada métrica. Si tienes una tienda, los fallos propios de fichas y categorías están en Core Web Vitals en una tienda online.

¿Qué son las Core Web Vitals?

Las Core Web Vitals son el subconjunto de las Web Vitals de Google que se aplica a todas las páginas web y que cubre carga, interactividad y estabilidad visual. Las tres métricas actuales tienen estado «estable», y Google se compromete a no cambiar una métrica estable más de una vez al año y a anunciarlo en su documentación1.

Un cambio así ya ha ocurrido. INP sustituyó a FID (First Input Delay) como Core Web Vital el 12-03-20242. FID solo medía el retraso de la primera interacción; INP observa todas las interacciones de la visita. Si una herramienta o un artículo te sigue hablando de FID, sus datos o sus consejos son anteriores a esa fecha.

¿Cuáles son los umbrales oficiales?

Google fija para cada métrica un límite de «bueno» y otro a partir del cual el resultado es «malo»; entre los dos queda «necesita mejorar». Son los mismos en PageSpeed Insights y en Search Console34:

Lo que se compara con esos límites no es la media, sino el percentil 75 de las cargas de página, por separado en móvil y en ordenador1. Dicho de otra forma: aprueba la métrica si al menos tres de cada cuatro visitas tienen una experiencia buena. Por eso una página puede ir rápida en tu ordenador con fibra y suspender en los móviles de tus visitantes.

PageSpeed Insights da la evaluación por aprobada cuando el percentil 75 de las tres métricas es «bueno». Si no hay datos suficientes de INP, basta con que LCP y CLS sean buenas; si faltan datos de LCP o de CLS, no hay evaluación3.

Datos de campo frente a datos de laboratorio

Hay dos maneras de medir las mismas métricas, y casi todas las dudas sobre Core Web Vitals vienen de mezclarlas.

Tres detalles de CrUX que explican resultados que desconciertan:

• Solo cuenta Chrome en ordenador y en Android. Chrome en iOS y otros navegadores basados en Chromium no aportan datos5. Si casi todo tu tráfico llega desde iPhone, los datos de campo describen a una minoría de tus visitas.
• Hace falta un mínimo de visitas, que Google no publica, y la página tiene que ser pública e indexable5. Si una URL no llega, PageSpeed Insights muestra los datos de todo el origen; si el origen tampoco llega, no hay datos de campo3.
• Los cambios tardan en verse. Al ser una ventana de 28 días, un arreglo publicado hoy no se refleja del todo hasta cuatro semanas después.

Que el laboratorio y el campo no coincidan es lo normal. Web.dev enumera los motivos: caché, dispositivo y red de cada usuario, contenido personalizado o pruebas A/B que cambian el elemento del LCP, y páginas que se recuperan al instante desde la caché de ida y vuelta del navegador6. Su recomendación es priorizar con los datos de campo6. Cómo leer cada bloque del informe está en la guía de PageSpeed Insights.

LCP: cómo se diagnostica y qué lo mejora

LCP es el tiempo que pasa desde que el usuario abre la página hasta que se pinta la imagen, el vídeo o el bloque de texto más grande de la primera pantalla7. Cuentan las etiquetas img, los pósteres de vídeo, las imágenes de fondo cargadas con url() en CSS y los bloques de texto7.

El primer paso es saber qué elemento es. Lighthouse lo indica, y lo desglosa en cuatro partes. Web.dev propone un reparto orientativo para una página bien optimizada8:

La parte que se desvía de ese reparto te dice dónde trabajar:

• Retraso de carga alto: la imagen se descubre tarde. Las causas típicas son loading="lazy" en la imagen principal (web.dev pide no hacerlo nunca) o una imagen que solo aparece cuando se ejecuta JavaScript. Marca esa imagen con fetchpriority="high"8.
• Duración de la carga alta: la imagen pesa demasiado. Comprime, usa formatos modernos y sirve el tamaño adecuado a cada pantalla; está detallado en cómo optimizar las imágenes de una web.
• TTFB alto: redirecciones encadenadas o un servidor lento; caché de página y CDN8.
• Retraso de renderizado alto: hojas de estilo y scripts que bloquean el pintado8.

INP: cómo se diagnostica y qué lo mejora

INP mide la latencia de todos los clics, toques y pulsaciones de tecla de una visita y da un valor que todas o casi todas quedan por debajo9. No cuentan pasar el ratón por encima, desplazarse ni hacer zoom9.

Cada interacción tiene tres tramos: el retraso de entrada (el navegador está ocupado y no atiende el clic), el tiempo de procesamiento (lo que tarda tu código en reaccionar) y el retraso de presentación (lo que tarda en pintarse el resultado)9.

INP es la métrica más difícil de diagnosticar, porque depende de lo que haga cada usuario. Web.dev propone un orden: identificar en los datos de campo qué interacciones son lentas, reproducirlas en el laboratorio y optimizar el tramo que más pese10. Para reproducirlas, el panel Rendimiento de las herramientas para desarrolladores de Chrome muestra en vivo el LCP, el CLS y el INP de tus propias interacciones, y puede compararlos con los datos de campo de CrUX11.

Los arreglos habituales, por tramo10:

• Retraso de entrada: menos JavaScript ejecutándose mientras la página carga, sobre todo de terceros (chat, publicidad, analítica).
• Procesamiento: haz en el manejador del evento solo lo imprescindible para mostrar la respuesta y cede el control al navegador entre trozos de trabajo.
• Presentación: un DOM más pequeño y menos HTML generado en el navegador con JavaScript.

CLS: cómo se diagnostica y qué lo mejora

CLS mide la mayor ráfaga de desplazamientos inesperados del contenido durante toda la vida de la página12. Una ráfaga agrupa los desplazamientos separados por menos de un segundo, con un máximo de cinco. Los que ocurren en los 500 ms siguientes a un clic o una tecla no cuentan, porque el usuario los espera12.

Lighthouse señala qué elementos se movieron. Las causas y sus arreglos son casi siempre los mismos13:

¿Cuánto pesan las Core Web Vitals en el posicionamiento?

Google es explícito: las Core Web Vitals se usan en sus sistemas de clasificación, y recomienda tenerlas en buen estado14. En la misma página añade los dos matices que las ponen en su sitio14:

• Google Search siempre intenta mostrar el contenido más relevante, aunque la experiencia de página sea mediocre.
• Tener buenos resultados en el informe de Search Console o en herramientas de terceros no garantiza salir arriba.

En la práctica, una página que responde mejor a la búsqueda gana a otra más rápida que responde peor. Las Core Web Vitals pesan cuando hay varias páginas igual de útiles, y pesan en la experiencia de tus visitas siempre. Por eso conviene revisarlas dentro de una auditoría SEO y no como un fin en sí mismas.

Cómo las revisa SmoothSeen

Declaración de interés: este blog es de SmoothSeen, una herramienta de auditoría web que mide el posicionamiento en buscadores y en asistentes de IA. Su informe toma la velocidad de PageSpeed Insights, con los datos de campo y los de laboratorio, así que lo que ves en él coincide con lo que ves en PageSpeed. Lo junta con el resto de comprobaciones de Posicionamiento web y lo compara con hasta tres competidores. Analiza una página cada vez y no se conecta a Search Console.

Preguntas frecuentes

¿Qué es un buen LCP?

Un LCP de 2,5 segundos o menos en el percentil 75 de las visitas, medido por separado en móvil y en ordenador. Entre 2,5 y 4 segundos necesita mejorar, y por encima de 4 es malo. Lo que cuenta es el dato de campo de usuarios reales; el LCP de una prueba de laboratorio sirve para encontrar la causa, no para saber si apruebas.

¿Qué pasó con FID?

Google lo retiró como Core Web Vital el 12-03-2024 y lo sustituyó por INP. FID solo medía cuánto tardaba el navegador en empezar a atender la primera interacción; INP mide todas las interacciones de la visita, de principio a fin, hasta que se pinta la respuesta. Search Console dejó de mostrar FID ese mismo día, y el resto de herramientas lo retiró en los meses siguientes.

¿Por qué mi web no tiene datos de Core Web Vitals?

Porque CrUX solo incluye páginas públicas e indexables con un mínimo de visitas, que Google no publica, y solo recoge datos de Chrome en ordenador y en Android. Si tu URL no llega, PageSpeed Insights muestra los del dominio entero; si el dominio tampoco, solo verás datos de laboratorio. Trabaja con ellos mientras tanto y revisa las plantillas, no páginas sueltas.

¿Se pueden aprobar las Core Web Vitals con una nota de rendimiento baja?

Sí. La nota de 0 a 100 de PageSpeed Insights sale solo de la prueba de laboratorio y mezcla métricas que no son Core Web Vitals, como el tiempo total de bloqueo. La evaluación de Core Web Vitals sale de los datos de campo. Una página con usuarios en buenos dispositivos y conexiones puede aprobar con una nota de laboratorio mediocre, y al revés.

Qué hacer ahora

Pasa tu página más importante por PageSpeed Insights, mira en el bloque de datos de campo qué métrica no llega a «bueno» y aplica los arreglos de su sección. Después, sigue con la guía de posicionamiento web para ver dónde encaja la velocidad en el resto del trabajo.