Core Web Vitals (Métricas web esenciales)

TL;DR — Los Core Web Vitals (Métricas web esenciales) son tres puntuaciones que Google usa para medir cómo se siente una página para los usuarios reales: cuánto tarda en cargar (LCP), con qué rapidez responde cuando se toca o se hace clic (INP) y cuánto se mueven los elementos mientras carga (CLS). «Bueno» es un LCP por debajo de 2,5 segundos, un INP por debajo de 200 milisegundos y un CLS por debajo de 0,1. Influyen un poco en el posicionamiento, pero el buen contenido importa mucho más.

Qué son los Core Web Vitals

Google quiere premiar las páginas que resultan agradables de usar, así que redujo la «buena experiencia de página» a tres aspectos medibles. En conjunto son los Core Web Vitals (Métricas web esenciales), a menudo abreviados como CWV:

• Largest Contentful Paint (LCP): carga. Cuánto tarda en aparecer el elemento más grande de la pantalla (normalmente una imagen principal o un titular). Lo bueno es ≤ 2,5 segundos.
• Interaction to Next Paint (INP): capacidad de respuesta. Cuando se toca un botón o se escribe, cuánto tarda la página en reaccionar. Lo bueno es ≤ 200 milisegundos.
• Cumulative Layout Shift (CLS): estabilidad visual. Cuánto se mueve la página mientras carga (un anuncio empuja el texto hacia abajo justo cuando se va a tocar). Lo bueno es ≤ 0,1.

De dónde salen las puntuaciones

Las puntuaciones que Google usa realmente provienen de personas reales que visitan su sitio en Chrome, no de una prueba que usted ejecute. Google recopila esos datos y una página se evalúa según lo que experimentó el 75 % de los visitantes. Por eso no se puede «aprobar» consiguiendo un resultado rápido en el equipo propio: la mayoría de los visitantes reales deben tener una buena experiencia. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

Por eso una puntuación perfecta en una herramienta de medición de velocidad no garantiza aprobar. Esas herramientas (como PageSpeed Insights y Lighthouse) ejecutan una única prueba de laboratorio en un teléfono simulado: excelentes para detectar problemas, pero no son las cifras con las que Google posiciona.

¿Afectan al posicionamiento?

Algo. Google dice que sus sistemas de posicionamiento usan los Core Web Vitals, pero no hay ningún peso ni porcentaje oficial asociado a ellos, y Google es explícito: un contenido relevante puede seguir posicionándose por encima de una página con una experiencia de página deficiente. Si el contenido no es relevante, la rapidez y la estabilidad no lo salvarán. Como dijo John Mueller, de Google, “it’s not going to make your site’s rankings jump up.” (traducción) «no va a hacer que el posicionamiento de su sitio se dispare».

Mi opinión sincera después de años en esto: la mayoría de los sitios no verán un gran beneficio de posicionamiento por perseguir estas cifras. Pero no hay nada de malo en hacer que su sitio sea más rápido y más estable: los visitantes lo notan y ayuda a la conversión incluso cuando no mueve el posicionamiento.

Algo que la gente entiende mal

Aviso de nombre antiguo: puede que todavía vea mencionado el FID (First Input Delay) como un Core Web Vital. Ya no existe: el INP sustituyó al FID el 12 de marzo de 2024. Si una herramienta o un artículo todavía le dice que optimice el FID, está desactualizado.

¿Quiere la versión más profunda: umbrales exactos, datos de campo frente a datos de laboratorio, cuánto pesa realmente para el posicionamiento y qué herramienta usar en cada caso? Cambie a la pestaña Avanzado.

TL;DR — Los Core Web Vitals (Métricas web esenciales) son tres métricas de experiencia de usuario medidas en campo: LCP (carga, «bueno» ≤ 2,5 s), INP (capacidad de respuesta, ≤ 200 ms) y CLS (estabilidad visual, ≤ 0,1), cada una evaluada en el percentil 75 de usuarios reales de Chrome (CrUX) en una ventana móvil de 28 días. Los umbrales son los mismos para móvil y escritorio, pero Google evalúa cada uno por separado y espera que las tres métricas sean buenas, no solo una. El INP sustituyó al FID el 12 de marzo de 2024. Google dice que sus sistemas de posicionamiento usan los Core Web Vitals, pero no hay ningún peso ni porcentaje oficial de «desempate» asociado: una buena puntuación no garantiza un mejor posicionamiento y la relevancia puede seguir ganando. Las puntuaciones de laboratorio (Lighthouse/PSI) son mediciones de diagnóstico y a menudo no coinciden con los datos de campo. El TTFB y el FCP son «otras Web Vitals» de diagnóstico; el TBT y el Speed Index son aproximaciones de laboratorio.

Qué cuenta como Core Web Vital

Google define los Core Web Vitals (Métricas web esenciales) como “the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (traducción) «el subconjunto de Web Vitals que se aplica a todas las páginas web, que todos los propietarios de sitios deberían medir y que aparecerá en todas las herramientas de Google». Hay exactamente tres, y cada una mide una dimensión distinta de cómo se siente una página:

Google evalúa los tres umbrales «buenos» en el percentil 75: el LCP en 2,5 segundos, el INP en 200 milisegundos y el CLS en 0,1. Una página solo se considera «buena» en conjunto cuando las tres superan su límite en el p75, no solo una o dos. Los umbrales en sí son los mismos para móvil y escritorio, aunque Google evalúa e informa de cada clase de dispositivo por separado. Evidence for this claim Core Web Vitals are assessed at the 75th percentile, with good thresholds of 2.5 seconds for LCP, 200 milliseconds for INP, and 0.1 for CLS. Scope: Current stable Core Web Vitals definitions from the Chrome team. Confidence: high · Verified: 2026-07-14 web.dev: Web Vitals

Todo lo demás de lo que haya oído hablar —TTFB, FCP, TBT, Speed Index— no es un Core Web Vital. Más sobre ello más abajo.

LCP: carga

El LCP “reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (traducción) «informa del tiempo de renderizado de la imagen, el bloque de texto o el video más grande visible en el viewport, en relación con el momento en que el usuario navegó por primera vez a la página». En la práctica, el elemento LCP suele ser una imagen principal, una imagen de fondo grande o el bloque del titular. Tenga en cuenta que es el elemento visible más grande: distintos tamaños de viewport pueden tener elementos LCP distintos, lo que es una de las razones por las que las cifras de campo y de laboratorio difieren.

INP: capacidad de respuesta

El INP “assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (traducción) «evalúa la capacidad de respuesta global de una página a las interacciones del usuario observando la latencia de todas las interacciones de clic, toque y teclado que se producen durante toda la duración de la visita de un usuario a una página». Mide la interacción completa: retardo de entrada → procesamiento del controlador de eventos → tiempo hasta pintar el siguiente fotograma.

Esta es la gran mejora respecto a la métrica a la que sustituyó. El INP mejora al FID al observar todas las interacciones, no solo la primera: el FID solo medía el retardo de entrada de la primerísima interacción. El INP se convirtió en Core Web Vital el 12 de marzo de 2024, sustituyendo a First Input Delay (FID). Evidence for this claim INP became a Core Web Vital and replaced FID on March 12, 2024. Scope: Chrome and Google tooling transition from FID to INP. Confidence: high · Verified: 2026-07-14 web.dev: INP launch Ese mismo día se eliminó el FID de Search Console. Está totalmente retirado: no lo optimice.

Un matiz que conviene retener: el INP no es su peor interacción individual, sino un percentil alto de todas ellas. Un único clic con tirones no hundirá una página que por lo demás es buena.

CLS: estabilidad visual

El CLS “is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (traducción) «es una medida de la mayor ráfaga de puntuaciones de cambio de diseño de cada cambio de diseño inesperado que se produce durante todo el ciclo de vida de una página». La «ráfaga» (ventana de sesión) agrupa los cambios que se producen en un intervalo de 1 segundo entre sí, hasta una ventana total de 5 segundos. Los culpables habituales que menciona Google: “images or videos with unknown dimensions,” (traducción) «imágenes o videos con dimensiones desconocidas»; “fonts that render larger or smaller than its initial fallback,” (traducción) «fuentes que se renderizan más grandes o más pequeñas que su alternativa inicial»; y “third-party ads or widgets that dynamically resize themselves.” (traducción) «anuncios o widgets de terceros que cambian de tamaño dinámicamente».

Datos de campo frente a datos de laboratorio: medición y diagnóstico

Esta es la distinción que causa más confusión, así que conviene ser preciso con ella.

• Los datos de campo (CrUX) son “data collected from the real users visiting your site.” (traducción) «datos recogidos de los usuarios reales que visitan su sitio». Se informan en el percentil 75, en una ventana móvil de 28 días, segmentados entre móvil y escritorio. Los Core Web Vitals representan este tipo de experiencia del mundo real y los usan los sistemas de posicionamiento de Google. Reflejan dispositivos, redes, estados de caché y caché de retroceso/avance reales.
• Los datos de laboratorio son “data collected in a controlled environment with predefined device and network settings” (traducción) «datos recogidos en un entorno controlado con configuraciones de dispositivo y de red predefinidas»: un único teléfono emulado, caché en frío, sin usuario real. Lighthouse y la sección de laboratorio de PageSpeed Insights los producen. Son una herramienta de diagnóstico para encontrar problemas más que una medición de campo. Evidence for this claim Core Web Vitals are real-world experience metrics used by Google ranking systems; lab measurements are diagnostic and can differ from field measurements. Scope: Google Search use of Core Web Vitals and Chrome UX Report field data. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search web.dev: Lab and field data

La propia recomendación de Google: “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (traducción) «Si tiene datos de campo y datos de laboratorio de una misma página, los datos de campo son los que debería usar para priorizar su trabajo». Y la Performance Score de Lighthouse “often does not correlate with field Core Web Vitals.” (traducción) «a menudo no se correlaciona con los Core Web Vitals de campo». Digo lo mismo en mi guía de Core Web Vitals: los datos de laboratorio son más útiles para probar e iterar, porque los datos de CWV de campo se basan en una media móvil de 28 días: no verá su corrección reflejada en semanas.

La regla del p75 y por qué importa

Una página aprueba solo si el 75 % de los usuarios reales alcanza el umbral «bueno». Es un límite deliberadamente indulgente pero real: la mayoría de sus visitantes (3 de cada 4) tuvo una buena experiencia, mientras que usted no queda a merced de unos pocos casos extremos con conexiones malísimas. También es la razón por la que ver una carga de 1,8 s en su teléfono no significa nada por sí solo: lo que cuenta es su p75 sobre todo el conjunto.

