Respuestas a preguntas frecuentes sobre las SPA, las Métricas web esenciales y cómo las tratan las Métricas web esenciales.
Fecha de publicación: 14 de septiembre de 2021. Última actualización: 11 de agosto de 2026
Desde que presentamos la iniciativa de Web Vitals en mayo de 2020, el equipo de Chrome recibió muchas preguntas y comentarios excelentes sobre el programa.
Quizás el tema sobre el que recibimos más preguntas, que también es probablemente la pregunta más difícil de responder, es cómo medir las Core Web Vitals en una aplicación de una sola página (SPA), así como la forma en que las arquitecturas de SPA afectan las puntuaciones de las Core Web Vitals.
Estas preguntas son difíciles de responder porque el problema es bastante matizado, por lo que, en esta publicación, haremos todo lo posible para responder las preguntas más frecuentes y proporcionar la mayor cantidad de detalles y contexto posible.
Sin embargo, antes de entrar en detalles, es importante aclarar que Google no tiene ninguna preferencia en cuanto a la arquitectura o la tecnología que se usa para crear un sitio. Creemos que las SPA y las aplicaciones de varias páginas (MPA) pueden brindar experiencias de alta calidad a los usuarios, y nuestra intención con la iniciativa de Métricas web es proporcionar métricas que midan la experiencia independientemente de la tecnología.
Preguntas frecuentes
Estas son algunas de las preguntas más frecuentes que recibimos sobre este tema. Nos complace recibir comentarios para agregarlos a esta sección de preguntas frecuentes en nuestro grupo de comentarios o planteando un problema.
¿Las métricas de Core Web Vitals incluyen transiciones de rutas de SPA?
Cuando se introdujeron por primera vez, cada una de las métricas de Métricas web esenciales se medía en relación con la navegación actual de la página de nivel superior. Si una página cargaba contenido nuevo de forma dinámica y actualizaba la URL de la página en la barra de direcciones, no tendría ningún efecto en la forma en que se miden las métricas de Core Web Vitals.
Los valores de las métricas no se restablecieron, y la URL asociada con cada medición de métrica es la URL a la que navegó el usuario que inició la carga de la página.
Chrome 151 introdujo nuevas APIs que permiten medir las Métricas web esenciales en las transiciones de rutas de SPA. Al momento de escribir este artículo (agosto de 2026), estas APIs recién comienzan a usarse en bibliotecas de medición como web-vitals, soluciones de RUM y herramientas como las Herramientas para desarrolladores de Chrome. Chrome aún no publicó los plazos para integrar estas APIs en el Informe sobre la experiencia del usuario en Chrome (CrUX). Además, otros motores de navegadores aún no admiten estas nuevas APIs, por lo que Core Web Vitals solo se pueden medir en las cargas de página completas para esos navegadores.
¿Por qué fue un problema difícil de resolver?
Hoy en día, no hay una forma estandarizada de crear una SPA, y, incluso entre las bibliotecas populares de SPA y de enrutamiento, la experiencia del usuario puede ser muy diferente de una app a otra:
- Algunas SPA actualizan la URL solo cuando cargan contenido nuevo de "página completa", mientras que otros sitios actualizan la URL para cambios de contenido pequeños o incluso solo cambios de estado de la IU.
- Algunas SPA actualizan la URL con la API de History, mientras que otras usan cambios de hash para admitir navegadores más antiguos (y otras no actualizan la URL en absoluto).
- Algunas SPA cargan contenido y, luego, actualizan la URL, mientras que otras actualizan la URL antes de cargar el contenido.
- Algunas SPA cargan contenido todo a la vez, de forma síncrona, en una sola tarea de JavaScript, mientras que otras hacen la transición de contenido de forma asíncrona en varias tareas (sin un evento de finalización de transición claro).
- Algunas SPA siempre cargan contenido de la red, mientras que otras cargan previamente todo el contenido para que los cambios de ruta se carguen de forma instantánea desde la memoria.
Estas diferencias hacen que definir e identificar lo que constituye un cambio de ruta de SPA, o incluso una SPA en sí, sea muy difícil de hacer a gran escala.
En algunos casos, un cambio de ruta de SPA es lógicamente idéntico a una carga de página de MPA, y, en esos casos, sería excelente si se pudieran aplicar las métricas de Core Web Vitals existentes.
Sin embargo, sin una heurística sólida para identificar de manera confiable los cambios de ruta "reales" de todos los demás cambios de URL, así como indicadores claros que marquen el comienzo y el final de esas transiciones, informar las métricas de Core Web Vitals en estos casos enturbiaría los datos y los haría menos útiles o representativos de la experiencia real del usuario en el sitio.
El trabajo de navegación suave proporcionó una solución a esto con dos nuevas APIs de rendimiento:
PerformanceSoftNavigation, que mide cuándo una interacción del usuario genera una pintura y un cambio de URL. La combinación de estas tres cosas proporciona una definición estandarizada de una "navegación suave" independientemente del framework que se use y algunas de las diferencias mencionadas anteriormente. Esto permite dividir la línea de tiempo de rendimiento en "navegaciones" separadas, lo que permite medir el CLS y el INP para cada navegación.InteractionContentfulPaint, que mide las "pinturas con contenido" después de una interacción, lo que permite medir el FCP y el LCP para estas navegaciones suaves.
La combinación de estas dos APIs permite medir las Core Web Vitals en las cargas de página completas y las navegaciones suaves.
¿Los cambios de ruta de SPA son iguales a las cargas de página completas para las Core Web Vitals?
No, todavía hay muchas diferencias entre estos tipos de navegaciones, lo que puede generar diferentes métricas de Métricas web esenciales.
Una navegación suave tiene contenido en la página y actualiza parte o todo ese contenido para mostrar la "página" nueva. En muchos sentidos, esto es similar a la diferencia entre una carga de página completa sin caché y una carga de página cuando algunos o todos los recursos de la página están almacenados en caché, pero a un estado aún más extremo, ya que parte del contenido puede permanecer renderizado.
En teoría, la principal diferencia será el potencial de que las navegaciones suaves sean mucho más rápidas. Pero hay otras diferencias más sutiles.
Las nuevas APIs de navegación suave solo consideran el contenido nuevo. Por lo tanto, una página que actualiza el contenido <h1> y de texto, pero deja la misma imagen hero entre las páginas, no considerará la imagen hero como candidata a LCP si no se vuelve a pintar. Esto generará diferencias en los elementos que se usan para calcular el tiempo de LCP en función de si la misma página se carga como una carga de página completa o como una navegación suave desde otra página existente.
Del mismo modo, el INP puede ser menor para las navegaciones suaves, ya que ya se cargará una gran cantidad de JavaScript necesario para ejecutar el sitio. De la misma manera, una navegación suave puede tener menos (o más) CLS si el mismo contenido causa CLS en una carga de página completa, pero no necesita cargarse ni volver a renderizarse en una navegación suave.
También hay pequeñas diferencias en el momento en que se toman las mediciones de las cargas de página completas (medidas después del procesamiento de la interacción de navegación) en comparación con las navegaciones suaves (medidas desde la hora de inicio de la interacción).
Como se indicó anteriormente, muchas de estas diferencias son similares a las páginas sin caché en comparación con las páginas almacenadas en caché, y el concepto de lo que intentan medir las Core Web Vitals sigue siendo válido. Sin embargo, vale la pena comprender estas sutilezas cuando se investigan problemas de Métricas web esenciales.
¿Es más difícil para las SPA obtener buenos resultados en las Core Web Vitals que para las MPA?
No hay nada inherente en la arquitectura de SPA que impida que una página de una SPA se cargue con la misma rapidez y obtenga la misma puntuación en todas las métricas de Métricas web esenciales que una página similar en una MPA.
Sin embargo, las MPA optimizadas correctamente tienen algunas ventajas para cumplir con los umbrales de Métricas web esenciales que las SPA no tienen. Esto se mitigó en gran medida con el trabajo de navegaciones suaves que se analizó anteriormente, pero aún puede ser el caso cuando aún no se usan estas nuevas APIs. El motivo es que, con la arquitectura de MPA, cada "página" se carga como una navegación de página completa (en lugar de obtener contenido de forma dinámica y insertarlo en la página existente), lo que significa que es más probable que los usuarios que visitan una MPA carguen más de una página del sitio, lo que, a su vez, significa que un porcentaje mayor de la distribución de todas las cargas de página para una MPA incluirá algunos o todos los subrecursos almacenados en caché.
Por supuesto, para que una MPA tenga un mejor rendimiento en las métricas de Core Web Vitals que una SPA, se deben cumplir algunas condiciones:
- La MPA debe tener un almacenamiento en caché de subrecursos optimizado para garantizar que las cargas de página del mismo origen sean más rápidas que las cargas de página de origen cruzado en el percentil 75.
- Los usuarios que visitan las MPA deben visitar varias páginas para que el sitio reciba los beneficios del almacenamiento en caché que generan cargas de página más rápidas.
Dado que las evaluaciones de Core Web Vitals consideran el percentil 75 de las visitas a la página, tener más visitas a la página con buen rendimiento en el conjunto de datos aumentará la probabilidad de que la visita en el percentil 75 de la distribución esté dentro de los umbrales recomendados.
Ten en cuenta que un aspecto importante que se debe considerar cuando se comparan las puntuaciones de Core Web Vitals es cómo se agregan los datos, es decir, si el conjunto de datos de la distribución incluye todas las páginas de tu sitio o origen, o solo las cargas de página para una URL de página en particular.
Cuando se agregan las puntuaciones de todas las páginas de un origen, las páginas rápidas individuales pueden mejorar el percentil 75 del origen en su totalidad. Sin embargo, cuando se agregan por páginas individuales, las puntuaciones de una página no afectarán las puntuaciones de la siguiente. En otras palabras, cuando se agregan las puntuaciones de una MPA por página, las cargas rápidas de caché que se ven en la página de confirmación de compra no mejorarán las puntuaciones de las cargas iniciales lentas que se experimentan en la página de destinodel sitio.
Puedes consultar la puntuación de tu sitio para diferentes métodos de agregación con PageSpeed Insights o la API del Informe sobre la experiencia del usuario en Chrome, que informa las puntuaciones de las URLs de páginas individuales y de todo el origen.
Otra forma en que la arquitectura de SPA puede afectar las puntuaciones de Core Web Vitals es para las métricas que consideran la vida útil completa de una página. Dado que los usuarios que visitan las SPA tienden a permanecer en la misma "página" durante toda la sesión, las métricas que se acumulan con el tiempo pueden ser más estrictas en las SPA que en las MPA.
Con el trabajo de navegaciones suaves, creemos que no debería haber desventajas para las SPA en términos de cómo se pueden medir las Métricas web esenciales. Sin embargo, la integración completa de estas APIs en todas las herramientas y soluciones de informes llevará tiempo.
Si las arquitecturas de SPA mejoran la experiencia del usuario, ¿no debería reflejarse esa mejora en las métricas?
Sí, debería. Cuantificar cuánto mejoró la experiencia fue difícil de hacer a gran escala, dadas todas las formas diferentes en que se implementan las SPA en la Web hoy en día. Ahora tenemos una solución para el problema de medición, y, cuando se usen estas nuevas APIs, cualquier mejora que se produzca al pasar a las SPA debería reflejarse en las métricas.
La verdad es que la industria del rendimiento web (incluido Google) históricamente no invirtió tanto tiempo y esfuerzo en desarrollar métricas centradas en el usuario para el rendimiento posterior a la carga de una página como lo hizo para la carga de la página en sí. Esto no se debe a que el rendimiento posterior a la carga no sea importante, sino a que la UX y las interacciones posteriores a la carga son mucho más variadas y menos definidas, lo que dificulta el diseño de métricas para ellas.
Pero incluso ahora que tenemos más métricas posteriores a la carga para medir el rendimiento de la SPA, no querríamos ignorar la experiencia de carga solo porque la experiencia posterior a la carga mejoró.
Uno de los objetivos de la iniciativa de Web Vitals es promover y fomentar las buenas experiencias del usuario en la mayor cantidad posible de aspectos de la carga y el uso de una página web. No queremos fomentar situaciones en las que se justifiquen las malas experiencias si puedes tener suficientes experiencias buenas para compensarlas. Los usuarios quieren que las páginas se carguen rápido y que la transición al contenido nuevo sea rápida, y tratamos de diseñar métricas que favorezcan esos tipos de experiencias.
Cambiamos nuestro sitio de una MPA a una SPA y nuestras puntuaciones disminuyeron. ¿Es lo esperado?
Depende. Hay varios motivos por los que tus puntuaciones podrían cambiar después de una migración de arquitectura importante, pero una disminución en la cantidad de cargas de caché activas podría explicar parte del cambio.
Una forma rápida de verificarlo sería probar una versión MPA y una SPA de una de tus páginas de destino con Lighthouse. Si la puntuación de Lighthouse es más baja en cualquiera de las métricas de Core Web Vitals para la versión de SPA, es probable que la experiencia de carga haya empeorado después de la actualización.
¿Debo cambiar mi sitio de una SPA a una MPA para obtener mejores puntuaciones en las Métricas web esenciales?
Probablemente no. Solo debes cambiar de una SPA a una MPA si no estás satisfecho con tu pila de SPA y tienes motivos para creer que una MPA proporcionará una mejor experiencia del usuario.
Con el trabajo de navegaciones suaves, creemos que abordamos los problemas de medición, por lo que cambiar por ese motivo no tiene sentido.
Sin embargo, si tienes motivos para demostrar que el rendimiento mejorará, en lugar de solo las mediciones, ese puede ser un motivo para cambiar de SPA a MPA (o viceversa).
Si las puntuaciones de Core Web Vitals solo se informan para las páginas de destino de una SPA, ¿cómo puedo depurar los problemas que ocurren en las "páginas" después de una transición de ruta?
Las herramientas de Google que informan datos de campo para la métrica de Core Web Vitals (como Search Console y PageSpeed Insights) obtienen sus datos del Informe sobre la experiencia del usuario en Chrome (CrUX). Además, CrUX agrega datos por origen o por URL de página (es decir, la URL de la página en el tiempo de carga).
Estamos trabajando para permitir que CrUX incluya datos por ruta de SPA en sus datos agregados. Sin embargo, como propietario del sitio, ahora puedes usar las nuevas APIs para medir Core Web Vitals por ruta de SPA antes de esto para comprender cómo pueden cambiar tus puntuaciones.
Para obtener más detalles y prácticas recomendadas sobre este tema, consulta Cómo medir navegaciones suaves.
¿Qué hace Google para garantizar que las MPA no tengan una ventaja injusta en comparación con las SPA?
Como se mencionó anteriormente, con el trabajo de navegaciones suaves, creemos que el trabajo que realizamos ahora significa que no debería haber desventajas para las SPA en este sentido, aunque la integración completa en todas las herramientas y soluciones de informes llevará tiempo.
Evalúa las visitas a la página de origen cruzado y del mismo origen por separado
Hoy en día, las métricas de Core Web Vitals agregan todas las visitas a la página en un solo bucket. No diferencian entre visitas nuevas y visitantes recurrentes, páginas de destino y páginas de confirmación de compra, ni ningún otro tipo de agregación en el que el estado de la caché pueda tener un efecto en el rendimiento.
Una forma de normalizar las diferencias entre el rendimiento de SPA y MPA sería aplicar diferentes ponderaciones a diferentes tipos de visitas, incluso con recomendaciones de umbral completamente diferentes.
Si bien queremos recompensar las implementaciones de caché eficaces, no queremos que las navegaciones rápidas dentro del sitio puedan encubrir las cargas lentas de la página de destino. Tampoco queremos incentivar a los sitios a dividir las páginas largas en una colección de páginas más cortas solo para mejorar las puntuaciones de las métricas.
Al evaluar por separado las visitas a la página de origen cruzado y del mismo origen, podemos ayudar a garantizar que ambos tipos de experiencias sean importantes sin permitir que la popularidad relativa de un tipo en un sitio determinado sesgue la distribución de una métrica en particular.
Reflexiones finales
Google se compromete a mejorar las métricas de Web Vitals y a garantizar que midan y fomenten experiencias de alta calidad que sean importantes para los usuarios. Dicho esto, reconocemos que existen brechas de medición en la actualidad. Las métricas ahora pueden cubrir las transiciones de rutas de SPA, lo que aborda una de las brechas principales.
También creemos que estas nuevas APIs (en particular, InteractionContentfulPaint) tienen más usos y beneficios potenciales más allá de la medición de Core Web Vitals para navegaciones suaves. Nos entusiasma seguir desarrollándolas ahora que se abordó el motivo principal de su introducción.
Espero que esta publicación te haya ayudado a comprender mejor este tema complejo y matizado. Como siempre, si tienes comentarios sobre las métricas de Métricas web actuales o futuras, envía un correo electrónico a web-vitals-feedback@googlegroups.com.