La historia de Core Web Vitals

• Core Web Vitals, que miden el rendimiento de los sitios web, surgieron a partir de 2014 como parte de un esfuerzo de varios equipos de Google para superar las limitaciones del proyecto AMP y definir métricas de rendimiento de estándar abierto aplicables a cualquier sitio web
• En mayo de 2020 se anunciaron oficialmente tres métricas clave (LCP para velocidad de carga, FID para capacidad de respuesta a la interacción y CLS para estabilidad visual), diseñadas como métricas medibles en campo que reflejan la experiencia real de los usuarios
• En 2021 se introdujeron como factor de posicionamiento en búsquedas mediante la actualización Page Experience de Google Search, y se eliminó el requisito exclusivo de AMP en Top Stories, creando un entorno competitivo de web abierta
• Gracias a optimizaciones en el navegador Chrome, mejoras en CMS importantes como WordPress y colaboración con frameworks de JavaScript, para 2023 se habían ahorrado en conjunto más de 10,000 años de tiempo de espera de usuarios, y en 2024 se alcanzaron 30,000 años ahorrados
• En 2024 siguieron evolucionando con cambios como reemplazar FID por INP e introducir la Soft Navigation API para SPA, contribuyendo a construir un ecosistema web rápido, estable y centrado en el usuario

---

Contexto y motivación: de AMP a métricas para la web abierta

• Google enfatizó durante años la velocidad y la experiencia de usuario como principios clave de la web, pero muchos sitios seguían ofreciendo experiencias lentas
• En 2010, Google Search empezó a usar la velocidad del sitio como señal de ranking, uno de los primeros intentos de incorporar el rendimiento al SEO
• Hacia 2015 se introdujo el proyecto AMP (Accelerated Mobile Pages) para ofrecer páginas optimizadas para cargas rápidas, pero surgieron problemas de apertura y flexibilidad al tratarse de un entorno cerrado servido desde la caché de Google
• En 2018, con el Speed Update, la velocidad de página pasó a aplicarse al ranking de búsquedas móviles, y Google Ads también introdujo una puntuación de velocidad de landing pages móviles, subrayando que una experiencia más rápida genera mejores tasas de conversión
• Para alejarse del enfoque exclusivo de AMP, los equipos de Chrome y Search colaboraron para empezar a definir métricas abiertas de rendimiento web aplicables a cualquier página sin necesidad de frameworks especiales
  • Analizaron millones de páginas para definir un estándar público para páginas web rápidas y amigables para el usuario
  • Se propusieron métricas medibles en campo que reflejaran la experiencia real de los usuarios
  • Buscaron métricas correlacionadas con resultados como la participación del usuario

Definición de Core Web Vitals: los tres pilares de la experiencia de usuario

• En mayo de 2020, Google anunció oficialmente la iniciativa Web Vitals e introdujo Core Web Vitals, centrados en “aspectos esenciales de la experiencia de usuario que aplican a todas las páginas web”

• Los Core Web Vitals iniciales estaban compuestos por tres métricas clave

  • Largest Contentful Paint (LCP): una métrica de velocidad de carga que mide el momento en que se renderiza el contenido principal; va más allá de First Contentful Paint o onload y se enfoca en cuándo el usuario ve contenido realmente significativo
  • First Input Delay (FID): una métrica de capacidad de respuesta a la interacción que mide la demora entre la primera interacción del usuario y la respuesta del navegador, capturando si la página responde de inmediato o si se retrasa por scripts pesados
  • Cumulative Layout Shift (CLS): una métrica de estabilidad visual que mide cuánto se desplaza el layout de la página durante la carga; suma los cambios de diseño inesperados, y un CLS bajo implica una experiencia estable y agradable

• La selección de métricas se basó en una amplia investigación y experimentación

  • Amar Sagoo, Annie Sullivan y Vivek Sekhar, entre otros, encontraron correlaciones entre métricas objetivas de rendimiento y la percepción del usuario mediante investigación de interacción humano-computadora
  • Idealmente, el tiempo de carga debía estar dentro de 2 a 3 segundos, la respuesta a la entrada dentro de 100 ms y los cambios de layout debían minimizarse
  • A partir del análisis de datos de usuarios reales, se establecieron umbrales prácticos: LCP menor a 2.5 segundos, FID menor a 100 ms y CLS menor a 0.1 (en el percentil 75)
  • Las páginas que cumplen estos umbrales tienen una probabilidad 24% menor de abandono por parte de los usuarios