Nivel de página frente a nivel de origen: no se deje engañar

Muchas herramientas muestran de forma predeterminada una puntuación de nivel de origen (la media de todo el sitio), que puede ser mucho más halagüeña que la de sus páginas individuales. En mi estudio de datos de CWV (CrUX más 5,2 millones de páginas de Ahrefs Site Audit), solo el 21,2 % de las páginas individuales superó los tres umbrales, frente al 33 % a nivel de origen. La documentación de experiencia de página de Google dice que sus sistemas suelen evaluar las páginas de forma individual, aunque también realiza evaluaciones más amplias de todo el sitio, por lo que un origen que «aprueba» puede seguir ocultando muchas páginas individuales que fallan. Cuando una herramienta ofrezca ambas vistas, no dé por sentado que la media de nivel de origen le dice qué está haciendo una página concreta; consulte también la cifra a nivel de página.

Un problema relacionado: las páginas sin tráfico suficiente no tienen ningún dato de campo de CrUX, y CrUX solo incluye a los usuarios de Chrome que han aceptado compartir estadísticas de uso (no hay Chrome en iOS ni otros navegadores). Eso es una laguna de elegibilidad de datos, no un suspenso: la falta de datos de campo no es lo mismo que una puntuación deficiente. Cómo agrupa exactamente una herramienta concreta las páginas similares o qué alternativa aplica a las URL con poco tráfico (PSI, Search Console, la API de CrUX) lo documenta ese producto concreto, no una única regla universal.

¿Cuánto importan realmente los Core Web Vitals para el posicionamiento?

Son una señal de posicionamiento confirmada: Google dice que sus sistemas de posicionamiento usan los Core Web Vitals. Lo que la documentación actual de Google no hace es asignar a esa señal un peso, un porcentaje o una etiqueta de «desempate» oficiales, así que tenga cuidado de no repetir esos enfoques como si fueran palabras de Google.

Del lado de «es real»: la documentación de Google dice que los Core Web Vitals “along with other page experience aspects, aligns with what our core ranking systems seek to reward,” (traducción) «junto con otros aspectos de la experiencia de página, se alinea con lo que nuestros sistemas de posicionamiento principales buscan premiar», y John Mueller declaró oficialmente que es “more than a tie-breaker, but it also doesn’t replace relevance.” (traducción) «más que un desempate, pero tampoco sustituye a la relevancia».

Del lado de «no se exceda»: Mueller también dijo “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that,” (traducción) «los Core Web Vitals no son factores gigantes en el posicionamiento, y dudo que se viera una caída grande solo por eso», y en la actualización de la documentación de marzo de 2024 añadió a través de LinkedIn que “it’s not going to make your site’s rankings jump up.” (traducción) «no va a hacer que el posicionamiento de su sitio se dispare». La propia documentación de experiencia de página de Google es rotunda: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (traducción) «La Búsqueda de Google siempre busca mostrar el contenido más relevante, aunque la experiencia de página sea deficiente». La documentación de 2024 incluso advierte de que “trying to get a perfect score just for SEO reasons may not be the best use of your time.” (traducción) «intentar conseguir una puntuación perfecta solo por motivos de SEO puede no ser el mejor uso de su tiempo». Evidence for this claim Google says Core Web Vitals are used by ranking systems, while page experience does not override more relevant content. Scope: Google Search ranking guidance; no fixed weight or ranking-position effect is promised. Confidence: high · Verified: 2026-07-14 Google: Core Web Vitals and Search Google: Page experience

Mi lectura pragmática: la relevancia domina, Google no ha puesto una cifra a cuánto cuentan los CWV y la mayoría de los sitios no verán un gran beneficio al trabajarlos para el posicionamiento. Dicho esto, las mejoras de experiencia de usuario subyacentes merecen la pena por los usuarios y por la conversión, y las plataformas (WordPress, Cloudflare, los frameworks) siguen absorbiendo automáticamente buena parte de la carga de optimización. Para las pequeñas empresas y los negocios locales en particular, esto normalmente no debería estar al principio de la lista.

Una aclaración más de la actualización de 2024: de las señales más amplias de experiencia de página, solo se confirma que los Core Web Vitals contribuyen directamente al posicionamiento. HTTPS, la adaptación a móviles, la ausencia de intersticiales intrusivos, la claridad del contenido: todo son buenas prácticas, pero no impulsan directamente el posicionamiento como la documentación insinuó en su momento.

Las «otras Web Vitals»: de diagnóstico, no Core

Aparecen constantemente y se clasifican mal. Ninguna de ellas es un Core Web Vital:

• Time to First Byte (TTFB): cuánto tarda en llegar el primer byte de la respuesta. “precedes every other meaningful loading performance metric” (traducción) «precede a cualquier otra métrica significativa de rendimiento de carga» y alimenta al LCP, pero Google es explícito: “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold.” (traducción) «Como el TTFB no es una métrica de Core Web Vitals, no es absolutamente necesario que los sitios cumplan el umbral ‘bueno’ de TTFB». (Bueno ≤ 0,8 s.) De diagnóstico.
• First Contentful Paint (FCP): tiempo hasta que se pinta cualquier contenido. Un diagnóstico de carga útil (bueno ≤ 1,8 s), pero no es Core.
• Total Blocking Time (TBT): una aproximación de laboratorio al INP. Herramientas como Lighthouse “cannot measure INP” (traducción) «no pueden medir el INP» sin un usuario real, así que informan del TBT en su lugar. Solo laboratorio.
• Speed Index: una aproximación de laboratorio a la velocidad de carga percibida. Solo en Lighthouse.

