Respuestas a preguntas comunes sobre las SPA, las Métricas web esenciales y el plan de Google para abordar las limitaciones actuales de medición
Desde que presentamos la iniciativa Métricas web por primera vez en mayo de 2020, el equipo de Chrome recibimos muchas preguntas y comentarios excelentes sobre el programa.
Quizás el tema sobre el que hemos recibido más preguntas, que probablemente sea la pregunta 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), y cómo las arquitecturas de las SPA afectan las puntuaciones de las Métricas web esenciales.
Estas preguntas son difíciles de responder porque el problema tiene muchos matices. Por eso, en esta publicación haremos todo lo posible para responder las más comunes y proporcionarte tantos detalles y contexto como podamos.
Sin embargo, antes de entrar en detalles específicos, es importante indicar 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) son capaces de brindar experiencias de alta calidad a los usuarios, y nuestra intención con la iniciativa de Web vitals es proporcionar métricas que midan la experiencia de forma independiente de la tecnología. Si bien en la actualidad esto no es posible en todos los casos (debido a las limitaciones de la plataforma web), estamos trabajando activamente para cerrar esas brechas.
Preguntas frecuentes
¿Las métricas web esenciales incluyen transiciones de rutas SPA?
No. Cada una 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 su URL en la barra de direcciones, esto no tendrá ningún efecto en la forma en que se miden las Métricas web esenciales. Los valores de las métricas no se restablecen, y la URL asociada con cada medición de la métrica es la URL a la que navegó el usuario y que inició la carga de la página.
¿Pueden las métricas web esenciales tratar los cambios de ruta de SPA de la misma manera que las cargas de página tradicionales?
Desafortunadamente, no. De todos modos, aún no.
Actualmente, no existe una forma estandarizada de crear una SPA, e incluso entre las SPA populares y las bibliotecas de enrutamiento, la experiencia del usuario puede ser bastante diferente de una app a otra:
- Algunas SPA actualizan la URL solo cuando se carga contenido nuevo de "página completa", mientras que otros sitios actualizan la URL para cambios pequeños de contenido 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 realizan la transición de contenido, de forma asíncrona, a través de varias tareas (sin un evento de finalización de transición claro).
- Algunas SPA siempre cargan contenido desde la red, mientras que otras lo precargan por adelantado para que los cambios de ruta se carguen al instante desde la memoria.
Estas diferencias hacen que definir e identificar lo que constituye un cambio de ruta SPA, o incluso una SPA en sí, sea muy difícil 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 genial si se pudieran aplicar las métricas existentes de las Métricas web esenciales.
Sin embargo, si no se cuenta con una heurística sólida para identificar de manera confiable cambios “reales” en la ruta a partir de todos los demás cambios en la URL, además de indicadores claros que marcan 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 haría que fueran menos útiles o representativos de la experiencia del usuario real en el sitio.
¿Es más difícil para las SPA tener un buen rendimiento en las Métricas web esenciales que en las MPA?
No hay nada inherente en la arquitectura de SPA que evite 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 tienen algunas ventajas para cumplir con los umbrales de las métricas web esenciales que las SPA no tienen en la actualidad. Esto se debe a que, con la arquitectura de la MPA, cada "página" se carga como una navegación de página completa (en lugar de recuperar contenido de forma dinámica e 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 desde el sitio, lo que, a su vez, implica que un porcentaje mayor de la distribución de todas las cargas de páginas de una MPA implicará almacenar en caché algunos o todos los subrecursos.
Sin embargo, para que una MPA tenga un mejor rendimiento en las métricas de Métricas web esenciales que una SPA, se deben cumplir los siguientes requisitos:
- La MPA debe tener un almacenamiento en caché de subrecursos optimizado para garantizar que las cargas de páginas de mismo origen sean realmente más rápidas que las cargas de páginas 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 de almacenamiento en caché que permiten que la página se cargue más rápido.
Dado que las evaluaciones de las Métricas web esenciales consideran el percentil 75 de visitas a la página, tener más visitas a la página de 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 cuando compares las puntuaciones de las Métricas web esenciales, es decir, 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 de origen, o solo se carga la página para una URL de página en particular.
Cuando agregas las puntuaciones de todas las páginas en un origen, las páginas rápidas individuales pueden mejorar el percentil 75 para el origen en general. Sin embargo, cuando se agrega 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 compras no mejorarán las puntuaciones de las cargas iniciales lentas que se experimentan en la página de destino del sitio.
Puedes comprobar la puntuación de tu sitio en busca de 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 individuales de las páginas y de todo el origen.
Otra forma en que la arquitectura de SPA puede afectar las puntuaciones de las Métricas web esenciales es para 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 difíciles en las SPA que en las MPA.
En abril de 2021, anunciamos cambios en la métrica CLS que solucionaron este problema de manera parcial. Antes, CLS se acumulaba durante toda la vida útil de la página, mientras que ahora solo se acumulaba durante un período específico; en esencia, es el peor aumento de actividad de los cambios de diseño en una página determinada.
Sin embargo, incluso con la nueva definición de CLS, las SPA siguen en desventaja porque el valor de CLS no se "restablece" después de una transición de ruta como lo hace con cargas de página completa en una MPA. Esto también puede generar confusión, ya que los cambios de diseño que ocurren 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 (más detalles a continuación).
Si las arquitecturas de SPA mejoran la experiencia del usuario, ¿no debería reflejarse esa mejora en las métricas?
Sí. Aunque se mencionó anteriormente, es difícil cuantificar las mejoras de la experiencia a gran escala, dadas las diferentes formas en que se implementan las SPA en la Web en la actualidad.
Lo cierto es que, históricamente, la industria del rendimiento web (incluido Google) no ha invertido mucho 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 hace 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 si tuviéramos métricas posteriores a la carga bien definidas para medir el rendimiento de la SPA, no queremos ignorar la experiencia de carga solo porque la experiencia posterior a la carga mejoró.
Uno de los objetivos de la iniciativa de las Métricas web es incentivar y promover buenas experiencias del usuario en la mayor cantidad posible de aspectos relacionados con la carga y el uso de una página web. No queremos fomentar situaciones en las que se justifiquen malas experiencias si puedes tener suficientes experiencias buenas para compensarlas. Los usuarios quieren que las páginas se carguen rápido y realicen una transición al contenido nuevo rápidamente. Por ello, intentamos diseñar métricas que favorezcan ese tipo de experiencias.
Por lo tanto, si bien es cierto que una versión de MPA de un sitio puede tener un mejor rendimiento en las métricas de Métricas web esenciales en el percentil 75 que una versión de SPA del mismo sitio, la versión de SPA aún debe esforzarse por alcanzar el umbral de "buena". Si la versión de SPA no cumple con el umbral "buena" para la mayoría de los usuarios, es probable que la experiencia de carga inicial no se perciba como buena, incluso si la experiencia de navegación in-page posterior es excelente.
En el futuro, planeamos desarrollar métricas que fomenten experiencias excelentes después de la carga, y creemos que esta es la mejor manera de incentivar las SPA de alta calidad de una manera que no comprometa la experiencia de carga inicial. Ya entregamos una métrica nueva llamada Interacción a la siguiente pintura (INP), que mide la latencia de interacción durante todo el ciclo de vida de la página, y estamos trabajando de forma activa en otras métricas posteriores a la carga, incluidas las métricas que miden las transiciones de rutas de SPA (consulta a continuación).
Cambiamos nuestro sitio de una MPA a una SPA, y nuestras puntuaciones se redujeron. ¿Es normal?
Depende. Existen 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é semicaliente podría explicar algunos de estos cambios.
Una forma rápida de comprobarlo es probar las versiones de MPA y 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 web esenciales de la versión SPA, es probable que la experiencia de carga empeore después de la actualización.
¿Debería cambiar mi sitio de una SPA a una MPA para obtener una mejor puntuación en las Métricas web esenciales?
Probablemente no. Solo debes cambiar de una SPA a una MPA si no estás conforme con tu pila de SPA y tienes motivos para creer que una MPA proporcionará una mejor experiencia del usuario.
Con el tiempo, a medida que las métricas de las Métricas web esenciales mejoran y abarcan más de la experiencia de navegación completa, los equipos con SPA bien compiladas que proporcionan una UX excelente deberían esperar ver que sus puntuaciones de las Métricas web esenciales reflejan eso.
Si las puntuaciones de las Métricas web esenciales 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 Métricas web esenciales (como Search Console y PageSpeed Insights) obtienen sus datos del Informe sobre la experiencia del usuario en Chrome (CrUX). Y CrUX agrega datos por origen o URL de la página (es decir, la URL de la página en el tiempo de carga).
Por todos los motivos ya mencionados, CrUX no puede agregar datos por ruta de SPA. Sin embargo, como propietario del sitio que está familiarizado con tu propia arquitectura, puedes medirlo tú mismo, y muchas herramientas de estadísticas te permiten indicar cuándo se produce un cambio de ruta de SPA y actualizan tus datos de medición en consecuencia.
Cuando midas las métricas de las Métricas web con una herramienta de estadísticas, asegúrate de medir tanto la URL de ruta actual como la URL de la página original. Esto te permitirá depurar problemas individuales que ocurren durante el 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 las métricas y generan informes sobre ellas.
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 las MPA no tengan una ventaja desleal en comparación con las SPA?
Como se mencionó anteriormente, una MPA optimizada de forma adecuada puede, en algunos casos, informar mejores puntuaciones de Métricas web en el percentil 75 debido al hecho de que probablemente tendrá un porcentaje mayor de visitas a páginas almacenadas en caché. Por el contrario, ninguna de las métricas de las Métricas web esenciales no capturan las mejoras reales en la experiencia del usuario en las SPA optimizadas.
En Google, reconocemos que esto genera incentivos que no se alinean completamente con los objetivos de la iniciativa de Métricas web, por lo que estamos buscando formas de solucionar este problema. Actualmente, estamos explorando dos soluciones posibles, una a corto y otra a largo plazo:
- Evalúa las visitas a la página de origen cruzado y del mismo origen por separado.
- Diseña nuevas APIs que permitan una mejor medición de SPA.
Evalúe las visitas a la página de origen cruzado y de mismo origen por separado
En la actualidad, las métricas web esenciales agregan todas las visitas a la página en un solo bucket. No diferencian entre las visitas o las páginas de destino nuevas y recurrentes, de las páginas de confirmación de compras o cualquier 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 la SPA y la de la MPA sería aplicar distintas ponderaciones a los distintos tipos de visitas, incluso con recomendaciones de umbral completamente diferentes.
Si bien queremos recompensar a las implementaciones eficaces de caché, no queremos que las navegaciones rápidas dentro del sitio puedan cubrir las cargas lentas de la página de destino. Tampoco queremos incentivar a los sitios a dividir páginas largas en un conjunto de páginas más cortas solo para mejorar las puntuaciones de las métricas.
Evaluamos por separado las visitas a páginas de origen cruzado y de mismo origen para 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.
Diseñar nuevas APIs que permitan una mejor medición de SPA
Otra solución en la que se está trabajando activamente (en paralelo a la anterior) es una nueva API del historial de aplicaciones, 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 del historial de apps presenta un evento navigate nuevo, 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ó mediante un clic en un vínculo, el envío de un formulario o la IU del navegador para retroceder o adelantar - Un método
transitionWhile(), que toma una promesa que permite al desarrollador indicar cuándo se completó el trabajo que inició para realizar la navegación
La marca userInitiated se puede utilizar para determinar un punto de partida semántico para una transición de ruta SPA, lo que indica un intent claro del usuario. La resolución de la promesa transitionWhile() puede ayudar al navegador a correlacionar las pinturas con la transición de ruta específica, de modo que pueda determinar el procesamiento de imagen con contenido más grande relacionado con esa transición.
A partir de la idea presentada en la sección anterior, incluso podría ser posible agregar el tiempo de transición de la ruta de SPA en el mismo bucket que las cargas de páginas del mismo origen en una MPA. Esto es interesante porque permitiría que un sitio que migra de una MPA a una SPA compare el rendimiento antes y después.
Por supuesto, se necesita más investigación antes de determinar si podemos tomar estas decisiones 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 está muy comprometido con mejorar las métricas web y garantizar que se midan y se fomenten las experiencias de alta calidad que son importantes para los usuarios. Dicho esto, reconocemos que en la actualidad existen brechas en la medición. Por el momento, las métricas no abarcan todos los aspectos de la experiencia del usuario, pero estamos trabajando activamente para cerrar esas brechas.
A pesar de las limitaciones actuales, creemos que las áreas que las métricas existentes capturan son fundamentales para el estado y el éxito de la Web, y en la medida en que los sitios (sin importar la arquitectura) no cumplan con los umbrales recomendados, creemos que hay margen para mejorar.
Espero que esta publicación te haya ayudado a comprender mejor este tema complejo y lleno de matices. Como siempre, si tienes comentarios sobre las métricas actuales o futuras de las Métricas web, envía un correo electrónico a web-vitals-feedback@googlegroups.com.