• Google también trabajó para que estas métricas fueran estandarizadas y abiertas

  • Publicó borradores de especificaciones web a través del WICG y grupos de estándares de rendimiento web
  • Las implementó en Chrome y otros navegadores para que pudieran medirse mediante la API PerformanceObserver
  • En mayo de 2020 lanzó la biblioteca JavaScript open source web-vitals, que los desarrolladores podían insertar en sus sitios para medir LCP, FID y CLS de usuarios reales
  • Addy Osmani desarrolló la extensión Core Web Vitals que muestra estas métricas en tiempo real
  • Todo esto reflejó un esfuerzo amplio por volverlas accesibles y útiles para todo el ecosistema

Page Experience: Core Web Vitals en el ranking de Google Search

• El equipo de Google Search adoptó rápidamente Core Web Vitals como parte de la actualización Page Experience

• El 28 de mayo de 2020, Google Search Central anunció que estas métricas pasarían a formar parte del algoritmo de ranking

  • Cuando dos páginas tienen una relevancia de contenido similar, la página que ofrece una mejor experiencia de usuario puede posicionarse más arriba
  • La señal Page Experience combina Core Web Vitals con señales de UX ya existentes, como compatibilidad móvil, seguridad HTTPS y ausencia de intersticiales intrusivos
  • El gran contenido sigue siendo lo más importante, y un sitio rápido no superará a otro más relevante solo por velocidad
  • En casos de empate o diferencias mínimas, unos buenos Web Vitals pueden ser decisivos

• El anuncio más llamativo fue la eliminación del requisito de AMP en el carrusel Top Stories

  • Antes, Google News/Top Stories en móvil exigía AMP, pero tras la actualización Page Experience las páginas que no eran AMP también podían aparecer si cumplían con Core Web Vitals y otros criterios
  • “AMP ya no es obligatorio para Top Stories en móvil, y queda abierto a cualquier página con buena experiencia de página”
  • Esto mostró la confianza de Google en fomentar mejoras en la web abierta sin canalizarlas obligatoriamente hacia el framework AMP

• Google dio al ecosistema suficiente aviso previo

  • Reconociendo que 2020 fue un año difícil por la pandemia de COVID-19, anunció que el cambio de ranking no se aplicaría hasta 2021 y prometió al menos seis meses de anticipación
  • En una actualización de noviembre de 2020 indicó que el cambio de ranking de Page Experience comenzaría en mayo de 2021
  • Finalmente, la actualización Page Experience empezó a desplegarse a mediados de junio de 2021 y se aplicó por completo hacia finales de agosto (en búsquedas móviles)
  • Una actualización similar para búsquedas de escritorio se llevó a cabo entre febrero y marzo de 2022

• Una vez aplicada la actualización, el algoritmo de ranking de Google empezó a usar Core Web Vitals como una de cientos de señales

  • Las páginas que cumplen el umbral de “bueno” en las tres métricas de CWV se consideran páginas con buena experiencia de página
  • Google creó un reporte de Page Experience en Google Search Console para que los propietarios de sitios pudieran verificar, con datos del Chrome UX Report, qué proporción de sus páginas superaba los umbrales
  • Esto dio a webmasters y especialistas en SEO retroalimentación directa sobre cómo se desempeñaban sus sitios desde la perspectiva de las señales de experiencia de página

• Google consideró mostrar una insignia para las páginas con buena experiencia de página en los resultados de búsqueda, pero no se añadió un ícono permanente

  • La recompensa llegó principalmente en forma de mejor ranking más que como una etiqueta explícita
  • Durante un tiempo, Google mostró un indicador temporal de “Page Experience” en Search Console y en experimentos dentro de los resultados de búsqueda
  • La idea central: Google está incentivando públicamente el rendimiento y la UX, y lograr buenos Core Web Vitals no solo satisface a los usuarios, sino que también puede mejorar la visibilidad de la página en búsqueda