Úselas para depurar. No las presente como Core Web Vitals ni trate sus umbrales como puertas de posicionamiento.

Un mito que hay que retirar

Puede que vea propuesta la «Engagement Reliability» como un nuevo Core Web Vital. No existe ningún anuncio oficial de Google sobre esa métrica: solo circula en contenido de terceros. Los Core Web Vitals son LCP, INP y CLS. Hasta que Google diga lo contrario, esa es la lista.

Cómo medirlos y qué herramienta usar para cada cosa

Ajuste la herramienta a la tarea:

• Relevantes para el posicionamiento (datos de campo): PageSpeed Insights (muestra los datos de campo de CrUX a nivel de página y de origen), el informe Core Web Vitals de Google Search Console (agrupa páginas similares y revela patrones de todo el sitio), la API de CrUX / BigQuery (análisis personalizados y por país) y la biblioteca de JavaScript web-vitals (para recoger sus propios datos de RUM).
• Depuración (datos de laboratorio): Lighthouse, el panel Performance de Chrome DevTools y la sección de laboratorio de PSI. Estas encuentran la causa; no deciden su posicionamiento.

El flujo de trabajo que sugeriría: usar GSC para encontrar qué grupos de páginas están fallando en campo, confirmarlo con PageSpeed Insights a nivel de página y después entrar en Lighthouse / DevTools para diagnosticar e iterar, sabiendo que las cifras de campo no se actualizarán hasta 28 días después.

Adónde ir después: el clúster de rendimiento web

Este hub es el mapa. Cada tema de abajo es su propio análisis en profundidad.

Los tres Core Web Vitals

• Largest Contentful Paint: la métrica de carga; qué cuenta como elemento LCP, el objetivo de ≤2,5 s y cómo lograr que se pinte antes.
• Interaction to Next Paint: la métrica de capacidad de respuesta que sustituyó al FID; retardo de entrada, procesamiento de eventos y retardo de presentación, y cómo reducir cada uno.
• Cumulative Layout Shift: la métrica de estabilidad visual; ventanas de sesión, las causas habituales (medios con dimensiones declaradas, fuentes, anuncios inyectados) y cómo alcanzar ≤0,1.

Métricas de apoyo y de diagnóstico

• Time to First Byte: latencia del servidor/respuesta que alimenta al LCP; útil para depurar, no es un Core Web Vital.
• First Contentful Paint: cuándo se pinta el primer contenido; un diagnóstico de carga.
• Total Blocking Time: la aproximación de laboratorio que usa Lighthouse para aproximar el INP.
• Speed Index: la aproximación de laboratorio a la velocidad de carga percibida.

Cómo se miden

• PageSpeed Insights: datos de campo (CrUX) más un informe de laboratorio de Lighthouse en un mismo lugar.
• Google Lighthouse: el motor de laboratorio/diagnóstico que hay detrás de PSI y DevTools.
• Chrome UX Report (CrUX): el conjunto de datos de usuarios reales sobre el que se ejecuta la evaluación de Google.

Para todo el clúster, consulte el hub de rendimiento web. Cada artículo hermano enlaza aquí automáticamente en cuanto se publica.

Resumen con IA

Una versión condensada de la pestaña Advanced:

• Core Web Vitals = tres métricas de campo: LCP (carga, bueno ≤ 2,5 s), INP (capacidad de respuesta, ≤ 200 ms), CLS (estabilidad visual, ≤ 0,1). Todo lo demás (TTFB, FCP, TBT, Speed Index) no es Core.
• Se evalúan con datos de campo: usuarios reales de Chrome mediante CrUX, en el percentil 75, en una ventana móvil de 28 días. Los umbrales son los mismos para móvil y escritorio pero se evalúan por separado, y Google espera que las tres métricas sean buenas, no solo una.
• El INP sustituyó al FID el 12 de marzo de 2024. El FID está totalmente retirado; el INP mide todas las interacciones, no solo la primera.
• Las herramientas de laboratorio (Lighthouse/PSI) son de diagnóstico, no mediciones de campo, y a menudo no coinciden con los CWV de campo. Úselas para encontrar causas; las cifras de campo se retrasan hasta 28 días.
• El nivel de página frente al de origen importa: ~21,2 % de las páginas aprueban frente a ~33 % de los orígenes (mi estudio de CWV). Google usa el nivel de página: las medias de origen ocultan páginas que fallan.
• Peso en el posicionamiento: se usan, pero sin peso declarado. Google dice que sus sistemas de posicionamiento usan los Core Web Vitals, sin ningún porcentaje ni etiqueta de «desempate» oficiales asociados; la relevancia domina y una buena puntuación no garantiza el posicionamiento. Mueller: “not giant factors in ranking.” (traducción) «no son factores gigantes en el posicionamiento». Según la documentación de 2024, solo los CWV (no HTTPS, ni la adaptación a móviles, ni los intersticiales) contribuyen directamente.
• Mito que saltarse: «Engagement Reliability» no es un Core Web Vital confirmado.
• Herramientas: campo = PSI, informe Core Web Vitals de GSC, API de CrUX, web-vitals.js; depuración = Lighthouse, DevTools, sección de laboratorio de PSI.

