Respuestas a preguntas frecuentes sobre las SPA, las Métricas web esenciales y el plan de Google para abordar las limitaciones de medición actuales.
Desde que presentamos la iniciativa de Métricas web en mayo de 2020, en el equipo de Chrome recibimos muchas preguntas y comentarios excelentes sobre el programa.
Quizás el tema sobre el que recibimos más preguntas, y que también es el más difícil de responder, es cómo medir las Métricas web esenciales en una aplicación de una sola página (SPA), así como cómo las arquitecturas de SPA afectan las puntuaciones de las Métricas web esenciales.
Estas preguntas son difíciles de responder porque el problema es bastante complejo, por lo que en esta publicación haremos todo lo posible para responder las preguntas más comunes y proporcionar tantos detalles y contexto como podamos.
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. Nuestra intención con la iniciativa Métricas web es proporcionar métricas que midan la experiencia independientemente de la tecnología. Si bien esto no es posible en todos los casos en la actualidad (debido a las limitaciones de la plataforma web), estamos trabajando activamente para cerrar esas brechas.
Preguntas frecuentes
¿Las métricas de las Métricas web esenciales incluyen las transiciones de ruta de SPA?
No. Cada una de las métricas de las Métricas web esenciales se mide en relación con la navegación actual de la página de nivel superior. Si una página carga contenido nuevo de forma dinámica y actualiza la URL de la página en la barra de direcciones, no afectará la forma en que se miden las métricas de Core Web Vitals. Los valores de las métricas no se restablecen, 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.
¿Las métricas de las Métricas web esenciales pueden tratar los cambios de ruta de SPA de la misma manera que las cargas de páginas tradicionales?
Lamentablemente, no. Al menos, no todavía.
Actualmente, no existe una forma estandarizada de compilar una SPA y, incluso entre las bibliotecas populares de SPA y enrutamiento, la experiencia del usuario puede ser bastante diferente de una app a otra:
- Algunos SPA actualizan la URL solo cuando se carga 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 SPAs 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).
- Algunos SPAs cargan contenido y, luego, actualizan la URL, mientras que otros actualizan la URL antes de cargar el contenido.
- Algunos SPAs cargan contenido de forma simultánea, de forma síncrona, en una sola tarea de JavaScript, mientras que otros transfieren contenido de forma asíncrona en varias tareas (sin un evento de finalización de transición claro).
- Algunos SPA siempre cargan contenido de la red, mientras que otros precargan todo el contenido de antemano para que los cambios de ruta se carguen instantáneamente desde la memoria.
Estas diferencias hacen que sea muy difícil definir e identificar lo que constituye un cambio de ruta de la SPA, o incluso la propia SPA, 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 muy útil que se pudieran aplicar las métricas existentes de las Métricas web esenciales.
Sin embargo, sin heurísticas sólidas para identificar de forma confiable los cambios de ruta "reales" de todos los demás cambios de URL, así como indicadores claros que marquen el principio y el final de esas transiciones, informar las métricas de las métricas web esenciales en estos casos confundiría los datos y los haría menos útiles o representativos de la experiencia real del usuario en el sitio.
¿Es más difícil para las SPA obtener buenos resultados en las Métricas web esenciales que para las MPA?
No hay nada inherente en la arquitectura de SPA que impida que una página en un SPA se cargue con la misma rapidez (y obtenga una puntuación tan buena en todas las métricas de las Métricas web esenciales) como una página similar en un MPA.
Sin embargo, los MPA optimizados de forma adecuada tienen algunas ventajas para cumplir con los umbrales de las Métricas web esenciales que los SPA no tienen actualmente. 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 recuperar contenido de forma dinámica y, luego, insertarlo en la página existente), lo que significa que los usuarios que visitan una MPA tienen más probabilidades de cargar 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 de una MPA incluirá algunos o todos los subrecursos almacenados en caché.
Sin embargo, para que un MPA tenga un mejor rendimiento en las métricas de las Métricas web esenciales que un SPA, se deben cumplir algunos requisitos:
- El MPA debe tener optimizada la caché de subrecursos para garantizar que las cargas de páginas del mismo origen sean más rápidas que las cargas de páginas de varios orígenes en el percentil 75.
- Los usuarios que visitan los MPA deben visitar varias páginas para que el sitio reciba los beneficios del almacenamiento en caché que permiten que las páginas se carguen más rápido.
Dado que las evaluaciones de las Métricas web esenciales consideran el percentil 75 de las visitas a la página, tener más visitas a la página con un 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 es importante tener en cuenta cómo se agregan los datos cuando se comparan las puntuaciones de las Métricas web esenciales, 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 de 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 de la siguiente. En otras palabras, cuando se agregan las puntuaciones de un MPA por página, las cargas rápidas de caché que se ven en la página de confirmación de la compra no mejorarán las puntuaciones de las cargas iniciales lentas que se experimentan en la página de destino del sitio.
Puedes verificar 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 las Métricas web esenciales es en las métricas que consideran el ciclo de vida completo de una página. Dado que los usuarios que visitan las SPAs 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 duras en las SPAs que en las MPAs.
En abril de 2021, anunciamos cambios en la métrica CLS que abordaron parcialmente este problema. Anteriormente, el CLS se acumulaba durante todo el tiempo de vida de la página, mientras que ahora solo se acumula durante un período específico, es decir, la peor ráfaga de cambios de diseño en una página determinada.
Sin embargo, incluso con la nueva definición de CLS, los SPAs siguen teniendo una desventaja, ya que el valor de CLS no se "restablece" después de una transición de ruta, como lo hace con las cargas de página completas en un MPA. Esto también puede generar confusión, ya que los cambios de diseño que se producen después de una transición de ruta se atribuirán a la URL de la página cuando se cargó, no a la URL de la barra de direcciones en el momento del cambio (obtén más detalles a continuación).
Si las arquitecturas de SPA mejoran la experiencia del usuario, ¿no debería esa mejora reflejarse en las métricas?
Sí, debería. Sin embargo, como se mencionó anteriormente, cuantificar cuánto mejoró la experiencia es difícil de hacer a gran escala, dadas todas las diferentes formas en que se implementan los SPA en la Web en la actualidad.
La verdad es que, históricamente, la industria del rendimiento web (incluido Google) no invirtió tanto tiempo y esfuerzo en el desarrollo de métricas centradas en el usuario para el rendimiento posterior a la carga de una página como lo hizo en la carga de la página en sí. Esto no se debe a que el rendimiento después de la carga no sea importante, sino a que la UX y las interacciones después de la carga son mucho más variadas y menos definidas, lo que dificulta el diseño de métricas para ellas.
Sin embargo, incluso si tuviéramos métricas posteriores a la carga bien definidas 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 Métricas web es promover e incentivar buenas experiencias del usuario en tantos aspectos de la carga y el uso de una página web como sea posible. No queremos fomentar situaciones en las que se justifiquen las experiencias negativas si puedes tener suficientes experiencias positivas 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.
Por lo tanto, si bien es cierto que una versión MPA de un sitio puede tener un mejor rendimiento en las métricas de las Métricas web esenciales en el percentil 75 que una versión SPA del mismo sitio, la versión SPA aún debe esforzarse por cumplir con el umbral "bueno". Si la versión de la SPA no cumple con el umbral de "bueno" para la mayoría de los usuarios, es probable que la experiencia de carga inicial siga sin percibirse como buena, incluso si la experiencia de navegación en la página posterior es excelente.
En el futuro, planeamos desarrollar métricas que fomenten experiencias posteriores a la carga excelentes, y creemos que esta es la mejor manera de incentivar SPA de alta calidad de una manera que no comprometa la experiencia de carga inicial. Ya proporcionamos una métrica nueva llamada Interaction to Next Paint (INP) que mide la latencia de interacción durante todo el ciclo de vida de la página y también estamos trabajando activamente en otras métricas posteriores a la carga, incluidas las métricas que miden las transiciones de ruta de SPA (consulta a continuación).
Cambiamos nuestro sitio de un MPA a un SPA y nuestras puntuaciones revirtieron. ¿Es normal?
Depende. Hay varias razones por las 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é activa podría explicar parte del cambio.
Una forma rápida de verificarlo es probar una versión de MPA y una de SPA de una de tus páginas de destino con Lighthouse. Si la puntuación de Lighthouse es más baja en alguna de las métricas de las Métricas web esenciales 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 un SPA a un MPA para obtener una mejor puntuación en las Métricas web esenciales?
Probablemente no. Solo debes cambiar de un SPA a un MPA si no estás conforme con tu pila de SPA y tienes motivos para creer que un MPA proporcionará una mejor experiencia del usuario.
Con el tiempo, a medida que las métricas de las Métricas web esenciales mejoren y cubran más de la experiencia de navegación completa, los equipos con SPA bien diseñados que proporcionan una UX excelente deberían esperar que sus puntuaciones de las Métricas web esenciales lo reflejen.
Si las puntuaciones de las Métricas web esenciales solo se registran para las páginas de destino de un SPA, ¿cómo puedo depurar los problemas que se producen en las "páginas" después de una transición de ruta?
Las herramientas de Google que registran datos de campo para la métrica Métricas web esenciales (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 la página (es decir, la URL de la página en el momento de la carga).
Por todos los motivos mencionados anteriormente, CrUX no puede agregar datos por ruta de SPA. Sin embargo, como propietario de un sitio que está familiarizado con su propia arquitectura, es posible que midas esto por tu cuenta. Además, muchas herramientas de estadísticas te permiten indicar cuándo se produce un cambio de ruta de SPA y actualizar tus datos de medición según corresponda.
Cuando midas las métricas de las Métricas web con una herramienta de estadísticas, asegúrate de medir la URL de la ruta actual y la URL de la página original. Esto te permitirá depurar problemas individuales que ocurren a lo largo del ciclo de vida de la página y agregarlos por URL de la página original para que coincidan con la forma en que las herramientas de Google miden y generan informes sobre las métricas.
Para obtener más detalles y prácticas recomendadas sobre este tema, consulta Cómo depurar el rendimiento en el campo.
¿Qué está haciendo Google para garantizar que los MPA no tengan una ventaja desleal en comparación con los SPA?
Como se mencionó anteriormente, un MPA optimizado de forma adecuada puede, en algunos casos, informar mejores puntuaciones de Métricas web esenciales en el percentil 75 debido a que es probable que tenga un porcentaje más alto de visitas a páginas almacenadas en caché. Por el contrario, actualmente, ninguna de las métricas de las Métricas web esenciales captura las mejoras reales de la experiencia del usuario en los SPA optimizados correctamente.
En Google, reconocemos que esto crea incentivos que no se alinean por completo con los objetivos de la iniciativa Web Vitals y estamos buscando activamente formas de solucionar este problema. Actualmente, estamos explorando dos posibles soluciones, una a corto plazo y otra a largo plazo:
- Evalúa las visitas a páginas de origen cruzado y de origen único por separado.
- Diseñar nuevas APIs que permitan una mejor medición de SPA
Evalúa las visitas a páginas de origen cruzado y de origen único por separado
Actualmente, las métricas de Métricas web esenciales agregan todas las visitas a la página en un solo bucket, no diferencian entre visitas nuevas y recurrentes, páginas de destino y páginas de confirmación de la compra, ni ningún otro tipo de agregación en el que el estado de la caché podría tener un efecto en el rendimiento.
Una forma de normalizar las diferencias entre el rendimiento de las SPA y las MPA sería aplicar una ponderación diferente a los 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.
Si evaluamos por separado las visitas a páginas de origen cruzado y de origen único, 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 cualquier métrica en particular.
Diseña nuevas APIs que permitan una mejor medición de SPA
Otra solución en la que se está trabajando activamente (en paralelo con lo anterior) es una nueva API de App History, que ayudaría a estandarizar los patrones actuales de SPA y facilitaría la medición y comprensión del uso de SPA a gran escala.
La API de App History presenta un nuevo evento navigate, que tiene dos funciones clave específicas para la medición de SPA:
- Una marca
userInitiated, que solo se establecerá como verdadera si la navegación se inició a través de un clic en un vínculo, el envío de un formulario o la IU de atrás o adelante del navegador. - Un método
transitionWhile(), que toma una promesa que le permite al desarrollador indicar cuándo se completa el trabajo que inició para realizar la navegación.
La marca userInitiated se puede usar para determinar un punto de partida semántico para una transición de ruta de SPA, lo que indica un intent del usuario claro. La resolución de promesas transitionWhile() puede ayudar al navegador a correlacionar las pinturas con la transición de ruta específica, de modo que pueda determinar la pintura con contenido más grande relacionada con esa transición.
Basándose en la idea presentada en la sección anterior, incluso podría ser posible agregar el tiempo de transición de la ruta de SPA al mismo bucket que las cargas de páginas del mismo origen en un MPA. Esto es emocionante porque permitiría que un sitio que migre de un MPA a un SPA compare el rendimiento antes y después.
Por supuesto, se necesitan más investigaciones para saber si podemos hacer estas determinaciones con precisión. Si tienes sugerencias o comentarios sobre estas propuestas, envía un correo electrónico a web-vitals-feedback@googlegroups.com.
Reflexiones finales
Google se compromete a mejorar las métricas de las Métricas web y a garantizar que midan e incentiven experiencias de alta calidad que son importantes para los usuarios. Dicho esto, reconocemos que existen brechas de medición en la actualidad. Actualmente, las métricas no abarcan todos los aspectos de la experiencia del usuario, pero estamos trabajando activamente para cerrar estas brechas.
A pesar de las limitaciones actuales, creemos que las áreas que capturan las métricas existentes son fundamentales para el estado y el éxito de la Web, y en la medida en que los sitios (independientemente de la arquitectura) no cumplan con los umbrales recomendados, creemos que hay margen para mejorar.
Espero que esta publicación haya ayudado a aclarar este tema complejo y lleno de matices. Como siempre, si tienes comentarios sobre las métricas actuales o futuras de las métricas Web Vitals, envía un correo electrónico a web-vitals-feedback@googlegroups.com.