Herramientas y datos: Chrome UX Report y medición del rendimiento

• Google realizó una gran inversión en herramientas y datos para Web Vitals

• Chrome UX Report (CrUX) fue el núcleo de este esfuerzo

  • Un conjunto de datos públicos de métricas de experiencia real de usuario que existe desde 2017, y que recopila datos de rendimiento anonimizados de millones de sitios a partir de millones de usuarios de Chrome
  • Con el lanzamiento de Core Web Vitals, CrUX comenzó de inmediato a reportar LCP, FID y CLS para todas las URLs de origen del conjunto de datos
  • Cualquiera puede consultar datos de rendimiento de campo
  • Tras ofrecer acceso mediante BigQuery, lanzó la CrUX API y CrUX Dashboard, facilitando que desarrolladores y especialistas SEO vieran cómo rendían sus sitios (o los de la competencia) en métricas CWV en condiciones reales
  • La introducción de CrUX History API permitió ofrecer datos de series temporales de estas métricas para seguir el progreso a lo largo de varios meses

• En cuanto a herramientas para desarrolladores, la integración avanzó rápido

  • Para finales de 2020, la mayoría de las herramientas de rendimiento de Google se habían actualizado para resaltar Core Web Vitals
  • Lighthouse (la herramienta open source de auditoría usada en Chrome DevTools y PageSpeed Insights) integró diagnósticos y puntuaciones relacionadas con CWV
    • Añadió auditorías como “Largest Contentful Paint fue de X segundos (objetivo: <2.5 segundos)” y ofrecía sugerencias de mejora
  • Chrome DevTools añadió un panel de Core Web Vitals y marcadores en la línea de tiempo para ver el elemento LCP o los cambios de diseño durante la carga de la página
  • PageSpeed Insights (PSI) fue rediseñado por completo para enfocarse en CWV
    • Mostrando de forma destacada, en la parte superior, los datos de campo de LCP, FID (más adelante INP) y CLS obtenidos de CrUX
  • Google Search Console ofreció un reporte dedicado de Core Web Vitals que agrupaba las páginas en categorías de “bueno”, “necesita mejoras” y “malo” para cada métrica, permitiendo a los propietarios de sitios identificar con precisión las áreas problemáticas
  • Trabajo en herramientas liderado por Elizabeth Sweeny, Paul Irish, Addy Osmani y otros

• La comunidad de desarrollo web también respondió con herramientas de terceros

  • Los proveedores de servicios de Real User Monitoring (RUM) integraron rápidamente Core Web Vitals
  • mPulse de Akamai, Browser agent de New Relic, Dynatrace, Datadog, SpeedCurve y otros ofrecieron soporte inmediato como métricas de primera clase para LCP, FID y CLS
  • Cloudflare también introdujo su servicio Browser Insights, capaz de recopilar Web Vitals insertando un script
  • La existencia de la librería JS web-vitals permitió que cualquier herramienta de analítica pudiera recopilar fácilmente estas métricas
  • Para 2021, Core Web Vitals ya era algo común en los dashboards de herramientas de monitoreo de rendimiento web
  • Esta amplia disponibilidad ayudó a expandir la conciencia sobre el tema y proporcionó a los desarrolladores datos con los que impulsar mejoras de rendimiento

• Los datos de Chrome User Experience Report también fueron esenciales para seguir el progreso de toda la web

  • Durante 2021 y 2022, la proporción de tráfico con CWV “buenos” aumentó de forma constante
  • Esto se reportó con frecuencia en el Web Almanac anual de HTTP Archive y en actualizaciones del propio blog de Google
  • Tener métricas medibles y visibles públicamente creó una especie de competencia virtuosa
  • Los propietarios de sitios y los proveedores de plataformas empezaron a presumir y a esforzarse por mejorar sus Core Web Vitals

Impacto y mejoras: hacer la web más rápida y estable

Optimización del navegador Chrome

• Una vez establecidos los Core Web Vitals, se desencadenó un gran esfuerzo multifacético en todo el ecosistema web para mejorar estas métricas