Documentación oficial

Documentación de fuente primaria de Google.

web.dev (equipo de Chrome)

• Web Vitals: la iniciativa, las tres métricas, la regla del p75 y por qué el TTFB y el FCP son «otras» Web Vitals.
• Largest Contentful Paint (LCP): definición, umbrales y elementos que pueden ser el LCP.
• Interaction to Next Paint (INP): definición, umbrales y el desglose retardo de entrada → procesamiento → presentación.
• Cumulative Layout Shift (CLS): definición, ventanas de sesión y causas habituales.
• Definición de los umbrales de las métricas de Core Web Vitals: por qué se eligieron cada umbral «bueno» y el percentil 75.
• Diferencias entre datos de laboratorio y de campo: por qué difieren las cifras de campo (CrUX) y de laboratorio (Lighthouse).
• Flujos de trabajo y herramientas de Core Web Vitals: qué herramienta informa de datos de campo y cuál de datos de laboratorio.
• El INP avanza a Core Web Vitals (mayo de 2023): el anuncio de que el INP sustituiría al FID.
• Interaction to Next Paint es oficialmente una Core Web Vital (12 de marzo de 2024): la confirmación del lanzamiento.
• TTFB y FCP: las «otras Web Vitals» de diagnóstico.

Google Search Central

• Entender Core Web Vitals y los resultados de búsqueda de Google: cómo se relacionan los CWV con el posicionamiento.
• Entender la experiencia de página en los resultados de búsqueda de Google: el panorama más amplio de la experiencia de página y el enfoque de «la relevancia gana».
• Presentación del INP en Core Web Vitals (mayo de 2023): el anuncio de Search Central.

Chrome para desarrolladores

• Informe de experiencia de usuario de Chrome (CrUX): el conjunto de datos de usuarios reales, la elegibilidad y la ventana de 28 días.

Citas de la fuente

Declaraciones oficiales de Google. Cada enlace es un enlace profundo que salta al pasaje citado en la página de origen.

Google: qué son los Core Web Vitals

• “Core Web Vitals are the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools.” (traducción) «Los Core Web Vitals son el subconjunto de Web Vitals que se aplica a todas las páginas web, que todos los propietarios de sitios deberían medir y que aparecerá en todas las herramientas de Google.» — Philip Walton, web.dev. Ir a la cita
• “LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page.” (traducción) «El LCP informa del tiempo de renderizado de la imagen, el bloque de texto o el video más grande visible en el viewport, en relación con el momento en que el usuario navegó por primera vez a la página.» — web.dev (LCP). Ir a la cita
• “INP is a metric that assesses a page’s overall responsiveness to user interactions by observing the latency of all click, tap, and keyboard interactions that occur throughout the lifespan of a user’s visit to a page.” (traducción) «El INP es una métrica que evalúa la capacidad de respuesta global de una página a las interacciones del usuario observando la latencia de todas las interacciones de clic, toque y teclado que se producen durante toda la duración de la visita de un usuario a una página.» — web.dev (INP). Ir a la cita
• “CLS is a measure of the largest burst of layout shift scores for every unexpected layout shift that occurs during the entire lifecycle of a page.” (traducción) «El CLS es una medida de la mayor ráfaga de puntuaciones de cambio de diseño de cada cambio de diseño inesperado que se produce durante todo el ciclo de vida de una página.» — web.dev (CLS). Ir a la cita

Google: el INP sustituye al FID

• “Interaction to Next Paint (INP) is now a stable Core Web Vital metric, replacing First Input Delay (FID).” (traducción) «Interaction to Next Paint (INP) es ya una métrica estable de Core Web Vitals, en sustitución de First Input Delay (FID).» — Rick Viscomi, web.dev (12 de marzo de 2024). Ir a la cita

Google: campo frente a laboratorio, y posicionamiento

• “If you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.” (traducción) «Si tiene datos de campo y datos de laboratorio de una misma página, los datos de campo son los que debería usar para priorizar su trabajo.» — Philip Walton, web.dev. Ir a la cita
• “The Chrome User Experience Report (also known as the Chrome UX Report, or CrUX for short) is a dataset that reflects how real-world Chrome users experience popular destinations on the web.” (traducción) «El Chrome User Experience Report (también conocido como Chrome UX Report o, abreviado, CrUX) es un conjunto de datos que refleja cómo experimentan los usuarios reales de Chrome los destinos populares de la web.» — Chrome for Developers (documentación de CrUX). Ir a la cita

John Mueller, Google

• “It is a ranking factor, and it’s more than a tie-breaker, but it also doesn’t replace relevance.” (traducción) «Es un factor de posicionamiento, y es más que un desempate, pero tampoco sustituye a la relevancia.» — vía Search Engine Journal (Reddit, agosto de 2021). Leer la cobertura
• “Core Web Vitals are not giant factors in ranking, and I doubt you’d see a big drop just because of that.” (traducción) «Los Core Web Vitals no son factores gigantes en el posicionamiento, y dudo que se viera una caída grande solo por eso.» — vía Stan Ventures (2024). Leer la cobertura

