Cómo auditar los Core Web Vitals en 2026 (y qué ha cambiado desde que INP reemplazó a FID)

En resumen: Las Core Web Vitals en 2026 son LCP, INP y CLS. FID se retiró e INP lo sustituyó el 12 de marzo de 2024. Su peso en el ranking es menor de lo que muchos SEOs afirman (la propia documentación de Google indica que la relevancia supera a la experiencia de página), pero el impacto en UX es real y la auditoría sigue siendo rentable. Esta es la guía de auditoría que entrego a los clientes: tres umbrales métricos, herramientas en dos pases (laboratorio y campo), una lista de correcciones ordenada por retorno y una cadencia trimestral que no quema al equipo de ingeniería en tareas equivocadas.

Realizo auditorías trimestrales para una cartera de sitios de mercado medio en mindnow y seojuice.io. Siempre surge la misma pregunta: ¿hay que dedicar otro sprint a las Core Web Vitals? La respuesta sincera suele ser no. El protocolo cambió en 2024, el peso de ranking es pequeño y la mayoría de lo que se publica sobre CWV exagera el potencial de tráfico orgánico. La auditoría sigue importando, porque las páginas lentas siguen perdiendo conversión y el INP es una métrica realmente distinta de FID. Este artículo es el playbook de la auditoría. No es un tutorial técnico de cómo optimizar INP; el equipo de web.dev lo explica mejor que yo. Es la capa de interpretación que va encima.

Qué cambió en Core Web Vitals entre 2024 y 2026

El cambio principal: First Input Delay (FID) se desaprobó e Interaction to Next Paint (INP) se convirtió en Core Web Vital oficial el 12 de marzo de 2024. El equipo de Chrome lo anunció directamente:

"INP will officially become a Core Web Vital and replace FID on March 12 of this year." Jeremy Wagner and Rick Viscomi, web.dev blog, March 2024

Si tu plantilla de auditoría todavía extrae FID, estás usando una métrica obsoleta. Search Console eliminó FID ese mismo día. PageSpeed Insights ahora muestra INP. La librería JavaScript Web Vitals v4 declaró obsoleta la medición de FID. Las herramientas de laboratorio que aún informan FID sirven para triaje, pero no para decisiones de ranking.

¿Por qué el cambio? FID medía solo la primera interacción de la página y únicamente la parte de input-delay de esa interacción. Un sitio podía tener un primer clic rápido y seguir congelándose en cada toque posterior. Además, la métrica era manipulable: no diferir nada en el landing y cargarlo todo en la segunda interacción. INP cubre ambos huecos muestreando todas las interacciones y midiendo el retardo completo hasta el siguiente paint:

"INP improves on FID by observing all interactions on a page, beginning from the input delay, to the time it takes to run event handlers, and finally up until the browser has painted the next frame." Jeremy Wagner and Barry Pollard, web.dev, Interaction to Next Paint

Efecto práctico en las auditorías: la mayoría de los sitios que estaban en verde con FID ahora aparecen en amarillo o rojo con INP. El cambio es mecánico, no significa que tu sitio haya empeorado. Ajusta la línea base antes de informar a los stakeholders de una aparente regresión.

Dos cambios menores también llegaron entre 2024 y 2026. CrUX, la fuente de datos de campo detrás del informe de CWV en Search Console, aumentó la profundidad de muestreo, por lo que los umbrales del percentil 75 se calculan sobre más sesiones. LCP incorporó un diagnóstico por sub-partes (TTFB, retraso de carga de recursos y retraso de renderizado del elemento) en PageSpeed Insights, la mejora de diagnóstico más útil en años.

Las tres métricas actuales y sus umbrales de auditoría

Tres métricas, una sola tabla de umbrales, aplicados en el percentil 75 del tráfico de usuarios reales para móvil y desktop por separado. La página canónica de web.dev lo deja claro:

"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." Philip Walton, web.dev, Web Vitals

El corte del percentil 75 es lo que más se pasa por alto. No necesitas que cada sesión quede por debajo del umbral; basta con que lo hagan tres cuartas partes. El extremo más lento de dispositivos, redes y páginas puede quedar en la banda amarilla y la URL seguirá obteniendo la etiqueta Good en CrUX.

Paso de auditoría para cada métrica. LCP: revisa las sub-partes de LCP en PageSpeed Insights. Si el TTFB supera los 800 ms, la solución está en el servidor o el CDN, no en el front-end. Si domina el retraso de renderizado del elemento, la corrección es precargar la imagen o aplicar CSS crítico. INP: abre la página en un Android de gama media, interactúa con cada elemento clicable y observa en la pestaña Performance las tareas largas superiores a 50 ms. La interacción más lenta es la que puntúa. CLS: desplázate por la página con una conexión lenta. Si el layout se desplaza durante el intercambio de fuentes o la carga de la imagen above-the-fold, la solución es reservar espacio (CSS aspect-ratio) o usar font-display: swap con una fuente de sistema de métricas coincidentes.