• El equipo de ingeniería de Google Chrome revisó de cerca el navegador para optimizar cómo Chrome carga y renderiza páginas web

  • Dada la enorme base de usuarios de Chrome, incluso pequeñas mejoras a nivel del navegador benefician a toda la web
  • Entre las principales optimizaciones lanzadas en Chrome entre 2020 y 2023 se incluyen las siguientes

• Priorización de contenido para LCP

  • Chrome fue modificado para priorizar la carga del contenido importante
  • Identifica las primeras imágenes del HTML (a menudo incluyendo la imagen LCP) y les asigna una prioridad de red más alta
  • Priorizar así las primeras 5 imágenes mejoró el LCP en algunas páginas de 3.1 segundos a 2.5 segundos
  • Se introdujeron nuevos estándares web como el atributo fetchpriority (mecanismo Priority Hints), que permite a los desarrolladores marcar imágenes o iframe con alta prioridad para LCP

• Back/Forward Cache (BFCache)

  • Históricamente, Chrome no aplicaba BFCache completo a las páginas debido a complejidades técnicas, pero en los últimos años habilitó BFCache para muchas páginas
  • Para 2023, logró un aumento notable en la tasa de aciertos de BFCache tanto en escritorio como en Android
  • Los usuarios que vuelven “atrás” a una página pueden verla de inmediato (LCP cero y retraso de entrada cero, porque la página no se descargó)
  • Grandes plataformas como Amazon se beneficiaron del BFCache de Chrome y, tras la mejora de Chrome (versión M112), reportaron un aumento de 22.7 puntos porcentuales en el uso del caché back/forward

• Prerendering (NoState Prefetch/Prerender2)

  • Chrome lanzó un nuevo prerenderer (Prerender2) que permite al navegador cargar y renderizar por completo una página en segundo plano, para luego cambiarla de inmediato cuando el usuario navega a ella
  • Al inicio se usó en Google Search (prerenderizado de resultados principales) y en la predicción de URLs escritas, permitiendo recortar drásticamente el LCP
  • Chrome reportó que el prerenderizado de búsquedas en la omnibox ofrecía una mejora mediana de 500~700 ms (aprox. 15~25%) en LCP en esas navegaciones
  • Chrome lo ha estado desplegando con cuidado (para evitar predicciones erróneas o problemas de privacidad)

• Optimización de red y scheduling

  • El equipo de Chrome identificó y resolvió varios pequeños retrasos en la capacidad de respuesta a la entrada
  • Introdujo la función de preconexión al presionar con el puntero (al iniciar un tap/clic, antes de soltar), recortando algunos milisegundos en el establecimiento de conexión para la navegación por enlaces
  • Esto ofreció un LCP en promedio unos 6~10 ms más rápido en navegaciones de origen cruzado
  • También mejoró la forma en que el hilo principal del navegador procesa tareas cuando hay varias pestañas abiertas, reduciendo la contención
  • Ajustando la programación de tareas y usando mecanismos como EcoQOS de Windows 11 en pestañas en segundo plano, Chrome logró mejorar el INP en alrededor de 5% y el LCP en alrededor de 2% en escenarios con mucha carga

• Mejoras en rendering y en el motor JavaScript

  • La renovación de la arquitectura RenderingNG de Chrome (completada alrededor de 2021) hizo el renderizado más eficiente
  • Mejoras en la prioridad de carga de imágenes (para que las imágenes LCP no quedaran bloqueadas detrás de otras tareas menos importantes) y una temporización más inteligente de la recolección de basura en V8 (ejecutándose durante tiempos ociosos) ayudaron a garantizar una experiencia más fluida
  • Los desarrolladores de Chrome descubrieron que la forma en que un navegador multiproceso accedía a las cookies causaba jank
    • Todas las llamadas a document.cookie tenían que recuperarse de forma síncrona desde otro proceso
    • Al introducir versionado de memoria compartida para las cookies, Chrome optimizó el acceso a cookies y eliminó muchos saltos de proceso redundantes
    • Esto redujo el retraso de entrada cuando un sitio saturaba cada interacción con lecturas de cookies

