Respuestas a preguntas comunes 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 Métricas web en mayo de 2020, del equipo de Chrome recibieron muchas preguntas y comentarios excelentes acerca del .
Quizás el tema sobre el que recibimos más preguntas, que también la más difícil de responder es cómo medir las Métricas web esenciales aplicación de una sola página (SPA), y cómo las arquitecturas de SPA afectan las puntuaciones de Métricas web esenciales.
Estas preguntas son difíciles de responder porque el problema tiene muchos matices, así que en En esta publicación, haremos todo lo que esté a nuestro alcance para responder las preguntas más comunes. con todos los detalles y contexto posibles.
Sin embargo, antes de entrar en detalles, es importante destacar que Google no tienen preferencia en cuanto a la arquitectura o tecnología que se usa para construir un . Creemos que tanto las SPA como las aplicaciones de varias páginas (MPA) pueden de ofrecer experiencias de alta calidad a los usuarios, y nuestra intención con la Web La iniciativa Vitals es proporcionar métricas que midan la experiencia independiente de la tecnología. Si bien actualmente esto no es posible en todos los casos (debido a en la plataforma web), estamos trabajando activamente para cerrar esos brechas de seguridad.
Preguntas frecuentes
¿Las métricas de las Métricas web esenciales incluyen las transiciones de la ruta SPA?
No. Cada una de las métricas web esenciales se mide en relación con la la navegación de páginas de nivel superior. Si una página se carga de forma dinámica contenido y actualiza la URL de la página en la barra de direcciones, no tendrá en la forma en que se miden las métricas de Métricas web esenciales. Los valores de las métricas no son restablecer, y la URL asociada con cada medición de métrica es la URL a la que navegaste hasta la que inició la carga de la página.
¿Pueden las métricas web esenciales tratar los cambios en la ruta de la SPA del mismo modo que las cargas de página tradicionales?
Lamentablemente, no. Aún no.
En la actualidad, no existe una manera estandarizada de crear una SPA, e incluso entre las bibliotecas de enrutamiento y SPA populares, la experiencia del usuario puede ser muy diferente de una aplicación a otra:
- Algunas SPA actualizan la URL solo cuando se carga una nueva "página completa" mientras que Otros sitios actualizan la URL para pequeños cambios de contenido o incluso solo el estado de la IU. cambios.
- Algunas SPA actualizan la URL con la API de History, mientras que otras usan hash para admitir navegadores anteriores (y otros 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 de una sola vez, de forma síncrona, en un único JavaScript. tarea, mientras que otros trasladan el contenido, de forma asíncrona, entre múltiples (sin un evento final de transición claro).
- Algunas SPA siempre cargan contenido desde la red, mientras que otras precargan todo contenido por adelantado para que los cambios en la ruta se carguen instantáneamente desde la memoria.
Estas diferencias hacen que definir e identificar qué constituye una ruta de SPA o incluso en una SPA, es muy difícil de hacer a gran escala.
En algunos casos, un cambio en una ruta SPA es lógicamente idéntico a una carga de página MPA. en esos casos, sería bueno que las métricas existentes que se puede aplicar.
Sin embargo, sin heurísticas sólidas para identificar de forma confiable cambios de ruta desde todos los demás cambios en la URL, así como indicadores claros que marcan el comienzo y el final de tales transiciones, los informes de métricas web esenciales en estos casos se dificultarían los datos y hacerlos menos útiles o representativos de la experiencia real del usuario en el sitio.
¿Es más difícil que las SPA tengan un buen rendimiento en las Métricas web esenciales que en las MPA?
No hay nada inherente en la arquitectura SPA que impida que una página que una SPA se cargue con la misma rapidez y asigne la puntuación tan bien en todos los Métricas web esenciales, como una página similar en una MPA.
Sin embargo, las MPA optimizadas correctamente tienen algunas ventajas a la hora de cumplir con los estándares de la Web Umbrales vitales que las SPA no alcanzan actualmente. Esto se debe a que, con la MPA, arquitectura, 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 un MPA tienen más probabilidades de cargar más de una página de la lo que significa que un porcentaje mayor de la distribución de todas las cargas de páginas de una MPA involucrarán algunos o todos los subrecursos que se se almacenó en caché.
Se otorga para que una MPA tenga un mejor rendimiento en las métricas de Métricas web esenciales que una SPA. requiere algunas cosas para ser ciertas:
- La MPA debe tener un almacenamiento en caché optimizado de subrecursos para garantizar las cargas de páginas del mismo origen son realmente más rápidas que las cargas de páginas de origen cruzado en la Percentil 75.
- Los usuarios que visitan MPA deben visitar varias páginas para que el sitio los beneficios de 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 percentil de la página de visitas, 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 sea 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 cómo se agregan los datos, es decir, si el conjunto de datos en la incluye todas las páginas de tu origen o sitio, o solo las cargas de página de una ubicación la URL de la página.
Cuando se agregan 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 su conjunto. Sin embargo, cuando se agregan por páginas individuales, las puntuaciones de una página no afectarán las puntuaciones de la a continuación. En otras palabras, cuando se agregan los puntajes de una MPA por página, la caché rápida que se ven en la página de confirmación de compras no mejorará las puntuaciones de los mensajes de inicio lentos cargas que se experimentaron en la página de destino del sitio .
Puedes verificar la puntuación de tu sitio para los diferentes métodos de agregación con las PageSpeed Insights o el Informe sobre la experiencia del usuario en Chrome API, 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 métricas que consideran la vida útil completa de una página. Dado que los usuarios que visitan las SPA suelen permanecer en la misma "página" de toda la sesión, las métricas que se acumulan Con el tiempo, puede ser más difícil en las SPA que en las MPA.
En abril de 2021, anunciamos cambios en la métrica de CLS que abordó este problema de forma parcial. Antes, el CLS se acumulaba durante el período la vida útil de una página entera, mientras que ahora solo se acumula en una ventana específica de 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, las SPA siguen en desventaja. porque el valor de CLS no se “restablece” después de que una ruta realiza la transición como lo hace con cargas de página completas en MPA. Esto también puede generar confusión porque el diseño los cambios que ocurran después de una transición de ruta se atribuirán a la URL de la cuando se cargó, no la URL de la barra de direcciones en el momento del cambio (más detalles a continuación).
Si las arquitecturas SPA mejoran la experiencia del usuario, ¿esa mejora no debería reflejarse en las métricas?
Sí. Aunque, como se mencionó anteriormente, cuantificar experiencia ha mejorado es difícil de hacer a gran escala, dadas las diferentes la forma en que las SPA se implementan en la Web actualmente.
La verdad es que la industria del rendimiento web (incluido Google) históricamente no ha invirtió casi el mismo tiempo y esfuerzo en desarrollar modelos de enfoque métricas para el rendimiento posterior a la carga de una para la carga de la página. Esto no se debe a que la carga posterior a la carga el rendimiento no es importante, es porque la UX y las interacciones mucho más variadas y menos definidas, lo que dificulta el diseño de métricas para de ellos.
Pero aun si tuviéramos métricas posteriores a la carga bien definidas para medir la SPA del rendimiento, no queremos ignorar la experiencia de carga solo porque mejoró la experiencia de carga posterior a la carga.
Uno de los objetivos de la iniciativa de Métricas web es incentivar y promover el las experiencias del usuario en todos los aspectos de la carga y el uso de una página web como sea posible. No queremos fomentar situaciones en las que se justifica si puedes tener suficientes experiencias buenas para compensarlas. Usuarios queremos que las páginas se carguen rápido y realicen la transición a contenido nuevo rápido, y tratamos de y diseñar métricas que favorecen ese tipo de experiencias.
Por lo tanto, si bien es cierto que una versión MPA de un sitio podría funcionar mejor en la Web principal. Métricas vitales en el percentil 75 que en una versión SPA del mismo sitio, la versión SPA debe seguir esforzándose por alcanzar la "buena" umbral. Si el botón La versión de SPA no cumple con los requisitos para la mayoría de los usuarios, el umbral inicial de carga del usuario probablemente no se perciba como buena, incluso si los cambios experiencia de navegación de anuncios in-page es excelente.
En el futuro, planeamos desarrollar métricas que fomenten y creemos que esta es la mejor ruta para incentivar SPA de un modo que no comprometa la experiencia de carga inicial. Tenemos ya publicamos una nueva métrica llamada Interaction to Next Paint (INP) que mide la latencia de interacción durante todo el ciclo de vida de la página, y estamos trabajando activamente en otras también las métricas posteriores a la carga, incluidas las métricas que miden las transiciones de la ruta SPA (consulta a continuación).
Cambiamos nuestro sitio de una MPA a una SPA y nuestros puntajes se disminuyeron. ¿Es normal?
Depende. Existen diversos motivos por los que tus puntuaciones pueden cambiar después de un una gran migración de la arquitectura, pero una disminución en la cantidad de cargas de caché templadas podría explicar parte del cambio.
Una forma rápida de comprobarlo sería probar tanto una versión MPA como una SPA de uno de tus las páginas de destino con Faro. Si el botón La puntuación de Lighthouse es más baja en cualquiera de las métricas de Core Web Vitals de la SPA de procesamiento, es probable que la experiencia de carga haya empeorado actualización.
¿Debo cambiar mi sitio de una SPA a una MPA para obtener una mejor puntuación en las Métricas web esenciales?
Probablemente no. Solo deberías 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 la experiencia del usuario.
Con el tiempo, a medida que las métricas web esenciales mejoran y abarcan experiencia de navegación, los equipos con SPA bien elaborados que ofrezcan una excelente UX deberían esperan que sus puntuaciones de Métricas web esenciales reflejen eso.
Si las puntuaciones de 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?
Herramientas de Google que informan datos de campo para la métrica de Métricas web esenciales (como la Búsqueda Console y PageSpeed Insights) obtienen sus datos de la Experiencia del usuario de Chrome Informe (CrUX). Y 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 según Ruta SPA. Sin embargo, como propietario de un sitio conoce su propia arquitectura, puedes medir esto por tu cuenta, y muchas herramientas de análisis te permiten cuando se produce un cambio en la ruta SPA y actualizan los valores de los datos de la empresa según corresponda.
Cuando midas las métricas de las Métricas web con una herramienta de estadísticas, asegúrate de hacer lo siguiente: Medir tanto la URL de ruta actual como la URL original de la página Si confirmas esta acción, Permiten depurar problemas individuales que ocurren en toda la página. del ciclo de vida, además de agregar por URL de la página original para que coincida con la forma de datos para medir las métricas y generar informes sobre ellas.
Para obtener más detalles y conocer las prácticas recomendadas sobre este tema, consulta Depura el rendimiento en la .
¿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 adecuadamente puede, en algunos casos, informar mejor puntuaciones de las Métricas web esenciales en el percentil 75 debido a que probablemente tienen un mayor porcentaje de visitas a páginas almacenadas en caché. Por el contrario, las mejoras reales en la experiencia del usuario en las SPA optimizadas de forma adecuada no se captan actualmente. por cualquiera de las métricas de Métricas web esenciales.
En Google, reconocemos que esto crea incentivos que no se alinean completamente con los objetivos de la iniciativa de Métricas web, y estamos buscando para solucionar este problema. Actualmente, estamos explorando dos posibles soluciones, una a corto plazo y uno más largo:
- Evalúa las visitas a la página de origen cruzado y del mismo origen por separado.
- Diseñar nuevas API que permitan una mejor medición de SPA.
Evalúa las visitas a la página de origen cruzado y del mismo origen por separado
Actualmente, las métricas de las Métricas web esenciales agregan todas las visitas a la página en un solo no diferencian entre las visitas nuevas y las recurrentes, o las páginas de destino las páginas en comparación con las páginas de confirmación de compras o cualquier otro tipo de agregación en el que el estado de caché podría afectar el rendimiento.
Una forma de normalizar las diferencias entre el rendimiento de la SPA y la MPA sería aplicar diferentes ponderaciones a los distintos tipos de visitas, posiblemente incluso con un umbral completamente diferente recomendaciones.
Si bien queremos recompensar las implementaciones eficaces de caché, desean navegaciones rápidas dentro del sitio para cubrir las páginas de destino lentas . Tampoco queremos incentivar a los sitios para que dividan las páginas largas en de páginas más cortas para mejorar las puntuaciones de las métricas.
Al evaluar por separado las visitas a la página entre orígenes cruzados y del mismo origen, podemos ayudar garantizar que ambos tipos de experiencias sean importantes sin permitir que la experiencia la popularidad de un tipo en un sitio determinado sesga la distribución de un métrica
Diseñar nuevas API 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 de App History, que ayudaría a estandarizar las aplicaciones patrones de SPA y facilitar la medición y comprensión del uso de SPA a escala.
La API de App History incorpora una nueva
navigate, que
tiene dos características clave específicas para la medición de SPA:
- R
userInitiatedque solo se establecerá en verdadero si la navegación se inició mediante un clic en el vínculo, envío de formulario o la IU para volver o reenviar el contenido del navegador. - R
transitionWhile()que toma una promesa que le permite al desarrollador indicar cuándo se que ha iniciado para realizar la navegación esté completa.
La marca userInitiated se puede usar para determinar un punto de partida semántico para
una transición de ruta SPA, lo que indica una intención clara del usuario. El transitionWhile()
la resolución de promesas puede ayudar al navegador a correlacionar las pinturas con la ruta específica
de transición, de modo que pueda determinar el color de imagen con contenido más grande
relacionados con esa transición.
A partir de la idea presentada en la sección anterior, incluso podría ser es posible agregar el tiempo de transición de la ruta SPA al mismo bucket que las páginas del mismo origen se cargan en una MPA. Esto es interesante porque permitiría que un sitio migrar de una MPA a una SPA para comparar realmente el rendimiento antes y después después.
Por supuesto, se necesita más investigación antes de saber si podemos tomar estas decisiones. Si tienes sugerencias o comentarios sobre estas propuestas, envíe un correo electrónico web-vitals-feedback@googlegroups.com.
Reflexiones finales
Google está profundamente comprometido con mejorar las métricas web y garantizar miden e incentivan las experiencias de alta calidad que son importantes para usuarios. Dicho esto, sabemos que existen brechas de medición en la actualidad. El no abarcan todos los aspectos de la experiencia del usuario, y estamos trabajando activamente para cerrar esas brechas.
A pesar de las limitaciones actuales, creemos que las áreas que las métricas existentes son cruciales para la salud y el éxito de la Web, y en la medida en que 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 un poco este tema complejo y lleno de matices. Como siempre, si tiene comentarios sobre las métricas de Métricas web actuales o futuras envía un correo electrónico web-vitals-feedback@googlegroups.com.