Un antipatrón de auditoría que debes abandonar: no optimices la puntuación Performance de Lighthouse como sustituto de las CWV. El score Performance es un compuesto ponderado de métricas de laboratorio que incluye Speed Index y Total Blocking Time, ninguna de las cuales es una Core Web Vital. Un sitio puede marcar 95 en Lighthouse Performance y aun así fallar CWV en datos de campo porque Lighthouse simula un único perfil de dispositivo y CWV mide a cada visitante real.

Cómo usa Google realmente las CWV en el ranking

Lee la documentación de experiencia de página de Google. La línea de resumen es tajante:

"Google Search always seeks to show the most relevant content, even if the page experience is sub-par." Google Search Central, Page Experience documentation

Esa frase está escondida en el FAQ bajo “¿Qué tan importante es la experiencia de página para el éxito en ranking?”. Es lo más claro que Google ha publicado sobre el peso de las CWV, y la mayoría del contenido SEO lo pasa por alto. La relevancia y la autoridad dominan. La experiencia de página es solo una de muchas señales que inclinan la balanza cuando la relevancia anda empatada.

El mismo documento matiza su propia matización. Google confirma que "Core Web Vitals are used by our ranking systems", y acto seguido aclara la estructura: "There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience." (Ambas citas del mismo documento de experiencia de página.)

Cómo leer las tres frases juntas: las CWV están en el sistema, pero no pesan mucho. No hay una sola puntuación de experiencia de página que cambie tu ranking; es un clúster de señales que ayuda a Google a desempatar cuando el resto está parejo. El planteamiento honesto para los stakeholders: mejorar las CWV de una página con contenido flojo y sin backlinks no la rescatará. Mejorar las CWV de una página con contenido sólido y buenos backlinks que está en posición 4 o 5 sí puede contribuir a que suba a la 2 o 3 en unos meses. Las matemáticas pasan primero por la relevancia.

Para una visión más amplia de las señales de ranking, nuestro artículo sobre confianza en las señales de ranking y auditoría recorre el resto del sistema. Las CWV son solo un panel de un tablero más grande. Trátalas así.

Qué miran realmente los buscadores con IA

Un protocolo completamente distinto. Google AI Mode, ChatGPT browse, Perplexity y la herramienta web de Claude son sistemas de recuperación y resumen. Obtienen tu página, la analizan en busca de contenido relevante y la citan o parafrasean al usuario. La velocidad de página en el sentido de las CWV no aparece entre sus criterios de selección; la recuperación es del lado servidor y su presupuesto de fetch es más laxo que el de un usuario real.

Lo que sí les importa: la capacidad de respuesta del servidor (un TTFB de 30 s provoca timeout del crawler), HTTPS, contenido que se renderice sin JavaScript (o que el fetcher pueda ejecutar), datos estructurados que puedan parsear y HTML semántico claro. Coinciden con las CWV solo en el borde de TTFB; el resto es otra auditoría. Optimizar INP para ChatGPT browse es tiempo perdido: el agente no interactúa con tu página.

Implicación práctica para la auditoría de 2026. Mantén un único objetivo de TTFB (menos de 800 ms) que sirva a ambas auditorías. Separa el trabajo de INP y CLS del de búsqueda con IA; viven en listas de prioridades distintas. Si tu mix de tráfico se inclina hacia sesiones referidas por IA, la hora de ingeniería rinde más en la renderización del contenido y en los datos estructurados que en recortar 50 ms a una interacción.

Herramientas para medir Core Web Vitals en 2026

El conjunto de herramientas se ha consolidado desde 2022. Seis herramientas cubren el flujo de trabajo laboratorio-más-campo que necesitan la mayoría de los equipos.

Flujo en dos pases. Empieza con PageSpeed Insights para una sola URL y obtén laboratorio y campo uno junto al otro. El dato de laboratorio muestra lo que es técnicamente alcanzable en un dispositivo limpio; el de campo, lo que experimentan los usuarios reales. Cuando divergen, el dato de campo es el que cuenta para el ranking y la brecha es el diagnóstico. Laboratorio en verde más campo en rojo significa que tu base de usuarios usa hardware o redes más lentos que tus máquinas de desarrollo.