• Todas estas optimizaciones de Chrome marcaron una diferencia medible

  • Para finales de 2023, Google reportó que la carga promedio de páginas en Chrome es 166 ms más rápida que antes de que existieran los Core Web Vitals
  • El impacto en toda la web fue enorme: al sumar el tiempo ahorrado, el equipo de Chrome calculó que solo en 2023 las mejoras de velocidad les ahorraron a los usuarios más de 10,000 años de tiempo acumulado esperando a que cargaran las páginas, además de otros 1,200 años esperando a que las páginas respondieran a la interacción
  • También aumentó de forma importante la proporción de tráfico que cumple con el criterio de CWV “bueno”
  • Cuando se anunciaron por primera vez, cerca de 1/3 de las cargas de página eran buenas según los criterios de CWV, pero para 2023 aproximadamente el 68% de las visitas de páginas de escritorio y el 64% de las móviles en Chrome cumplían los tres umbrales de CWV

Mejoras en todo el ecosistema web

• Las mejoras no vinieron solo del lado de Google; la comunidad más amplia de desarrolladores web, frameworks y proveedores de plataformas también actuó para resolver los problemas de rendimiento identificados por Core Web Vitals

• Optimización de imágenes y lazy loading

  • Al reconocer que las imágenes suelen ser el contenido más grande y una causa común de LCP, los frameworks web y los CMS implementaron valores predeterminados más inteligentes
  • El loading="lazy" nativo de HTML para imágenes fuera de pantalla se estandarizó (con ayuda de Chrome y de contribuyentes a estándares web como Yoav Weiss y Addy Osmani) y fue adoptado por WordPress y otras plataformas, reduciendo drásticamente la carga innecesaria de imágenes
  • Después de que WordPress activó por defecto el lazy loading para imágenes en 2020, mejoró el comportamiento para no aplicar lazy loading a la imagen principal del banner inicial y así evitar retrasar el LCP
  • El nuevo atributo `` también fue aprovechado rápidamente por los frameworks para destacar la imagen principal y cargarla más rápido

• WordPress Performance Team

  • Como WordPress representa alrededor del 40% de todos los sitios web, su rendimiento tiene una influencia enorme
  • Al inicio, los sitios de WordPress se quedaban atrás en las puntuaciones de CWV, y un informe de 2021 mostró que su tasa de aprobación era menor que la de algunos otros ecosistemas, lo que encendió las alarmas
  • La comunidad respondió formando un Core Performance Team dedicado (incluyendo contribuidores de Google y otras empresas) para mejorar sistemáticamente la velocidad del núcleo de WordPress
  • En lanzamientos recientes, ese trabajo dio resultados
    • WordPress 6.3 (2023) incluyó numerosas optimizaciones para el renderizado de temas y la carga de recursos, y sus temas base cargaban 27% más rápido con block themes y 18% más rápido con classic themes frente a WordPress 6.2, medido con la métrica LCP
    • En la práctica, millones de sitios se volvieron más rápidos solo por actualizar WordPress
  • El equipo de WordPress optimizó el procesamiento de imágenes, añadió caché para algunas tareas especialmente costosas y puso al rendimiento al mismo nivel de prioridad que las nuevas funciones
  • Como resultado, la proporción de sitios WordPress con buenas puntuaciones de CWV aumentó de forma drástica (algunos datos muestran que la proporción de sitios WP que cumplían todos los CWV se multiplicó por más de 4 entre 2020 y 2022)

• Wix y los creadores de sitios web

  • Otras plataformas alojadas de creación de sitios como Wix, Squarespace y Duda también tomaron Core Web Vitals como impulso para mejorar el rendimiento
  • Wix realizó una importante renovación de infraestructura (caché, servidores más rápidos y mejor código del lado del cliente) y multiplicó varias veces la proporción de sitios Wix que lograban buenas puntuaciones de CWV
  • En un caso de estudio, Wix reportó haber elevado la proporción de sitios con CWV “buenos” de 4% a más de 33% en alrededor de un año
  • Esto demostró que un cambio cultural orientado al rendimiento dentro de la plataforma puede beneficiar a una enorme cantidad de usuarios
  • Otros creadores como Duda también suelen promocionar que la mayoría de los sitios de sus clientes alcanzan buenos CWV, porque esas plataformas integraron las mejores prácticas por defecto (imágenes responsivas, entrega por CDN, plantillas eficientes, etc.)
  • Esta presión competitiva hizo que, incluso si los propietarios individuales de sitios no eran expertos en rendimiento, la plataforma que usaban impulsara mejoras internamente

