Novedades de Core Web Vitals: qué cambió y qué corregir primero
Por Toy Wen Da, Cofundador · Actualizado · 12 min de lectura
Traducido del original en inglés. Léelo en inglés
Si buscas novedades de Core Web Vitals, lo normal es que se deba a un aviso en Search Console o a un cambio de métrica del que te has enterado. La respuesta corta: Interaction to Next Paint (INP) sustituyó a First Input Delay (FID) como Core Web Vital oficial el 12 de marzo de 2024. Abre tu informe de Core Web Vitals en Search Console para ver qué URL están marcadas.
Antes de tocar nada de código, pasa la página por la herramienta gratuita Website Speed Test. Obtiene las puntuaciones de Lighthouse e indica qué métrica de Core Web Vitals está lastrando la página, de modo que sepas si te enfrentas a un problema de carga, de interacción o de diseño antes de abrir una sola línea de código.
Qué ha cambiado realmente en Core Web Vitals últimamente
Las novedades de Core Web Vitals suelen llegar de dos formas: un cambio de métrica o una filtración que confirma cuánto se apoya Google en el comportamiento real de los usuarios entre bambalinas. Ambas ocurrieron en 2024 y ambas siguen influyendo en cómo deberían priorizar las correcciones los equipos hoy.
El cambio de FID a INP
Hasta el 12 de marzo de 2024, Google medía la capacidad de respuesta de las páginas con First Input Delay, o FID. FID solo observaba la primera interacción del visitante con la página: un clic, un toque, una pulsación de tecla. Una página podía superar FID con facilidad y aun así resultar lenta cada vez después.
Interaction to Next Paint cerró esa brecha. INP vigila cada clic, toque y pulsación de tecla durante toda la visita y luego informa de la más lenta que no fuera un caso atípico poco frecuente. Esto importa porque los datos de uso de Chrome muestran que aproximadamente el 90 % del tiempo que un visitante pasa en una página ocurre después de que termine de cargar, no durante la carga. FID medía una pequeña parte de la experiencia. INP mide la parte que los usuarios realmente perciben.
Una buena puntuación de INP es de 200 milisegundos o menos. Todo lo que esté entre 200 y 500 milisegundos cuenta como "Necesita mejorar" (Needs improvement). Por encima de 500 milisegundos, Search Console lo marca como "Deficiente" (Poor).
La filtración de la Content Warehouse API
En marzo de 2024 salió a la luz una serie de documentos internos de la API de Google, y los comentaristas del sector pasaron buena parte de 2025 analizándolos. No reescribió las reglas de Core Web Vitals. Confirmó algo que muchos SEO ya sospechaban: las métricas públicas son un indicador indirecto de un sistema de posicionamiento mucho más amplio, basado en clics.
Según se informa, la documentación filtrada hace referencia a módulos vinculados a datos de uso de Chrome y a un sistema llamado NavBoost, que reordena los resultados usando aproximadamente 13 meses de comportamiento de clics acumulado. La relación con Core Web Vitals es una simple causa y efecto. Una página lenta o inestable genera más "malos clics": visitas en las que alguien hace clic en un resultado, se frustra y vuelve de inmediato a los resultados de búsqueda. Mejorar tus Core Web Vitals no es solo cumplir con un marcador. Elimina una razón para que los visitantes vuelvan a Google.
La cronología a largo plazo
Core Web Vitals no surgió de la nada en 2020. Google lleva más de una década encaminándose hacia esto:
| Año | Cambio | Por qué importa hoy |
|---|---|---|
| 2011 | La actualización Panda penaliza el contenido de baja calidad | Estableció que la calidad percibida por el usuario afecta al posicionamiento, no solo las palabras clave |
| 2014 | HTTPS se convierte en señal de posicionamiento | Primera vez que se confirmó como señal un factor técnico ajeno al contenido |
| 2018 | Actualización Mobile Page Speed | La velocidad de página en móvil recibe su propia señal explícita |
| 2020 | Se anuncia oficialmente Core Web Vitals (actualización Page Experience) | LCP, FID y CLS se convierten en el trío medible |
| 2024 | INP sustituye a FID (12 de marzo) | La capacidad de respuesta se mide a lo largo de toda la visita, no solo en el primer clic |
Cómo comprobar tus Core Web Vitals en Google Search Console, paso a paso
Search Console sigue siendo el lugar gratuito y de referencia para ver cómo puntúan tus páginas según los datos de campo de Google. Así se abre y se interpreta correctamente.
Abrir el informe
- Inicia sesión en Google Search Console y selecciona tu propiedad.
- En la barra lateral izquierda, dentro de Experiencia (Experience), haz clic en Core Web Vitals.
- Verás dos gráficos de resumen: Móvil (Mobile) y Ordenador (Desktop). Haz clic en Abrir informe (Open report) bajo cualquiera de ellos.
- Cada informe muestra grupos de URL ordenados por estado: Deficiente (Poor), Necesita mejorar (Need improvement) y Bueno (Good).
Interpretar los grupos de URL
Search Console no informa de URL individuales por defecto: agrupa páginas similares, normalmente por plantilla. Es intencionado. Si todas tus páginas de producto comparten un mismo diseño, es probable que compartan también un mismo problema de Core Web Vitals.
Entra en un grupo "Deficiente" y verás:
- Qué métrica concreta está fallando (LCP, INP o CLS)
- Una muestra de las URL afectadas
- El número de URL de ese grupo
Aquí es donde suele diagnosticarse una página cuya evaluación de Core Web Vitals aparece como "No superada" (Failed): por plantilla, no a ciegas sobre una sola página.
Después de corregir algo
Una vez publicada una corrección, vuelve al informe y haz clic en Validar corrección (Validate fix) en el grupo de URL afectado. Google vuelve a rastrear una muestra de esas URL en los días siguientes y actualiza el estado cuando recibe suficientes datos de usuarios reales. Esto puede tardar de dos a cuatro semanas, porque los datos de campo de Core Web Vitals necesitan una muestra real de visitas, no un rastreo puntual.
Las tres métricas y sus umbrales
| Métrica | Qué mide | Bueno | Necesita mejorar | Deficiente |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Tiempo hasta que se muestra el elemento visible más grande | 2,5 segundos o menos | 2,5–4 segundos | Más de 4 segundos |
| INP (Interaction to Next Paint) | Retraso entre una acción del usuario y la siguiente respuesta visual | 200 ms o menos | 200–500 ms | Más de 500 ms |
| CLS (Cumulative Layout Shift) | Cuánto se mueve de forma inesperada el contenido visible | 0,1 o menos | 0,1–0,25 | Más de 0,25 |
Google evalúa las tres en el percentil 75 de las cargas de página, según la documentación de Core Web Vitals de web.dev. Eso significa que al menos tres de cada cuatro visitas reales deben alcanzar el nivel "Bueno" para que la página supere la evaluación en conjunto.
Cuándo basta con Google Search Console y cuándo no
Esta es la parte sincera que la mayoría de las guías se salta. El informe de Core Web Vitals de Search Console es gratuito, usa datos de visitantes reales y, para muchos sitios, es realmente suficiente. Pero tiene límites reales.
Dónde Search Console cumple
- Gestionas un solo sitio con unas pocas plantillas. La vista por grupos de URL te dice exactamente qué plantilla está rota.
- Estás revisando una caída puntual. Si una página pasa de repente a "Deficiente" tras una actualización de contenido, los datos de campo de Search Console junto con la herramienta gratuita Website Speed Test normalmente señalarán la causa.
- Solo necesitas datos de campo, no un rastreo de la causa raíz. Search Console te dice qué les ocurre a los usuarios reales. No te dice qué script o imagen lo provocó.
Dónde necesitas algo más que Search Console
- Una página tiene muy poco tráfico para generar datos de campo. Google necesita un volumen mínimo de visitas reales antes de informar de una puntuación. Las páginas con poco tráfico muestran "sin datos" aunque sean realmente lentas.
- Necesitas rastrear la causa real. Search Console te indica la métrica y la plantilla. No te mostrará qué script de terceros está bloqueando el hilo principal. Para eso necesitas Chrome DevTools o una herramienta de laboratorio como Lighthouse.
- El problema se repite en cada versión. Si cada despliegue vuelve a introducir un desplazamiento de diseño, necesitas monitorización en tu flujo de compilación, no una revisión mensual de un informe de GSC.
- Estás en una plataforma con causas a nivel de plugin. En Shopify, por ejemplo, una app de terceros suele ser el verdadero origen de una mala puntuación de INP, y corregirlo implica saber qué apps de Shopify abordan realmente Core Web Vitals en lugar de añadir más peso de seguimiento.
En resumen: Search Console te dice que algo va mal y más o menos dónde. Rara vez te dice exactamente por qué, hasta el nivel del script o la hoja de estilos.
Causas y soluciones habituales por métrica
| Métrica | Causa típica | Lo primero que hay que comprobar | Quién suele corregirlo |
|---|---|---|---|
| LCP | La imagen principal o el bloque de texto principal se carga tarde | ¿Se puede descubrir el elemento LCP en el HTML sin procesar? | Desarrollador frontend o proveedor de hosting |
| LCP | Respuesta lenta del servidor (TTFB alto) | Tiempo de respuesta del servidor y caché | Equipo de hosting o backend |
| INP | Una tarea larga de JavaScript bloquea el hilo principal | ¿Qué acción del usuario se siente retrasada? | Desarrollador frontend |
| INP | Scripts de terceros pesados (anuncios, widgets de chat, rastreadores) | Auditar qué scripts se ejecutan durante la interacción | Marketing o desarrollo, de forma conjunta |
| CLS | Imágenes o anuncios sin dimensiones reservadas | ¿Se mueve el diseño después de la carga? | Desarrollador frontend o equipo de contenidos |
| CLS | Fuentes web que provocan un reflujo del texto | ¿Está bien configurada una fuente de reserva? | Desarrollador frontend |
Errores habituales de los equipos con las novedades de Core Web Vitals
La mayoría de los errores vienen de tratar Core Web Vitals como una única puntuación que maximizar, en lugar de tres problemas distintos e independientes.
- Perseguir un 100 perfecto en PageSpeed Insights. A Google solo le importa que superes el umbral "Bueno". Más allá, estás gastando presupuesto en mejoras invisibles.
- Probar solo la página de inicio. Tu página de inicio puede estar bien mientras todas las páginas de producto fallan. Usa la vista por grupos de URL, no una comprobación puntual.
- Ignorar los datos de móvil. Los Core Web Vitals en ordenador suelen salir mejor que en móvil. El móvil es donde ocurren la mayoría de las visitas, y la mayoría de los abandonos.
- Corregir todos los avisos amarillos a la vez. Prioriza primero las páginas vinculadas a ingresos o a clientes potenciales. Un archivo de blog lento puede esperar.
- Omitir las pruebas de interacción real para INP. Una página puede parecer rápida al cargar y aun así suspender INP en cuanto alguien toca un desplegable o un filtro.
- Cerrar el ticket antes de que los datos se pongan al día. Los datos de campo necesitan visitas reales tras publicar una corrección, normalmente unas semanas, antes de que cambie el estado.
Core Web Vitals también se sitúan junto a otra señal de calidad que Google lleva años impulsando: la accesibilidad. Una página con mal contraste de color o sin texto alternativo suele incumplir los mismos criterios establecidos en las Web Content Accessibility Guidelines (WCAG) del W3C, el estándar oficial detrás de la mayoría de las auditorías de accesibilidad, y a menudo comparte las mismas causas de fondo que una página con problemas de desplazamiento de diseño; por eso corregir los problemas de accesibilidad suele mejorar el SEO al mismo tiempo. Si no sabes con certeza cuál es tu exposición legal, conviene revisar qué exige realmente la ley de accesibilidad que corrijas primero junto con tu limpieza de Core Web Vitals.
Novedades de Core Web Vitals para editores y sitios de noticias
Si tu sitio funciona como medio de noticias, las novedades de Core Web Vitals tienen una complicación añadida: los problemas de velocidad y estabilidad se suman a los problemas de indexación. Una plantilla lenta no solo arriesga una mala puntuación de CLS: puede ralentizar la rapidez con la que se rastrean los artículos nuevos.
Si buscas tanto una indexación rápida como una buena puntuación de Core Web Vitals, hay algunas correcciones relacionadas que suelen ir de la mano:
- Limpia los errores del sitemap de Google News para que los artículos nuevos aparezcan rápido.
- En WordPress, confirma que tu configuración de Yoast News SEO no añade scripts que bloqueen el renderizado a las plantillas de artículos.
- Revisa la guía más amplia para indexar artículos de noticias y posicionarlos rápido, ya que una plantilla de artículo pesada suele fallar a la vez en INP y en las comprobaciones de velocidad de rastreo.
Y si tu negocio también aparece en la búsqueda local, conviene seguir los cambios recientes en Google Business Profile junto con tu trabajo en Core Web Vitals: ambos alimentan la misma imagen global de experiencia de página que Google se está formando de tu marca.
Por qué esto se relaciona con el comportamiento de los clics
Recuerda el mecanismo de NavBoost mencionado antes: Google registra los clics que vuelven de inmediato a la página de resultados como una señal negativa. Una página lenta o inestable produce más de ellos. Mejorar tus Core Web Vitals, en la práctica, protege tu rendimiento de clics. Si quieres conocer las cuentas que hay detrás de lo que se considera un buen resultado, merece la pena leer rápidamente la fórmula del porcentaje de clics (CTR) y sus valores de referencia: una página rápida y estable es una de las formas más baratas de proteger esa cifra.
Priorizar las correcciones: un marco sencillo
En lugar de corregir cada URL marcada en el orden en que Search Console las enumera, sigue esta secuencia:
- Elige primero las plantillas vinculadas a ingresos o a clientes potenciales: páginas de producto, de servicios y de aterrizaje.
- Comprueba los datos de campo antes que los de laboratorio. El informe de Search Console y los datos de campo de CrUX reflejan visitas reales; las herramientas de laboratorio como Lighthouse solo simulan una ejecución.
- Identifica la métrica concreta que falla. LCP, INP y CLS necesitan cada una una solución distinta, y un ticket genérico de "hazlo más rápido" hace perder tiempo a los desarrolladores.
- Prueba una URL representativa del grupo antes de cambiar toda la plantilla.
- Valida en una herramienta de laboratorio antes de publicar y, después, valida la corrección en Search Console.
- Monitoriza durante unas semanas. Los datos de campo tardan en reflejar una corrección publicada.
Preguntas frecuentes
¿Cuáles son las últimas novedades de Core Web Vitals en 2026?
El cambio reciente más importante sigue siendo la sustitución, el 12 de marzo de 2024, de First Input Delay por Interaction to Next Paint. Desde entonces, la mayoría de las "novedades" han sido análisis de la documentación filtrada de Google que confirma cómo interactúan el comportamiento de los clics y Core Web Vitals, más que una nueva métrica oficial.
¿Ha eliminado Google Core Web Vitals del posicionamiento?
No. Google ha dicho repetidamente que Core Web Vitals son una señal más entre muchas y que la relevancia y la calidad del contenido siguen pesando más. Unos malos Core Web Vitals no impedirán que una página se posicione, pero pueden hacer que una página igualada en lo demás pierda frente a un competidor más rápido.
¿Cuánto tarda en verse una corrección en Search Console?
Los datos de campo necesitan una muestra nueva de visitas reales después de publicar una corrección, lo que normalmente tarda entre un par de semanas y un mes antes de que el estado se actualice en el informe de Core Web Vitals.
¿Es PageSpeed Insights lo mismo que el informe de Core Web Vitals de Search Console?
No. PageSpeed Insights prueba una URL cada vez y combina datos de laboratorio y de campo. El informe de Search Console agrupa muchas URL por plantilla usando únicamente datos de campo de visitas reales, lo que es mejor para priorizar correcciones en todo un sitio.
¿INP sustituye a Core Web Vitals por completo o solo a una métrica?
INP solo sustituyó a FID. LCP y CLS no han cambiado. Los tres Core Web Vitals actuales son LCP, INP y CLS.
Qué hacer ahora mismo
Abre hoy tu informe de Core Web Vitals en Search Console, ordénalo por estado y elige el grupo de URL "Deficiente" vinculado a tu plantilla con más tráfico. Pasa una página de ese grupo por la herramienta gratuita Website Speed Test para confirmar cuál de las tres métricas, LCP, INP o CLS, está fallando realmente antes de dar instrucciones a un desarrollador. Si prefieres ver qué sacaría a la luz una revisión técnica completa y de Core Web Vitals de tu sitio, habla con el equipo y recibe un informe de muestra elaborado con tus propias URL. Esas son las novedades de Core Web Vitals que de verdad mueven el posicionamiento: no una métrica nueva que perseguir, sino una plantilla corregida.
Recursos / Referencias
Fuentes
Sobre el autor
SearchBlueprint investigó, escribió y puntuó este artículo con el mismo flujo de contenido que nuestros clientes usan en sus propios sitios. La puntuación que aparece junto al autor es la que nuestro motor de contenido dio a esta página antes de publicarla. Nada de esto se revisa a mano, y ese es el punto: es el resultado del producto, publicado donde cualquiera puede comprobarlo.