Lista de comprobación de Core Web Vitals

Una revisión rápida para confirmar que está midiendo lo correcto y corrigiendo las páginas correctas:

• Está leyendo datos de campo (CrUX), no solo una puntuación de laboratorio, para las métricas con las que Google posiciona.
• Está mirando cifras a nivel de página, no solo la media de nivel de origen.
• Se comprueban las tres: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 en el p75.
• Móvil y escritorio se revisan por separado (Google evalúa cada uno).
• No está optimizando el FID: se retiró el 12 de marzo de 2024 (use el INP).
• Se ha revisado el informe Core Web Vitals de GSC buscando grupos de páginas que fallan, no casos aislados.
• Entiende que las páginas con poco tráfico pueden no tener ningún dato de campo de CrUX.
• Las herramientas de laboratorio (Lighthouse/PSI) se usan para diagnosticar, no como puerta de aprobado/suspenso, y no está esperando una Performance Score perfecta.
• Está dando hasta 28 días para que las correcciones aparezcan en campo.
• No está persiguiendo los CWV por delante de la relevancia del contenido y de logros de SEO mayores.

Los modelos mentales

1. Tres dimensiones, tres métricas. LCP = carga, INP = capacidad de respuesta, CLS = estabilidad visual. Si puede nombrar en qué dimensión vive un problema, sabe qué métrica (y qué análisis en profundidad) abrir.

2. El campo es para posicionar; el laboratorio, para corregir. Google posiciona con los datos de campo de CrUX en el p75 a lo largo de 28 días. Las puntuaciones de laboratorio de Lighthouse/PSI encuentran causas. Nunca trate una puntuación de laboratorio como su cifra de posicionamiento: a menudo ni siquiera se correlacionan.

3. El nivel de página gana al nivel de origen. Un origen que «aprueba» puede ocultar páginas que fallan. Google usa datos a nivel de página cuando los tiene. Cuando una herramienta muestre ambos, confíe en la vista a nivel de página.

4. Se usan, pero sin peso declarado. Los CWV son una señal de posicionamiento confirmada a la que Google nunca ha asignado un peso oficial: la relevancia puede seguir prevaleciendo sobre ella. Corrija los CWV por los usuarios y la conversión; no espere que el posicionamiento dé un salto.

5. La prueba del «¿es siquiera Core?». Solo LCP, INP y CLS son Core Web Vitals. El TTFB y el FCP son de diagnóstico; el TBT y el Speed Index son aproximaciones de laboratorio. La «Engagement Reliability» no está confirmada en absoluto.

Core Web Vitals: hoja de referencia rápida

Los tres Core Web Vitals (datos de campo, p75)

Métricas de diagnóstico: NO son Core Web Vitals

Datos rápidos

• Evaluación = datos de campo de CrUX, percentil 75, ventana móvil de 28 días, móvil y escritorio por separado.
• El INP sustituyó al FID el 12 de marzo de 2024. El FID está totalmente retirado.
• Las puntuaciones de laboratorio (Lighthouse/PSI) son de diagnóstico, no mediciones de campo, y a menudo no coinciden con los CWV de campo.
• Google usa el nivel de página; las medias de nivel de origen pueden engañar (~21,2 % de las páginas aprueban frente a ~33 % de los orígenes en mi estudio de CWV).
• Peso en el posicionamiento: los usan los sistemas de posicionamiento de Google, sin peso oficial declarado: la relevancia domina y una buena puntuación no es ninguna garantía.
• La «Engagement Reliability» no es un Core Web Vital confirmado.

¿Qué Core Web Vital debería investigar primero?

Los Core Web Vitals empeoran después de un despliegue

1. Confirme la señal. Separe campo de laboratorio, URL de origen y móvil de escritorio. Si solo cambió una ejecución de laboratorio, reprodúzcala antes de declarar un incidente.
2. Identifique la métrica que falla. LCP, INP y CLS representan problemas distintos. Si se movieron varias, revise primero los cambios compartidos del despliegue y los scripts de terceros.
3. Vincule la regresión a un despliegue. Compare RUM o trazas de laboratorio repetibles antes y después del despliegue. Si los tiempos no cuadran, inspeccione en su lugar la mezcla de tráfico y dispositivos.
4. Diagnostique la métrica, no la puntuación. Para el LCP, inspeccione el elemento y sus subpartes; para el INP, las interacciones lentas y el trabajo en el hilo principal; para el CLS, las fuentes de los cambios de diseño.
5. Publique la corrección más pequeña atribuible. Válidela de inmediato en laboratorio. Si rompe alguna funcionalidad o empeora otra métrica, revierta.
6. Observe a los usuarios reales. Use RUM como señal adelantada y CrUX/Search Console para el veredicto de campo móvil. Documente el alcance y la ventana para que las partes interesadas no esperen un reinicio de CrUX el mismo día.

Errores con los Core Web Vitals que hacen perder trabajo

Optimizar la puntuación compuesta de Lighthouse

La evaluación de campo de Google usa LCP, INP y CLS a partir de datos de usuarios reales, no la cifra única de Performance de Lighthouse. Diagnostique la métrica de campo que falla y use Lighthouse como un entorno controlado de depuración.

Tratar los Core Web Vitals como un atajo de posicionamiento