• Frameworks de JavaScript (Chrome Aurora)

  • El equipo de Chrome Aurora nació a mediados de 2020 como una fuerza de tarea especial dentro de Chrome para colaborar con frameworks populares de JavaScript
  • Integrantes de Aurora (Addy Osmani, Kara Erickson, Houssein Djirdeh y otros) trabajaron estrechamente con autores de frameworks como React/Next.js, Angular, Nuxt y Gatsby para identificar cuellos de botella comunes y ofrecer soluciones
  • Esa colaboración produjo funciones como las siguientes
    • El componente next/script de Next.js (carga scripts de terceros de forma más eficiente fuera del hilo principal)
    • La directiva integrada NgOptimizedImage de Angular (aplica lazy loading automático a imágenes y configura tamaños y prioridades adecuadas)
    • El módulo de optimización de Google Fonts para Nuxt
  • El impacto fue considerable: en 2022 mejoraron notablemente las puntuaciones medianas de Core Web Vitals en sitios construidos con estos frameworks
    • La tasa de aprobación de CWV en sitios de Next.js pasó de 20.4% a 27.3%
    • Angular mejoró de 7.6% a 13.2%
    • Nuxt mejoró de 15.8% a 20.2%
  • También abundan los casos individuales de éxito
    • El sitio de comercio electrónico Land's End mejoró su LCP en 40% en móvil (pruebas de laboratorio) tras adoptar la optimización de imágenes de Angular
    • CareerKarma redujo su LCP en 24% usando la carga mejorada de scripts de Next.js

• Métricas reales de negocio

  • En última instancia, unos mejores Core Web Vitals no sirven solo para satisfacer a Google, sino que se correlacionan con la satisfacción real de los usuarios y con resultados de negocio
  • Muchas empresas compartieron casos de estudio que vinculan las mejoras de CWV con el engagement de los usuarios
    • El sitio de noticias Economic Times mejoró su INP al optimizar el procesamiento de scripts y logró 42% más pageviews y 49% menos rebote
    • El sitio de reservas de viaje RedBus mejoró su INP y confirmó un aumento de 7% en la tasa de conversión
    • El marketplace en línea indio Meesho redujo su LCP de 6.9 segundos a 2.5 segundos y logró casi 17% menos rebote y 3% más conversión
  • Estos ejemplos refuerzan que el rendimiento no es solo una métrica técnica, sino algo que se traduce en que los usuarios se quedan más tiempo, leen más y compran más
  • Estos casos de éxito motivaron aún más a desarrolladores y equipos de producto a priorizar Web Vitals

Logros de mejora en todo el ecosistema

• El esfuerzo combinado de equipos de navegadores, autores de frameworks, desarrolladores de CMS e innumerables desarrolladores web individuales mejoró drásticamente el estado de la web
• Al establecer métricas claras y accionables, Core Web Vitals creó un objetivo común que todos podían seguir
• Lo importante es que esto se logró sin encerrar al ecosistema en tecnología propietaria, sino aprovechando estándares abiertos y datos abiertos
• Para 2023, alrededor del 40% de los sitios web (y una proporción mucho mayor entre sitios comerciales y bien mantenidos) ya superaban todos los umbrales de Core Web Vitals, mientras que a inicios de 2020 solo lo lograba una minoría
• Incluso los sitios que no los superaban por completo solían ser más rápidos y fluidos que antes
• Se expandió una cultura de conciencia sobre el rendimiento: cada vez más desarrolladores monitorean métricas de CWV (según encuestas, cerca del 51% de los desarrolladores rastrean y optimizan activamente Web Vitals)
• Google señaló que, a pesar de impulsar estas mejoras de velocidad, la satisfacción de los desarrolladores con la plataforma web se mantuvo alta
  • Esto indica que la guía fue alcanzable y no llevó a los desarrolladores a la desesperación
  • Ese equilibrio fue importante: si las metas de CWV hubieran sido imposibles o las herramientas insuficientes, los desarrolladores podrían haber reaccionado en contra; en cambio, la comunidad se unió para mejorar la web