Para informes de cliente repetibles y seguimiento de tendencias, el SEOJuice Lighthouse Score Checker ejecuta un escaneo real a nivel de página y te entrega una URL compartible más datos históricos; es lo que usamos internamente para seguir el progreso de los clientes sin relanzar Lighthouse en cada ciclo de auditoría. La cuestión más amplia de interpretación del score de Lighthouse (qué se considera una puntuación aprobada, cómo se componen las categorías) se cubre en nuestro desglose del score SEO de Lighthouse.

Si quieres ver cómo correlacionan las CWV con el tráfico orgánico en una población real de páginas, nuestro calculador de impacto CWV muestra las correlaciones agregadas de más de 164 000 páginas auditadas. El resultado principal coincide con el enfoque de Google: las correlaciones son reales pero moderadas y varían por métrica. CLS es la que menos correlaciona; LCP e INP son más fuertes pero siguen por debajo de lo que promete gran parte del marketing de CWV.

Correcciones comunes ordenadas por retorno

Las horas de ingeniería son finitas. Ordena las correcciones por el tamaño del impacto en tu peor métrica, no por lo fácil que sea implementarlas. A continuación, la lista de prioridades que utilizo tras siete años de auditorías CWV.

Nivel 1, tiempo de respuesta del servidor. Si el TTFB supera los 800 ms, cualquier corrección front-end se mide contra una línea de salida retrasada. Pon un CDN delante de tu origen. Cachea la respuesta HTML cuando sea posible. Saca las consultas a base de datos de la ruta crítica de renderizado. Una mejora de 400 ms en TTFB suele mover LCP en 600 ms porque las cargas de recursos posteriores se adelantan en bloque.

Nivel 1, estrategia de imágenes. El elemento LCP suele ser una imagen. Precárgala con una pista de alta prioridad. Sirve tamaños responsivos vía srcset. Usa AVIF o WebP con fallback JPEG. Carga diferida para todas las demás imágenes con el atributo nativo loading="lazy". No hagas lazy-load de la imagen LCP; es el autogol más común en las auditorías CWV.

Nivel 2, higiene de JavaScript. Difere los scripts no críticos. Divide tus bundles. Audita las etiquetas de terceros; la mayoría de los sitios tienen de 4 a 6 scripts cargados por el tag manager que hace años no justifican su tiempo de main thread. Las regresiones de INP casi siempre se remontan a un script que programa una tarea larga durante la interacción. Separa en código los componentes interactivos pesados, especialmente cualquier búsqueda, filtro o carrusel.

Nivel 2, carga de fuentes. Usa font-display: swap con una fuente de sistema de métricas equivalentes para que el swap no provoque desplazamiento de layout. Precarga el archivo de la fuente principal. Si cargas tres web fonts, deja dos.

Nivel 3, items de limpieza. Define width y height explícitos en cada imagen e embed. Reserva espacio para los anuncios con min-height. Mueve los componentes propensos a CLS (notificaciones, banners, cookies) por debajo del fold o haz que se rendericen con translate para no afectar al layout.

Qué no hacer. No persigas un Lighthouse Performance de 100. No bloquees un release por una regresión de CLS de 0,01. No permitas que un stakeholder de CWV pida una tercera auditoría antes de que se hayan desplegado las correcciones de la segunda. La métrica es ruidosa y el informe lleva retardo.

Lo que las AI Overviews interpretan mal sobre las CWV

Se repiten tres patrones en las respuestas de AI Overview cuando preguntas “core web vitals 2026” o similar.

El primero es el fantasma de FID. Las AI Overviews suelen seguir listando FID como Core Web Vital. Los datos de entrenamiento son anteriores a marzo de 2024 y el anuncio de deprecación no pesa mucho en el índice. Verifica con web.dev o Google Search Central, no con el resumen de IA.

El segundo es la inflación del peso de ranking. Muchas IA resumen el lenguaje matizado de Google a “Core Web Vitals son un factor clave de ranking”. La frase “factor clave” aparece en posts de marketing que el modelo ha memorizado; la documentación real de Google dice que la relevancia prima sobre la experiencia de página. La compresión aplana el matiz.

El tercero es el bucle de auto-referencia de la búsqueda con IA. Las AI Overviews recomendarán optimizar para motores de búsqueda IA mediante CWV. Como se explicó antes, estos motores no miden tu INP. La velocidad de página en sentido CWV es irrelevante para la recuperación. El conjunto de entrenamiento confunde “sitio rápido equivale a buen SEO” sin distinguir la superficie de búsqueda.

Efecto neto para los operadores. Toma las respuestas de AI Overview sobre CWV como punto de partida, no como fuente de verdad. Verifica con la documentación de Google y con web.dev antes de actuar.

La cadencia de auditoría trimestral

Cuatro checkpoints al año, noventa minutos cada uno. Es la cadencia que la mayoría de los sitios de mercado medio necesita. Más frecuencia es sobrecarga; menos y las regresiones llegan antes de que la siguiente auditoría las detecte.

