Core Web Vitals: qué son y cómo mejorar LCP, INP y CLS

Las tres métricas y sus umbrales

Cada métrica tiene un límite para «bueno» y otro para «deficiente». Una página lo cumple cuando es buena en el percentil 75 de las visitas reales, medido por separado en móvil y en escritorio.

• Largest Contentful Paint (LCP): bueno hasta 2,5 s, deficiente por encima de 4 s. Marca el momento en que se ha dibujado la imagen o el bloque de texto más grande de la pantalla.
• Interaction to Next Paint (INP): bueno hasta 200 ms, deficiente por encima de 500 ms. Mide el retraso entre un toque, un clic o una pulsación de tecla y la siguiente actualización visual, a lo largo de toda la visita.
• Cumulative Layout Shift (CLS): bueno hasta 0,1, deficiente por encima de 0,25. Suma los movimientos inesperados del diseño, como el texto que salta cuando una imagen o un banner tarda en cargar.

INP sustituyó a First Input Delay (FID) como Core Web Vital en marzo de 2024. Cualquier herramienta o informe que todavía te califique por FID está desactualizado.

Datos de campo frente a datos de laboratorio

Los datos de campo proceden de usuarios reales de Chrome a través del Chrome UX Report (CrUX), agregados durante los 28 días anteriores. Son los que usa Google. Los sitios pequeños suelen carecer de datos de campo porque no tienen tráfico suficiente para que se publiquen.

Los datos de laboratorio salen de una única carga simulada en Lighthouse, normalmente en un móvil de gama media con la conexión limitada. Son reproducibles y muy útiles para depurar, pero no pueden medir INP, porque nadie interactúa con la página. Lighthouse informa en su lugar del Total Blocking Time (TBT), que se correlaciona bien con los problemas de INP.

Usa los datos de laboratorio para encontrar las causas y los datos de campo para confirmar que una corrección ha funcionado para los visitantes reales. Los valores de campo cambian de forma gradual, porque primero tiene que renovarse la ventana de 28 días.

Cómo mejorar el LCP

La mayoría de los LCP lentos tienen su origen en cuatro puntos: una respuesta lenta del servidor, una hoja de estilos o un script que bloquean el renderizado, una imagen principal que se descubre tarde o una imagen que simplemente es demasiado grande.

• Mantén bajo el tiempo de respuesta del servidor (TTFB) con caché de página y una CDN.
• No apliques carga diferida (lazy loading) a la imagen principal. Dale fetchpriority="high" y, si se define en CSS, precárgala.
• Sirve la imagen principal en un formato moderno (AVIF o WebP) y al tamaño con el que se muestra, con srcset para las distintas pantallas.
• Incluye el CSS crítico en línea o mantén pequeña la hoja de estilos principal, y aplaza los scripts que no hacen falta para la primera pantalla.
• Sustituye los carruseles de portada y los vídeos con reproducción automática por una sola imagen estática potente siempre que sea posible.

Cómo mejorar el INP

Un INP deficiente casi siempre significa que el hilo principal está ocupado cuando el usuario interactúa. Lo habitual es un exceso de JavaScript, y los scripts de terceros suelen ser la mayor parte.

• Elimina los scripts que ya no uses, sobre todo los restos de aplicaciones antiguas, plugins y pruebas con el gestor de etiquetas.
• Carga los chats, los mapas de calor y los widgets de reseñas cuando la página ya sea interactiva, o solo cuando el usuario los abra.
• Divide las tareas largas en otras más pequeñas y mantén ligeros los controladores de clic, para que el navegador pueda pintar enseguida tras cada interacción.
• Evita árboles DOM enormes: los menús y las cuadrículas de productos muy grandes ralentizan cada actualización.

Cómo mejorar el CLS

Los saltos de diseño se producen cuando el navegador no sabe cuánto espacio va a necesitar un elemento hasta que este se carga.

• Define width y height (o aspect-ratio) en todas las imágenes, vídeos e iframes.
• Reserva espacio para los anuncios, los avisos de cookies y los contenidos incrustados en lugar de empujar el contenido hacia abajo cuando aparecen.
• Usa font-display: swap con una fuente alternativa de tamaño similar, o precarga la fuente web principal, para reducir el reajuste del texto.
• No insertes nunca contenido por encima del que ya se muestra, salvo que el usuario lo haya pedido.

Qué muestra el informe de Sitequiry

Sitequiry ejecuta Google PageSpeed Insights en móvil y en escritorio y muestra LCP, FCP, TBT y CLS en franjas basadas en los umbrales anteriores, junto con la secuencia de carga (filmstrip) y el peso de la página por tipo de recurso. Cuando Google dispone de datos de campo de CrUX para la URL o el origen, el informe también los utiliza. Si PageSpeed no está disponible, el informe lo indica y marca la puntuación de velocidad como estimación en lugar de inventar cifras.

Para ver estos valores en tu propia web puedes hacer un análisis gratis. Si quieres más contexto sobre cómo interpretar los resultados, consulta la guía para medir la velocidad web.

Preguntas frecuentes