La evolución de las métricas: INP, Soft Navigation y más

• Google reconoció desde el principio que Core Web Vitals evolucionaría con el tiempo
• El conjunto de tres métricas de 2020 no estaba pensado para ser estático ni completo
• Al principio no se abordaron otros aspectos de la experiencia de usuario, como el desplazamiento fluido o las tareas largas más adelante en la página
• El equipo de Chrome Web Platform siguió investigando nuevas métricas y mejoras a las métricas existentes

Interaction to Next Paint (INP)

• La brecha más clara en CWV originalmente era la interactividad más allá del primer clic
• FID solo medía el retraso de la primera entrada, lo cual es importante para la primera impresión, pero la página podía dejar de responder más adelante durante más interacciones del usuario
• Para resolver esto, Googlers como Annie Sullivan y Michal Mocny propusieron INP
  • Observa todas (o al menos muchas) las interacciones del usuario en la página e informa una especie de peor caso (o percentil 98) de latencia
  • Plantea la pregunta: "cuando el usuario interactúa con la página en cualquier momento, ¿cuánto tarda hasta que el siguiente frame se pinta como respuesta?", capturando la latencia del procesamiento de eventos y del renderizado
• INP se implementó en 2022 como una métrica de campo experimental y se recopiló en CrUX
• A inicios de 2023, Google descubrió que INP predecía mejor los problemas generales de capacidad de respuesta que FID
• Por ello, anunció que en marzo de 2024 INP reemplazaría a FID como Core Web Vital
  • Este cambio se comunicó a los desarrolladores con suficiente anticipación
  • Herramientas como Lighthouse y PageSpeed Insights empezaron a mostrar INP (y a marcarlo como "próximamente como CWV")
  • Web.dev ofreció orientación para mejorar INP, que a menudo terminaba en las mismas prácticas de rendimiento general: dividir tareas largas, usar web workers para cálculos pesados, etc.
• La transición de FID a INP subraya la filosofía del equipo de CWV de iterar las métricas para cubrir mejor lo que realmente importa
  • En este caso, garantizar una capacidad de respuesta consistente durante toda la visita del usuario, no solo durante la carga de la página

Fluidez y animaciones

• Otro aspecto que investigó el equipo de Chrome fue la fluidez visual, como la tasa de cuadros en las animaciones y el jank al desplazarse
• Aún no es una métrica oficial de CWV, pero hay trabajo en curso en este frente
• El equipo de Chrome proporcionó una métrica de Smoothness para herramientas de RUM (a veces reportada como "Jankiness" en CrUX) para cuantificar cosas como animaciones entrecortadas
• Se introdujeron heurísticas en el navegador para reducir el jank
  • Por ejemplo, se ajustó la forma en que los eventos táctiles se sincronizan con los frames de pantalla, duplicando la fluidez del desplazamiento del propio Chrome en Android (explicado en detalle en una publicación de Fast and Curious de agosto de 2023)
• En el futuro podríamos ver un Web Vital oficial de "smoothness", o que INP se amplíe para cubrir ciertas demoras en animaciones
• El punto clave es que Google reconoce estos aspectos y está experimentando activamente con ellos

Soft Navigation (SPA)

• Una limitación de la definición inicial de CWV era que se enfocaba en las cargas completas de página (las llamadas "hard navigations")
• Sin embargo, las Single-Page Applications (SPA) modernas suelen cargarse una vez y luego actualizar dinámicamente el contenido y las rutas sin recargar por completo
• Estas soft navigations (cuando se hace clic en un enlace pero el contenido cambia mediante JavaScript sin realizar una navegación completa del navegador) no quedaban capturadas por las mediciones de LCP o CLS en la implementación original
  • Desde la perspectiva del navegador, seguía siendo la misma página, así que una gran actualización del DOM no activaba un nuevo LCP
