Google ya mide los cambios de ruta de tu SPA: por qué tus Core Web Vitals pueden mejorar sin publicar una sola línea de código
El 13 de octubre de 2026 CrUX publicó variantes experimentales de LCP, INP y CLS que cuentan las navegaciones suaves de las SPAs, y el mismo día Cloudflare partió INP en tres sub-fases en su RUM. Las notas de CrUX suben el pase global del 55,9% al 59,5% sin que nadie toque su sitio: aquí van los números, quién cambia y el marco de lectura que usamos en Mintec.
El 13 de octubre de 2026, Chrome publicó en CrUX variantes experimentales de LCP, INP y CLS que cuentan las navegaciones suaves —los cambios de vista que una SPA hace sin recargar—, y Cloudflare hizo público el mismo día el desglose de LCP e INP por sub-fases en su Real User Monitoring. El efecto visible: el porcentaje de orígenes que pasan los tres Core Web Vitals sube de 55,9% a 59,5% sin que nadie haya cambiado su sitio, y en orígenes con más de 75% de tráfico suave el LCP "Bueno" en Android salta del 26% al 87%. Nuestra postura, después de leer el anuncio de web.dev y las notas de lanzamiento de CrUX: tu puntuación acaba de ponerse más amable, no más rápida, y quien lea ese delta como una mejora real va a saltarse el diagnóstico justo cuando se pone más preciso.
Lo que aterrizaron el mismo día — y por qué importan juntos
No son dos noticias de rendimiento: son dos caras de la misma moneda. Una cambia qué mide el campo; la otra cambia qué tan adentro puedes mirar cuando el número se mueve.
| Lanzamiento | Fecha | Qué cambia | Quién lo nota primero |
|---|---|---|---|
| CrUX con navegaciones suaves (web.dev) | 13 oct 2026 | Variantes experimentales de LCP, INP y CLS que mezclan navegaciones duras y suaves, disponibles en BigQuery, la API de CrUX y la History API desde la edición de octubre | Cualquier SPA con tráfico interno relevante: sus URLs de destino empiezan a reportar sus propias métricas en vez de heredarlas de la landing |
| Sub-fases de LCP e INP en RUM (Cloudflare) | 13 oct 2026 | El panel y la GraphQL API separan INP en inpInputDelay, inpProcessingDuration y inpPresentationDelay, y parten el tiempo de conexión en TCP y TLS | Cuya web ya midía INP y no sabía cuál de las tres fases le estaba matando |
El Soft Navigations API ya existía en el navegador desde Chrome 151 (julio 2026) — lo cubrimos entonces junto con interaction-contentful-paint para atribuir pinturas a rutas concretas en Interaction Contentful Paint: finally measuring what happens inside a SPA. Lo nuevo no es la API: es que los datos de campo de Google empiezan a contar esas navegaciones. Y eso sí cambia cómo se lee un dashboard.
Los números de la edición de septiembre
Las notas de la edición de septiembre de CrUX, publicadas el 13 de octubre con 18.376.044 orígenes, son la parte que duele en una reunión:
| Métrica | Sin navegaciones suaves | Con navegaciones suaves | Diferencia |
|---|---|---|---|
| LCP "Bueno" | 68,3% | 72,1% | +3,8 pp |
| CLS "Bueno" | 81,7% | 85,1% | +3,4 pp |
| INP "Bueno" | 85,4% | 87,4% | +2,0 pp |
| Los tres (pase global) | 55,9% | 59,5% | +3,6 pp |
Dos lecturas que sacamos de esto:
1. El INP mejora porque cambia la regla, no el rendimiento. Antes, una sesión de SPA entera se resumía en la peor interacción de toda la sesión; ahora cada vista suave elegible se mide por su vista. En la práctica eso duplica casi las tasas de paso de INP en Android para sitios que navegan sobre todo en cliente — pero las SPAs siguen por detrás de los sitios multipágina en INP, así que el trabajo real de JavaScript pesado durante los cambios de vista no desaparece.
2. El LCP se dispara porque la segunda visita es barata. En orígenes con 75–100% de tráfico suave, el LCP "Bueno" en Android pasa del 26% al 87%: las vistas siguientes reutilizan código y assets que la carga inicial ya pagó. Es una medición más representativa de lo que el usuario siente — y a la vez un recordatorio de que tu primera carga sigue siendo la cara del sitio.
Quién ve cambios, en una tabla:
| Perfil del sitio | Qué verás | Acción |
|---|---|---|
| Multipágina / SSG (nuestro caso en Astro) | Idéntico: ~70% de los orígenes de CrUX tiene menos de 5% de tráfico suave | Nada. El campo ya te medía bien |
| SPA con 5–50% de tráfico suave | Cambios pequeños, en una dirección | Compara contra tu histórico, no contra el mes anterior: la línea base cambió de definición |
| SPA con más de 50% de tráfico suave (7–11% de los orígenes) | Saltos grandes, todos hacia arriba | Captura tu línea base experimental ahora y vuelve a leerla en mayo de 2027 |
El mismo día, Cloudflare afinó el bisturí
Mientras Google aclaraba qué número verás, Cloudflare detalló dónde mirar cuando ese número está mal: su RUM ahora parte INP en sus tres fases y el LCP en sub-fases, en el panel y consultable por GraphQL. Es el mismo desglose que ya traían las tablas BEACON que analizamos en Cloudflare's BEACON dataset — solo que ahora está en tu propio dashboard, con tus propios usuarios.
El marco de triaje que aplicamos cuando un cliente llega con INP en rojo:
| Fase de INP | Campo en CrUX/RUM | Causa típica | Primer movimiento |
|---|---|---|---|
| Retardo de entrada | inpInputDelay | Un script ajeno a la interacción — tag manager, chat, A/B — con tareas largas antes de que corra tu handler | Corte de tareas largas y scheduler.yield(); revisión de terceros |
| Procesamiento | inpProcessingDuration | Tu handler hace todo el trabajo antes de pintar: filtrado sincrónico, analytics en el click, re-render amplio | Dividir el trabajo, posponer lo no crítico, memoizar el árbol que se redibuja |
| Presentación | inpPresentationDelay | El navegador tarda en pintar el siguiente frame: DOM enorme, reflow en bucle, sombras y estilos caros | Reducir el DOM vivo, eliminar lecturas de layout en bucle, content-visibility |
La regla que seguimos: la fase que domina decide el dueño de la corrección. Un inpProcessingDuration alto es tu código; un inpInputDelay alto casi siempre es de terceros; un inpPresentationDelay alto es de arquitectura. Mezclar los tres en un solo número —como hacía el INP agregado— es la razón por la que tantos equipos optimizan en la dirección equivocada.
Cómo lo leemos en Mintec
Nuestro sitio corre sobre Astro, multipágina con JavaScript casi cero: los datos experimentales nos devolverán prácticamente lo mismo que los estables, y así lo confirmaremos antes de gastar una sola hora en ello. El sitio donde sí cambia la conversación es una SPA de cliente con Next.js, y ahí el protocolo que seguimos es este:
- La métrica estable sigue siendo la fuente de verdad. Google lo dice explícitamente: las puntuaciones estables no cambian mientras se evalúa la variante. No tocamos objetivos, contratos ni umbrales de aceptación por un número experimental.
- Capturamos la línea base ahora. Los campos
experimental_*_with_softnavsestán en BigQuery, la API de CrUX y la History API desde la edición de octubre; en noviembre llegan FCP y los tipos de navegación. Guardar octubre-noviembre cuesta una consulta y nos ahorra el espejismo de comparar contra una definición que ya no existirá. - Diagnosticamos con sub-fases, no con el número global. El pase de INP que sube 2,3 pp a nivel agregado no te dice si tu sitio es de los que mejoran o de los que siguen igual. Las tres fases de Cloudflare (y las entradas a nivel de ruta que ya cubrimos en agosto) sí lo dicen.
- Recordamos la fecha de mayo de 2027. Ahí es donde Search Console cambia a los datos nuevos. Los equipos que hayan aprendido su perfil de navegación suave ahora no se sorprenden entonces; los que no, verán un "caída" o una "mejora" que es solo un cambio de instrumento.
La opinión, sin rodeos
Este anuncio es una trampa amable. Un sitio que sube de 55,9% a 59,5% sin tocar código no se ha vuelto más rápido: se ha vuelto mejor medido. El error caro no es leer mal el número — es usar la mejora de medimiento como excusa para cerrar el ticket de rendimiento. Si tu INP estaba en rojo por presentación, seguirá en rojo en la variante experimental, porque el trabajo pesado durante el cambio de vista es real y el usuario lo sigue sintiendo.
La posición que defendemos: la medición se pone más amable justo cuando el diagnóstico se pone más barato, y esa combinación dura hasta mayo de 2027. Aprovecha la ventana —captura la línea base, separa las tres fases y arregla la que domine— antes de que Search Console empiece a reportar con la nueva regla y todos descubran a la vez qué medía su dashboard durante dos años.
Si estás decidiendo arquitectura y este cambio te cambia la conversación, vuelve a Astro vs Next.js en 2026: benchmarks reales — la diferencia entre ir multipágina y en cliente no la borra ningún número experimental — y si lo que necesitas es dónde atacar primero, el diagnóstico por sub-fases de INP a 200 ms sigue siendo el punto de partida.
Preguntas Frecuentes
¿Qué es una navegación suave (soft navigation) en Core Web Vitals?
Es un cambio de vista dentro de una aplicación de página única (SPA) que actualiza el contenido y la URL con JavaScript sin recargar el documento. Antes de octubre de 2026, CrUX solo registraba la carga inicial dura de una SPA y agrupaba todas las interacciones y desplazamientos de toda la sesión en esa URL de entrada; ahora cada navegación suave elegible se mide como su propia navegación y se reporta bajo la URL de destino.
¿Van a cambiar las métricas de mi sitio?
Para la mayoría de sitios, no: en torno al 70% de los orígenes de CrUX tiene menos de 5% de tráfico suave, y solo entre el 7% y el 11% supera el 50%. Los sitios afectados son las SPAs con mucho tráfico interno, y para ellas las métricas mejoran o se mantienen iguales — nunca empeoran. Las puntuaciones estables de Core Web Vitals no cambian mientras la variante experimental se evalúa.
¿Cuándo usará Search Console las métricas con navegaciones suaves?
Google apunta a que las variantes experimentales salgan del modo experimental en mayo de 2027; cuando eso ocurra, Search Console cambia a los datos nuevos. Hasta entonces, las notas de Search Console siguen con las métricas estables, así que el momento de capturar tu línea base es ahora, no después del cambio.