Los CWV son una señal de experiencia de página a la que Google nunca ha asignado un peso oficial; la relevancia sigue dominando. Corrija una experiencia deficiente para los usuarios, pero no prometa un salto de posicionamiento ni desplace trabajo más importante de contenido y de indexación sin pruebas.

Mezclar valores de URL, origen, móvil y escritorio

Distintos alcances pueden contar historias distintas. Etiquete cada valor y no afirme que una página aprueba porque una alternativa de origen o un agregado de escritorio esté en verde.

Esperar a CrUX antes de comprobar un despliegue

La ventana móvil de 28 días es demasiado lenta para el control de calidad de un despliegue. Valide el mecanismo de inmediato en laboratorio y con RUM, y después use CrUX para confirmar el resultado de campo a más largo plazo.

Herramientas para medir los Core Web Vitals

Compruébelo con Core Web Vitals History & Competitor Comparison:

1. Añada un sitio (un origen simple como example.com es el que más datos de CrUX tiene; añada hasta 5 para comparar).
2. Elija móvil o escritorio y ejecute la comparación.
3. Lea el marcador para ver el aprobado/suspenso de hoy en LCP, INP y CLS, y después el gráfico de tendencia semanal para ver si cada métrica se acerca a la banda buena o se aleja de ella.

Datos de campo: medición de Core Web Vitals con usuarios reales

• PageSpeed Insights: datos de campo de CrUX a nivel de página y de origen, además de un informe de laboratorio de Lighthouse al lado.
• Google Search Console, informe Core Web Vitals: agrupa páginas similares y revela patrones de campo de todo el sitio; la forma más rápida de encontrar grupos de páginas que fallan.
• API de CrUX / BigQuery: análisis personalizados y por país directamente desde el conjunto de datos original.
• Biblioteca de JavaScript web-vitals: recoja sus propios datos de usuarios reales (RUM) y, por ejemplo, envíelos a su analítica.

Datos de laboratorio: para depurar (no para posicionar)

• Lighthouse: oportunidades de diagnóstico y la Performance Score (que no interviene en el posicionamiento).
• Panel Performance de Chrome DevTools: depuración a nivel de traza del LCP, los cambios de diseño y las tareas largas.
• Sección de laboratorio de PageSpeed Insights: las recomendaciones basadas en Lighthouse que aparecen debajo de los datos de campo.

Regla general: GSC para encontrar dónde está fallando en campo → PSI para confirmarlo a nivel de página → Lighthouse / DevTools para diagnosticar e iterar.

Recursos que merecen su tiempo

Mis textos relacionados

• Core Web Vitals: cómo mejorarlas (Ahrefs): mi guía práctica completa de las tres métricas y de qué corregir.
• Estudio de datos de Core Web Vitals (Ahrefs): CrUX + 5,2 millones de páginas; el hallazgo sobre la tasa de aprobados a nivel de página frente al nivel de origen.
• Guía de Largest Contentful Paint (LCP) (Ahrefs).
• Guía de Cumulative Layout Shift (CLS) (Ahrefs).
• Guía de PageSpeed Insights (Ahrefs).
• Guía para principiantes de SEO técnico: dónde encaja la experiencia de página en el panorama general.

Oficiales

• web.dev — Web Vitals y los artículos de cada métrica enlazados en Documentación oficial.
• Google updates its page experience docs to clarify ranking signals (Search Engine Land): Barry Schwartz sobre el cambio de documentación de marzo de 2024.

Del sector

• Factor de clasificación de Google: Core Web Vitals, más que un desempate (Search Engine Journal): cobertura de la declaración de John Mueller en Reddit de que los CWV son «más que un desempate» pero no sustituyen a la relevancia.
• Prioridad de Core Web Vitals de Google para pequeñas empresas y negocios locales (Search Engine Roundtable): el comentario de Mueller en Mastodon de que el trabajo en CWV no debería ser la máxima prioridad para pequeñas empresas y negocios locales.
• Confirmado: Core Web Vitals no es un factor importante de clasificación (Stan Ventures): la cita de Mueller «no son factores gigantes en el posicionamiento» en su contexto.
• Impacto de Core Web Vitals en el SEO (RUMvision): actualizado en noviembre de 2025; recopilación exhaustiva en formato de preguntas frecuentes de citas de portavoces y matices sobre la señal de posicionamiento.
• Actualización de experiencia de página de Google: desempate (Search Engine Roundtable): el primer enfoque de desempate de Mueller/Illyes, anterior al lanzamiento de la actualización.

Datos que merece la pena citar

• Solo alrededor del 21,2 % de las páginas individuales supera los tres Core Web Vitals, frente a alrededor del 33 % a nivel de origen, según mi estudio de datos de CWV (CrUX + 5,2 millones de páginas de Ahrefs Site Audit). Los sistemas de Google suelen evaluar las páginas de forma individual, así que una media halagüeña a nivel de origen puede seguir ocultando muchas páginas que fallan. Fuente
• Donde más cuesta a los sitios es en el LCP. Ese estudio encontró sitios avanzando en el antiguo FID y en el CLS, pero rezagados en el LCP, y que “almost no sites on 3G or slower connections are passing.” (traducción) «casi ningún sitio con conexiones 3G o más lentas está aprobando». Fuente
• Los umbrales «buenos»: LCP ≤2,5 s, INP ≤200 ms, CLS ≤0,1, cada uno en el percentil 75 de los datos de campo; son los objetivos de Core Web Vitals documentados por Google. Fuente
• El INP sustituyó al FID el 12 de marzo de 2024: la fecha en que el FID dejó de ser un Core Web Vital y se eliminó de Search Console. Fuente