• Esto significaba que, en las SPA, los desarrolladores debían depender de mediciones personalizadas para evaluar las "transiciones de página" dentro de la app, y que los datos de campo de CrUX también quedaban ciegos ante esas navegaciones posteriores (solo se registraban los CWV de la carga inicial)
• Para corregir esto, Chrome propuso la Soft Navigation API
  • Todo el crédito de este trabajo es para Yoav Weiss
  • A mediados de 2023, Chrome comenzó experimentos para detectar navegaciones SPA mediante heurísticas
  • Para mediados de 2025, se lanzó un origin trial para la Soft Navigations API
• Como explicaron los ingenieros de Chrome Barry Pollard y Michal Mocny, una soft navigation es "cuando JavaScript intercepta una navegación (por ejemplo, mediante la History API o un router del framework) y actualiza el contenido de la página existente mientras actualiza la URL mediante history.pushState, sin una recarga completa"
• Con la nueva API, el navegador (y los desarrolladores) pueden marcar estos eventos y esencialmente tratarlos como si fueran una nueva vista de página
• De forma crucial, esto permite medir Core Web Vitals en SPA como si esos cambios de ruta soft fueran cargas de página
• Con la API, métricas como LCP pueden reiniciarse en una soft navigation y capturar el contenido más grande de la nueva vista (usando el concepto de entradas "interaction-to-next-paint" en la Performance Timeline)
• Del mismo modo, CLS puede dividirse por navegación e INP puede asociarse con la vista actual
• Esto es un gran avance para llevar CWV al mundo de las apps con routing del lado del cliente (que son muy comunes)
• A finales de 2025, la Soft Nav API sigue en pruebas y los desarrolladores pueden optar por participar y enviar comentarios
• Con el tiempo, se espera que Chrome soporte por completo las métricas de soft nav y que los datos de campo (CrUX) también las incorporen
• Esta evolución reconoce que el recorrido del usuario está compuesto por varias etapas y que no se trata solo de la carga de la página de aterrizaje; la plataforma web debe medir y optimizar toda la experiencia

Evolución futura

• Google ha indicado que seguirá mejorando las métricas cada año
• Podríamos ver ajustes como nuevos umbrales
  • Por ejemplo, si la web en general se vuelve universalmente más rápida, en el futuro el objetivo de un LCP "bueno" podría volverse más estricto que 2.5 segundos
  • O podría aparecer una métrica completamente nueva si surge una brecha clara
• Todas las incorporaciones pasan por un proceso público (definición en estándares de rendimiento web, discusión con otros fabricantes de navegadores, etc.), como ocurrió con INP
• Google planea integrar más señales de experiencia de página con el tiempo
  • Por ejemplo, experimentos de privacidad y seguridad como mostrar una insignia de "página rápida" en Chrome si un sitio usa buenas prácticas
• Sin embargo, en el contexto del ranking de Search, Google ha simplificado recientemente su mensaje
  • Para 2023, señaló que ya no habría un impulsor explícito de ranking de "experiencia de página" más allá de las señales individuales
  • Esencialmente, integró las consideraciones de experiencia de página de forma más sutil en el algoritmo central de ranking
  • Pero desde la perspectiva del propietario del sitio, no cambia nada
  • Las páginas rápidas, responsivas y estables siguen siendo fundamentales tanto para la satisfacción del usuario como para un buen SEO

Resumen

• La historia de Core Web Vitals es la historia de una plataforma web que responde a los desafíos
  • Comenzó con la idea de que la calidad de la experiencia de usuario debe poder medirse y recompensarse, y se convirtió en un movimiento amplio que tocó métricas, navegadores, ranking de búsqueda, herramientas, frameworks y plataformas de hosting
  • En pocos años, impulsó mejoras significativas en el rendimiento web en general
  • El recorrido continúa: con innovaciones futuras como la medición de soft navigation para SPA y el perfeccionamiento continuo de las métricas, el compromiso de la industria con una experiencia web rápida y agradable sigue siendo fuerte
• Core Web Vitals ha demostrado ser no solo un conjunto de métricas, sino un catalizador para una web más saludable, más rápida y centrada en el usuario
  • Es un legado construido con la colaboración de muchas personas, y uno que beneficiará a todos los que usan la web