Seguimiento de los cambios en el informe de Search Console Core Web Vitals Data
Seguimiento del informe Core Web Vitals en Seach Console
¿Cómo se actualiza el informe sobre la experiencia web de Search Console a lo largo del tiempo?
Cuando se trata de los datos del Informe sobre la experiencia del usuario de Chrome (CrUX), existen varios intervalos de tiempo diferentes. PageSpeed Insights lo utiliza para los datos de campo que muestran, y ellos, según sus documentos de soporte, utilizan una ventana de 28 días continuos, por lo que las puntuaciones se agregan para ese tipo de dispositivo durante las últimas 4 semanas. Lo mismo ocurre con la API del Informe UX de Chrome
El conjunto de datos públicos disponible en BigQuery, y que también se utiliza en el panel de control de CrUX en Data Studio, se actualiza una vez al mes.
¿Qué pasa con Google Search Console?
No hay información explícita en la documentación de apoyo sobre qué intervalo de tiempo está involucrado en la agregación de Search Console, tenemos dos intervalos de fechas. El primer lapso de tiempo es el de los gráficos, estos dan 90 días de datos.
El gráfico de Core Web Vitals de Google Search Console
Pero si observamos el gráfico, hay un buen cambio, no parece tan suave como cabría esperar si estas cifras se agregaran a lo largo de los 90 días.
La otra fecha que se menciona, en la documentación de apoyo a este informe, es la conocida de 28 días.
Se menciona en relación con la validación de las correcciones. En concreto, afirman que el inicio de una validación pondrá en marcha 28 días en los que supervisarán las métricas y verán si las pasan al final.
Entonces, ¿cómo lo averiguamos?
Bueno, podemos ser perezosos y preguntar a los Googlers, como el eternamente paciente John Muller.
Pero, como bien señala, ponerse a prueba es la mejor manera de aprender. Así que eso es lo que hice.
La prueba (abreviada)
Identificar un candidato adecuado y realizar una prueba para ello supone un pequeño reto. La naturaleza de CrUX, y la forma en que se recopila, significa que se necesitan volúmenes sostenidos de tráfico, utilizando Chrome con las opciones de intercambio y sincronización requeridas, a lo largo del tiempo.
Esto excluye en gran medida cualquier sitio de pruebas controlado y construido a propósito, lo que necesitamos es un sitio que:
- Tiene suficientes datos de CrUX para completar el informe de Search Console para la propiedad.
- Tiene problemas identificables que se pueden solucionar.
- Tiene un propietario comprensivo que me permitiría ejecutar la prueba.
¡Me las arreglé para encontrar uno que marcaba todas las casillas!
El sitio
El sitio que encontré es un sitio de comercio electrónico, que arrastra algunos problemas de CLS, que no se han solucionado, ya que está a punto de migrar a un nuevo dominio y a una nueva plataforma. Todos los recursos de los desarrolladores se han volcado, naturalmente, en eso, y no en esto.
A pesar de lo comprensivo y sorprendente que es el cliente, no quieren que se revele la identidad del sitio, así que lamentablemente no hay ejemplos de URL reales.
El cambio estaba previsto para finales de marzo de 2021, comencé la prueba el 17 de febrero de 2021, así que debería haberme dado los 28 días completos y un poco más. Pero, en una primicia para el desarrollo web, ¡¡¡el cambio se adelantó!!!. Es una mierda para esta prueba, pero súper feliz para el cliente y el nuevo sitio, está listo para ir, así que ni siquiera una cuestión de tener que aguantar.
Eso significa, sin embargo, que sólo hay 19 días de datos, no los 28 completos que tenía previstos. Consideré la posibilidad de abandonar la idea de escribir esto, pero creo que los datos siguen contando una historia.
Metodología de las pruebas
Necesitaba aislar al máximo los problemas, solucionarlos y controlar los resultados. Para ello, busqué en el informe Core Web Vitals de la consola de búsqueda de los sitios.
Recogí las cifras cada día, empezando por el 17 de febrero, hasta hoy, 7 de marzo. Los datos de la consola de búsqueda están fechados con un día de retraso, como se muestra en el campo «Última actualización» en la parte superior derecha de la vista del informe. Así que los datos que recogí el 17 eran del 16, y así sucesivamente. Normalmente se actualizaba a las 10:30 am (GMT). A veces era un poco más tarde. Esperé a que se actualizara.
Para los datos de origen, lo comprobé a las 14 horas de cada día
Para los datos del mundo real recogidos por mí mismo, los segmenté en visitantes móviles y calculé el percentil 75 de cada día.
También quería probar si al hacer clic en el botón de validación se hace algo notable aparte de controlar los datos, como acelerar la recogida de datos, así que esperé lo que habría sido la mitad de la prueba de 28 días, el 2 de marzo, y solicité la validación.
Los grupos
Search Console agrupa las URLs, la documentación explica que esto se hace por URLs que «proporcionan una experiencia de usuario similar». Eso parecía encajar con lo que encontré, las URLs estaban agrupadas en tipos bastante distintos, que sí parecían tener problemas comunes entre ellos. Como el sitio es un sitio de comercio electrónico bastante estándar en cuanto a su estructura, éstas sí se agrupaban aproximadamente en tipos de páginas, es decir, páginas de listado de productos, páginas de detalles de productos. Así que podría ser que haya algún elemento de la estructura de la página que se utiliza para agrupar las páginas, pero la división en estos grupos es explicable sólo por los problemas comunes de la página. Además, un par de los grupos eran todos tipos de listados de productos, divididos en diferentes grupos, ya que uno tenía sólo un impulsor principal de CLS, el otro tenía eso más otro.
Para reducir el enfoque, miré sólo las cifras móviles, y sólo CLS, una métrica que es un poco más fácil de asegurar que se arregle, y que podría arreglar para el cliente sin chupar tiempo de desarrollo. LCP puede ser un poco más dependiente de la infraestructura, y habría requerido cambios que el equipo de desarrollo tenía que hacer, algo para lo que no tenía tiempo. El sitio no tenía ningún problema de FID que rastrear y arreglar. Así que CLS fue.
Grupo 1
Este fue el grupo más numeroso. A partir del 17 de febrero, se contabilizaron 216 URL con un CLS de 0,3. El cambio fue causado por un filtro lateral / columna de navegación, que en los viewports móviles se apila encima de la columna principal en su lugar, y se colapsa, con un botón para hacer clic para mostrar y ocultar esto.
Las clases CSS requeridas para cambiar esto fueron añadidas por JavaScript, que se ejecutó en el documento listo, lo que significa que hubo parpadeos y desplazamiento ya que esto ocurrió después de la carga de la página.
Cambié la lógica para que no se necesitaran clases adicionales para contraer la columna en móviles, por lo que no fue necesario añadir nada por JavaScript.
Las pruebas locales en algunos ejemplos del grupo mostraron que un CLS de 0,28 – 0,31 bajó a 0,03 – 0,04 (la prueba se hizo utilizando un Moto G4 simulado y velocidades 3g rápidas)
Grupo 2
Este grupo de 79 URLs tuvo un CLS de 0,5 el día 17. Los cambios aquí fueron una combinación del mismo problema que el grupo uno, con otro elemento de navegación superior adicional que mostraba el mismo comportamiento.
La fijación de ambos hizo que las cifras de las pruebas locales pasaran de 0,48-0,53 a los mismos 0,03 – 0,04 del grupo 1.
Grupo 3
Este grupo de 11 URLs tenía un CLS de 0,76 el día 17. A diferencia del grupo 1 y 2, se trataba de páginas de detalles de productos. Una combinación de falta de dimensiones de las imágenes y un carrusel que se comportaba mal fueron los principales problemas.
Las pruebas locales mostraron un CLS de 0,6-0,82, reducido a 0,01
Grupo 4
Este grupo de 53 URLs tenía un CLS de 0,14 pero sólo hizo una breve aparición en Search Console, apareciendo el 1 de marzo y desapareciendo después del día 5. Al igual que el grupo 3, eran páginas a nivel de producto, las pruebas locales mostraron un CLS de 0,01 en el momento en que aparecieron, pero sí tenían más elementos en el carrusel. Por lo tanto, sólo puedo plantear la hipótesis de que fueron peores que el grupo 3 y se habría informado de ello, pero no había suficientes datos de CrUX en este conjunto para informar de toda la prueba.
Grupo bueno
Este grupo apareció el 27 de febrero con 13 URLs y un CLS de 0,03. Estas parecían estar compuestas en su mayoría por URLs que habrían caído en los tres primeros grupos. Las pruebas locales parecían coincidir con esta cifra de 0,03 CLS.
Sospecho que sólo obtuvieron suficientes datos para empezar a aparecer en el informe después de que se fijaran y, por lo tanto, nunca cayeron en los otros grupos.
Otros datos
También comprobé la API de CrUX a diario para obtener los datos de origen y hacer un seguimiento de cómo caía el CLS en todo el sitio, y también recogí datos de usuarios reales utilizando la biblioteca JavaScript de web-vitals, registrando el tipo de dispositivo junto con la métrica.
Los datos
Los datos completos
CLS a lo largo del tiempo
Gráfico de CLS de todos los grupos más origen y ron
Conclusiones
Intervalos de tiempos
Parece que Search Console funciona como la API CrUX, y tiene una ventana móvil de 28 días. Observando los gráficos, las líneas tienen una tendencia a la baja a lo largo de los 19 días de datos que pude recopilar. También están claramente agregadas a lo largo de un periodo de tiempo, la caída fue más suave que la caída brusca por día.
No puedo decir con absoluta confianza que la ventana sea de 28 días, podría ser más corta o más larga, pero parece encajar y siendo un lapso de tiempo común con la API CrUX, y PageSpeed Insights, me sorprendería mucho que fuera diferente.
Validación
El acortamiento del tiempo que se ejecutó da menos confianza aquí, pero parece que es puramente un proceso de monitoreo, y solicitar la validación no cambia lo que se recoge y se informa.
Otras observaciones.
Parece que hay alrededor de 2 días de retraso desde la fijación hasta que empieza a reflejarse en Search Console. Un día se explica porque el informe se actualiza con un día de retraso, y parece que se retrasa un día más. Mirando los datos, se tardó hasta el tercer día hasta que se observó algún movimiento.
Puede saltar un poco. Sospecho que hay periodos en los que no se han recogido suficientes datos sobre el grupo por parte de CrUX, por lo que se mantiene en la estación hasta la próxima vez que haya suficientes. Eso explicaría la naturaleza plana y de buzamiento del gráfico. Sospecho que este sitio está un poco en el límite inferior de la cantidad de visitas móviles válidas para recoger datos.
Otras reflexiones
Instintivamente, sentí que la agrupación en la consola de búsqueda era una mala idea. Yo, como muchos otros, siempre pienso que más datos es mejor. Especialmente pensé que el límite de 20 URLs de ejemplo de cualquier grupo era demasiado limitante.
Sin embargo, en la práctica, esto fue más que suficiente para identificar las áreas problemáticas que tenía este sitio, y arreglarlas. Todo ello sin una cantidad abrumadora de datos. Probablemente seguiría abogando por una mayor cobertura en este caso, y bien podría ser un problema mayor con un sitio que tenga más variación entre las páginas. Pero quizás eso se solucionaría mostrando más grupos.
Realmente me gustaría haber podido realizar esta prueba hasta su conclusión, ¡espero que alguien más por ahí pueda hacerlo! Pero no creo que las conclusiones hubieran sido diferentes, y espero que esta prueba algo reducida sea de alguna utilidad.