Ponga a prueba sus conocimientos: Core Web Vitals

Cinco preguntas rápidas sobre los Core Web Vitals. Elija una respuesta para cada una y compruebe.

Demuestre que una corrección de LCP/INP/CLS realmente ha surtido efecto

La trampa de una corrección de rendimiento es celebrar la puntuación de laboratorio el día en que se publica. El laboratorio (Lighthouse) le dice si el cambio puede funcionar; solo los datos de campo (CrUX) le dicen si funcionó para los usuarios reales, y se mueven con un retraso móvil de 28 días. Ejecute ambos, en ese orden.

Prueba 1: la corrección mejoró la métrica de laboratorio

• Prueba a ejecutar: pase la página por el Core Web Vitals Checker (o por Lighthouse / PageSpeed Insights) antes y después del cambio.
• Resultado esperado: la métrica de laboratorio objetivo se mueve en la dirección correcta; por ejemplo, el elemento LCP se renderiza antes, no hay ningún cambio de diseño nuevo, se resuelve el diagnóstico concreto que estaba corrigiendo.
• Interpretación del fallo: si no hay movimiento en laboratorio, el cambio no tocó la ruta crítica (optimizó un elemento que no era el elemento LCP, o un script que no estaba bloqueando).
• Ventana de seguimiento: inmediata; las pruebas de laboratorio se ejecutan a demanda.
• Desencadenante de reversión: una regresión en otra métrica (corrigió el LCP pero introdujo CLS, o añadió JS que perjudicó al INP); el laboratorio lo detecta antes que los usuarios reales.

Prueba 2: los usuarios reales lo notan de verdad (datos de campo)

• Prueba a ejecutar: siga el p75 de la página o del origen para LCP, INP y CLS en CrUX, con Core Web Vitals History & Competitor Comparison o con el informe Core Web Vitals de GSC.
• Resultado esperado: el p75 de la métrica corregida entra en la banda «Good» y se mantiene ahí (umbrales de Google: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1).
• Interpretación del fallo: si el laboratorio mejoró pero el campo no, la corrección ayudó en una prueba con conexión rápida pero no en la mezcla real de dispositivos y redes, o no hay suficientes URL del grupo que compartan la corrección.
• Ventana de seguimiento: móvil de 28 días; CrUX usa una ventana retrasada de 28 días, así que una corrección necesita unas 4 semanas de datos de campo acumulados antes de que el p75 sea fiable. No lo dé por hecho en la primera semana.
• Desencadenante de reversión: el p75 vuelve a cruzar el umbral «Poor», o el número de URL «Good» en GSC cae tras un cambio de plantilla: una señal clara de que el despliegue causó una regresión del rendimiento para los usuarios reales.

El KPI permanente para este tema

Al margen de validar una corrección concreta, esto es lo que se observa trimestre a trimestre para saber que la experiencia de página está sana. Aquí hay un punto de referencia defendible —Google publica los umbrales—, así que no se inventa ninguna cifra.

p75 de LCP, INP y CLS (datos de campo)

• Métrica: el valor en el percentil 75 de cada Core Web Vital en las visitas reales, por grupo de páginas y dispositivo.
• Qué le dice: si el 75 % de los usuarios reales obtiene una buena experiencia, el límite exacto que usa Google para clasificar una URL como aprobada. El p75 (y no la media) es la cifra que importa porque refleja la cola lenta.
• Cómo obtenerlo: CrUX mediante Core Web Vitals History & Competitor Comparison, el informe Core Web Vitals de GSC (datos de campo agrupados por patrón de URL) o PageSpeed Insights para una sola URL.
• Punto de referencia / rango realista: los propios umbrales de Google: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1 para «Good»; las bandas «Needs improvement» / «Poor» son 2,5–4 s / >4 s, 200–500ms / >500ms y 0,1–0,25 / >0,25. Son las líneas publicadas, no un objetivo inventado.
• Cadencia: ventana móvil de 28 días, así que revíselo mensualmente; comprobarlo a diario solo relee la misma ventana retrasada. Trate las puntuaciones de laboratorio como el indicador adelantado y el p75 de CrUX como el retrasado.

Cobertura de URL «Good» en todo el sitio

• Métrica: la proporción de sus URL indexadas que están en el segmento «Good» del informe Core Web Vitals de GSC (móvil y escritorio se siguen por separado).
• Qué le dice: hasta qué punto se han propagado las correcciones; una sola página rápida no mueve el sitio, los logros a nivel de plantilla sí.
• Cómo obtenerlo: GSC → informe Core Web Vitals → recuento de URL en Good / Needs improvement / Poor a lo largo del tiempo.
• Punto de referencia / rango realista: depende de la situación; varía según sus plantillas y su mezcla de tráfico, así que establezca su propia línea base y aumente con el tiempo la proporción de Good en lugar de perseguir un porcentaje inventado.
• Cadencia: mensual, o semanal justo después de un cambio de plantilla o de tema mientras la ventana de campo se pone al día.

Registro de cambios