Extrae el informe de Core Web Vitals en Search Console. Anota los grupos de URL que cambiaron de estado desde el trimestre anterior. Para cada grupo que cambió, ejecuta PageSpeed Insights en una URL representativa y captura los diagnósticos por sub-partes.

Ejecuta un escaneo de laboratorio en tus diez páginas de aterrizaje con más tráfico. Compáralo con el trimestre anterior. Si una página empeoró más de 200 ms en LCP o 50 ms en INP, márcala para revisión de ingeniería.

Muestra los datos de campo de tu propio RUM (librería Web Vitals v4). Los datos CrUX que usa Google tienen 28 días de retardo; tus datos son en tiempo real. Compara la forma de la distribución, no solo los promedios.

Prioriza la lista de correcciones según los niveles anteriores. Despliega un item de nivel 1 por trimestre, incluso cuando sea incómodo. La limpieza de nivel 3 viaja con los ciclos de lanzamiento normales. Para los sitios que ya ejecutan una auditoría SEO trimestral, nuestro producto de auditoría automatiza el escaneo de laboratorio de este checkpoint, de modo que el tiempo manual se dedica a la interpretación.

Lo que esta auditoría NO resuelve

Las Core Web Vitals son una señal de UX y de ranking ligero. No son una señal de calidad de contenido, backlinks ni confianza de marca. Si tu página está en la segunda página de Google para una consulta competitiva, arreglar tu CLS no te llevará a la primera. El trabajo de relevancia y autoridad tiene que hacerse primero.

Las CWV tampoco resuelven la conversión como algunos esperan. Un LCP 200 ms más rápido se correlaciona con mejor conversión, pero la elasticidad varía enormemente según el tipo de sitio. Los flujos de checkout en ecommerce reaccionan con fuerza; las páginas de contenido largo, mucho menos. Mide tu propio uplift antes de justificar la inversión en ingeniería.

Y las CWV no resuelven la auditoría de búsqueda con IA: protocolo distinto, fetcher distinto, prioridades distintas. Si tu mix de tráfico se mueve hacia sesiones referidas por IA, la auditoría de experiencia de página no es la herramienta adecuada.

Preguntas frecuentes

¿FID sigue siendo una Core Web Vital? No. FID se desaprobó y se eliminó del programa Core Web Vitals el 12 de marzo de 2024. Interaction to Next Paint (INP) ocupó su lugar. Search Console quitó FID del informe de CWV ese mismo día. Si tu plantilla de auditoría aún extrae FID, actualízala.

¿Cuál es el umbral de INP? 200 milisegundos o menos es Bueno. Entre 200 y 500 ms es Necesita mejora. Más de 500 ms es Pobre. El umbral se aplica en el percentil 75 de las interacciones reales de usuarios para móvil y desktop por separado.

¿Cuánto afectan las Core Web Vitals al ranking en Google? Menos de lo que afirma la mayoría del contenido SEO. La documentación de experiencia de página de Google dice directamente que la Búsqueda “siempre intenta mostrar el contenido más relevante, incluso si la experiencia de página es subóptima”. Las CWV son una señal real, pero solo una entre muchas, y la relevancia y la autoridad dominan. Trátalas como un desempate entre páginas aproximadamente equivalentes, no como una palanca principal de ranking.

¿Los motores de búsqueda con IA como ChatGPT o Google AI Mode usan las Core Web Vitals? No, al menos no de la misma forma. Sus crawlers recuperan las páginas del lado servidor y extraen contenido para resumirlo. La velocidad de página en el sentido de las CWV es irrelevante para la recuperación. La disponibilidad del servidor (TTFB), la renderización del contenido sin JS y los datos estructurados son las prioridades para la búsqueda con IA; INP y CLS no lo son.

¿Cuál es el error más común en una auditoría de Core Web Vitals? Optimizar la puntuación Performance de Lighthouse como si fuera un proxy de las CWV. Lighthouse Performance es un compuesto de laboratorio que incluye métricas fuera de CWV (Speed Index, Total Blocking Time). Una página puede marcar 95 en Lighthouse y aun así suspender CWV en datos de campo porque Lighthouse simula un único perfil de dispositivo mientras que CWV mide a cada visitante real.

¿Con qué frecuencia debo auditar las Core Web Vitals? Trimestral es suficiente para la mayoría de los sitios de mercado medio. Más frecuencia es sobrecarga: los datos CrUX tienen 28 días de retardo y tu ciclo de corrección raramente es más rápido. Usa monitorización RUM continua (Web Vitals v4) para alertas en tiempo real entre auditorías.