Una guía detallada para medir Core Web Vitals

Google ha anunciado que a partir de mayo de 2021 ( edición : la fecha se movió a junio de 2021), comenzarán a considerar la "Experiencia de la página" como parte del ranking de búsqueda, medido por un conjunto de métricas llamadas Core Web Vitals. Esa fecha se acerca rápidamente y estoy seguro de que a muchos de nosotros se nos pide que nos aseguremos de que estamos pasando nuestros Core Web Vitals, pero ¿cómo puede saber si es así?

Responder a esa pregunta es en realidad más difícil de lo que podría suponer y, si bien muchas herramientas ahora están exponiendo estos Core Web Vitals, hay muchos conceptos y sutilezas importantes que comprender. incluso las herramientas de Google como PageSpeed ​​Insights y el informe Core Web Vitals en Google Search Console parecen brindar información confusa.

¿Por qué es eso y cómo puede estar seguro de que sus correcciones realmente han funcionado? ¿Cómo puede obtener una imagen precisa de Core Web Vitals para su sitio? En esta publicación, intentaré explicar un poco más sobre lo que está sucediendo aquí y explicar algunos de los matices y malentendidos de estas herramientas.

¿Qué son los principales web vitals?

Core Web Vitals es un conjunto de tres métricas diseñadas para medir la experiencia "central" de si un sitio web se siente rápido o lento para los usuarios y, por lo tanto, brinda una buena experiencia.

Las páginas web deberán estar dentro de las medidas verdes para los tres Core Web Vitals para obtener el beneficio completo de cualquier aumento de clasificación. Fuera del buen rango, los diferentes valores de una métrica Core Web Vital en dos páginas podrían dar como resultado una clasificación de experiencia de página diferente.

1. Pintura con contenido más grande (LCP)

Esta métrica es probablemente la más fácil de entender de todas: mide la rapidez con la que se dibuja el elemento más grande en la página, que es probablemente el contenido que le interesa al usuario. Puede ser una imagen de banner, un fragmento de texto o lo que. El hecho de que sea el elemento con mayor contenido de la página es un buen indicador de que es la pieza más importante. LCP es relativamente nuevo, y solíamos medir el First Contentful Paint (FCP) de nombre similar, pero LCP se ha visto como una mejor métrica para cuando se dibuja el contenido que el visitante probablemente quiere ver.

Se supone que LCP mide el rendimiento de carga y es un buen proxy para todas las métricas antiguas que solíamos usar en la comunidad de rendimiento (es decir, tiempo hasta el primer byte (TTFB), contenido DOM cargado, renderizado inicial, índice de velocidad), pero desde la experiencia del usuario No cubre toda la información cubierta por esas métricas, pero es una métrica única más simple que intenta dar una buena indicación de la carga de la página.

2. Primera demora de entrada (FID)

Esta segunda métrica mide el tiempo que transcurre entre que el usuario interactúa con una página, haciendo clic en un enlace o un botón, por ejemplo, y cuando el navegador procesa ese clic. Está ahí para medir la interactividad de una página . Si se carga todo el contenido, pero la página no responde, es una experiencia frustrante para el usuario.

Un punto importante es que esta métrica no se puede simular, ya que realmente depende de cuándo un usuario realmente hace clic o interactúa con una página y luego cuánto tiempo lleva actuar. El tiempo de bloqueo total (TBT) es un buen indicador de FID cuando se utiliza una herramienta de prueba sin interacción directa del usuario, pero también debe vigilar el tiempo de interacción (TTI) cuando se mira FID.

3. Cambio de diseño acumulativo (CLS)

Una métrica muy interesante, muy diferente a otras métricas anteriores por varias razones. Está diseñado para medir la estabilidad visual de la página , básicamente cuánto salta a medida que se colocan nuevos espacios de contenido. Estoy seguro de que todos hicimos clic en un artículo, comenzamos a leer y luego el texto saltó mientras se cargaban imágenes, anuncios y otros contenidos.

Esto es bastante discordante y molesto para los usuarios, por lo que es mejor minimizarlo. ¡Peor aún es cuando ese botón en el que estabas a punto de hacer clic se mueve repentinamente y haces clic en otro botón en su lugar! CLS intenta dar cuenta de estos cambios de diseño.

Laboratorio contra ron

Uno de los puntos clave a entender sobre Core Web Vitals es que se basan en métricas de campo o Real User Metrics (RUM). Google utiliza datos anónimos de los usuarios de Chrome para evaluar las métricas y las pone a disposición en el Informe de experiencia del usuario de Chrome (CrUX). Esos datos son los que están usando para medir estas tres métricas para las clasificaciones de búsqueda. Los datos de CrUX están disponibles en varias herramientas, incluso en Google Search Console para su sitio.

El hecho de que se utilicen datos RUM es una distinción importante porque algunas de estas métricas (excepto FID) están disponibles en herramientas de rendimiento web sintéticas o "basadas en laboratorio" como Lighthouse, que han sido el elemento básico del monitoreo del rendimiento web para muchos en el pasado. . Estas herramientas ejecutan cargas de página en redes y dispositivos simulados y luego le informan cuáles fueron las métricas para esa ejecución de prueba.

Entonces, si ejecuta Lighthouse en su máquina de desarrollador de alta potencia y obtiene excelentes puntajes, es posible que eso no refleje lo que los usuarios experimentan en el mundo real y, por lo tanto, lo que Google usará para medir la experiencia de usuario de su sitio web.

LCP va a depender mucho de las condiciones de la red y de la potencia de procesamiento de los dispositivos que se utilizan (¡y es probable que muchos más de sus usuarios utilicen dispositivos de menor potencia de lo que cree!). Sin embargo, un contrapunto es que, al menos para muchos sitios occidentales, nuestros móviles quizás no sean tan de bajo consumo como sugieren herramientas como Lighthouse en modo móvil, ya que están bastante estranguladas. Por lo tanto, puede notar que sus datos de campo en dispositivos móviles son mejores que las pruebas con esta sugerencia (hay algunas discusiones sobre cómo cambiar la configuración móvil de Lighthouse).

Del mismo modo, FID a menudo depende de la velocidad del procesador y de cómo el dispositivo puede manejar todo este contenido que le enviamos, ya sean imágenes para procesar, elementos para diseñar en la página y, por supuesto, todo el JavaScript que nos encanta enviar. al navegador para batir a través.

CLS, en teoría, se mide más fácilmente en herramientas, ya que es menos susceptible a las variaciones de red y hardware, por lo que pensaría que no está tan sujeto a las diferencias entre LAB y RUM, excepto por algunas consideraciones importantes que inicialmente pueden no ser obvias. :

• Se mide a lo largo de la vida de la página y no solo para la carga de la página como lo hacen las herramientas típicas, que exploraremos más adelante en este artículo. Esto genera mucha confusión cuando las cargas de página simuladas en el laboratorio tienen un CLS muy bajo, pero la puntuación CLS del campo es mucho más alta, debido al CLS causado por el desplazamiento u otros cambios después de la carga inicial que las herramientas de prueba suelen medir.
• Puede depender del tamaño de la ventana del navegador ; por lo general, herramientas como PageSpeed ​​Insights miden dispositivos móviles y de escritorio, pero los diferentes dispositivos móviles tienen diferentes tamaños de pantalla y los escritorios suelen ser mucho más grandes que el conjunto de estas herramientas (Web Page Test aumentó recientemente su tamaño de pantalla predeterminado para tratar de reflejar con mayor precisión el uso).
• Diferentes usuarios ven cosas diferentes en las páginas web . Los banners de cookies, el contenido personalizado como promociones, los bloqueadores de anuncios, las pruebas A/B, por nombrar algunos elementos que pueden ser diferentes, afectan el contenido que se dibuja y, por lo tanto, lo que los usuarios de CLS pueden experimentar.
• Todavía está evolucionando y el equipo de Chrome ha estado ocupado arreglando cambios "invisibles" y similares que no deberían contar para el CLS. También se están realizando cambios más importantes en la forma en que CLS se mide realmente. Esto significa que puede ver diferentes valores de CLS según la versión de Chrome que se esté ejecutando.

Usar el mismo nombre para las métricas en las herramientas de prueba basadas en laboratorio, cuando pueden no ser reflejos precisos de las versiones de la vida real, es confuso y algunos sugieren que deberíamos cambiar el nombre de algunas o todas estas métricas en Lighthouse para distinguir estas métricas simuladas de las métricas RUM del mundo real que impulsan las clasificaciones de Google.

Métricas de rendimiento web anteriores

Otro punto de confusión es que estas métricas son nuevas y diferentes de las métricas que tradicionalmente usábamos en el pasado para medir el rendimiento web y que aparecen en algunas de esas herramientas, como PageSpeed ​​Insights, una herramienta de auditoría en línea gratuita. Simplemente ingrese la URL que desea auditar y haga clic en Analizar, y unos segundos más tarde se le presentarán dos pestañas (una para dispositivos móviles y otra para computadoras de escritorio) que contienen una gran cantidad de información:

En la parte superior está la gran puntuación de rendimiento de Lighthouse sobre 100. Esto es bien conocido en las comunidades de rendimiento web desde hace un tiempo y a menudo se cita como una métrica de rendimiento clave para apuntar y resumir las complejidades de muchas métricas en un simple , número fácil de entender. Eso tiene cierta superposición con el objetivo Core Web Vitals, pero no es un resumen de los tres Core Web Vitals (incluso las versiones basadas en laboratorio), sino de una variedad más amplia de métricas.

Actualmente, seis métricas conforman la puntuación de rendimiento de Lighthouse, incluidas algunas de Core Web Vitals y algunas otras métricas:

• Primera pintura con contenido (FCP)
• Índice de velocidad (SI)
• Pintura con contenido más grande (LCP)
• Tiempo para Interactivo (TTI)
• Tiempo total de bloqueo (TBT)
• Cambio de diseño acumulativo (CLS)

Para agregar a la complejidad, cada uno de estos seis tiene un peso diferente en el puntaje de rendimiento y CLS, a pesar de ser uno de los Core Web Vitals, actualmente es solo el 5% del puntaje de Lighthouse Performance (apuesto dinero a que esto aumentará poco después). se lanza la siguiente iteración de CLS). Todo esto significa que puede obtener una puntuación de rendimiento Lighthouse de color verde muy alta y pensar que su sitio web está bien y aún así no pasar el umbral de Core Web Vitals. Por lo tanto, es posible que deba reenfocar sus esfuerzos ahora para observar estas tres métricas principales.

Más allá del gran puntaje verde en esa captura de pantalla, pasamos a los datos de campo y obtenemos otro punto de confusión: First Contentful Paint se muestra en estos datos de campo junto con los otros tres Core Web Vitals, a pesar de no ser parte de Core Web. Vitals y, como en este ejemplo, a menudo encuentro que está marcado como una advertencia incluso cuando todos los demás pasan. (¿Quizás los umbrales para esto necesitan un pequeño ajuste?) ¿FCP perdió por poco ser un Core Web Vital, o tal vez solo se ve mejor equilibrado con cuatro métricas? Esta sección de datos de campo es importante y volveremos a eso más adelante.

Si no hay datos de campo disponibles para la URL en particular que se está probando, en su lugar se mostrarán los datos de origen de todo el dominio (esto está oculto de manera predeterminada cuando los datos de campo están disponibles para esa URL en particular, como se muestra arriba).

Después de los datos de campo, obtenemos los datos de laboratorio y vemos las seis métricas que conforman la puntuación de rendimiento en la parte superior. Si hace clic en el interruptor en la parte superior derecha, incluso obtiene una descripción un poco más detallada de esas métricas:

Como puede ver, las versiones de laboratorio de LCP y CLS se incluyen aquí y, como forman parte de Core Web Vitals, tienen una etiqueta azul para marcarlas como muy importantes. PageSpeed ​​Insights también incluye un útil enlace de calculadora para ver el impacto de estos puntajes en el puntaje total en la parte superior, y le permite ajustarlos para ver qué efecto tendrá en su puntaje mejorar cada métrica. Pero, como digo, es probable que el puntaje de rendimiento web quede en segundo plano por un momento, mientras que Core Web Vitals disfruta del brillo de toda la atención en este momento.

Lighthouse también realiza cerca de otras 50 verificaciones en Oportunidades y Diagnósticos adicionales. Estos no afectan directamente el puntaje, ni Core Web Vitals, pero los desarrolladores web pueden usarlos para mejorar el rendimiento de su sitio . Estos también aparecen en PageSpeed ​​Insights debajo de todas las métricas, por lo que están fuera de lugar para la captura de pantalla anterior. Piense en esto como sugerencias sobre cómo mejorar el rendimiento, en lugar de problemas específicos que necesariamente deben abordarse.

El diagnóstico le mostrará el elemento LCP y los cambios que han contribuido a su puntaje CLS, que son información muy útil al optimizar para su Core Web Vitals.

Por lo tanto, si bien en el pasado los defensores del rendimiento web pueden haberse concentrado en gran medida en las puntuaciones y auditorías de Lighthouse, veo que esto se centra en las tres métricas Core Web Vital, al menos durante el próximo período mientras las analizamos. Las otras métricas de Lighthouse y la puntuación general siguen siendo útiles para optimizar el rendimiento de su sitio, pero Core Web Vitals actualmente está tomando la mayor parte de la tinta en el nuevo rendimiento web y las publicaciones de blog de SEO.

Visualización de los principales elementos vitales de la Web para su sitio

La forma más fácil de echar un vistazo rápido a Core Web Vitals para una URL individual y para todo el origen es ingresar una URL en PageSpeed ​​Insights como se mencionó anteriormente. Sin embargo, para ver cómo Google ve Core Web Vitals para todo su sitio, acceda a Google Search Console. Este es un producto gratuito creado por Google que le permite comprender cómo Google "ve" todo su sitio, incluidos los Core Web Vitals para su sitio (aunque hay algunas, digamos, " frustraciones " con la frecuencia con la que se actualizan los datos aquí ).

Los equipos de SEO han utilizado Google Search Console durante mucho tiempo, pero con la información que los desarrolladores de sitios necesitarán para abordar Core Web Vitals, los equipos de desarrollo también deberían tener acceso a esta herramienta si aún no lo han hecho. Para obtener acceso, necesitará una cuenta de Google y luego verificar su propiedad del sitio a través de varios medios (colocando un archivo en su servidor web, agregando un registro DNS, etc.).

El informe Core Web Vitals en Google Search Console le brinda un resumen de cómo su sitio está cumpliendo con Core Web Vitals durante los últimos 90 días:

Idealmente, para que se considere que está pasando Core Web Vitals por completo, desea que todas sus páginas sean verdes , sin ámbar ni rojos. Si bien un ámbar es un buen indicador de que está cerca de pasar, en realidad solo los verdes cuentan para obtener el beneficio completo, así que no se conforme con el segundo lugar. Depende de usted si necesita que todas sus páginas pasen o solo las clave, pero a menudo habrá problemas similares en muchas páginas, y arreglarlos para el sitio puede ayudar a que la cantidad de URL que no pasan sea más manejable. nivel en el que puede tomar esas decisiones.

Inicialmente, Google solo aplicará la clasificación Core Web Vitals a los dispositivos móviles, pero seguramente solo es cuestión de tiempo antes de que eso también se implemente en el escritorio, así que no ignores el escritorio mientras estás revisando y arreglando tus páginas.

Al hacer clic en uno de los informes, obtendrá más detalles sobre cuáles de los elementos vitales de la web no se cumplen y, luego, una muestra de las URL afectadas. Google Search Console agrupa las URL en cubos para, en teoría, permitirle abordar páginas similares juntas. Luego puede hacer clic en una URL para ejecutar PageSpeed ​​Insights para realizar una auditoría de rendimiento rápida en la URL en particular (que incluye mostrar los datos de campo de Core Web Vitals para esa página, si están disponibles). Luego soluciona los problemas que resalta, vuelve a ejecutar PageSpeed ​​Insights para confirmar que las métricas de laboratorio ahora son correctas y luego pasa a la página siguiente.

Sin embargo, una vez que comienza a mirar ese informe Core Web Vitals (¡obsesivamente para algunos de nosotros!), es posible que se sienta frustrado porque este informe no parece actualizarse para reflejar su arduo trabajo. Parece que se actualiza todos los días a medida que el gráfico se mueve, pero a menudo apenas cambia incluso una vez que haya publicado sus correcciones, ¿por qué?

Del mismo modo, los datos de campo de PageSpeed ​​Insights aún muestran obstinadamente que la URL y el sitio fallan. ¿Cuál es la historia aquí entonces?

El Informe de experiencia de usuario de Chrome (CrUX)

La razón por la que Web Vitals tarda en actualizarse es que los datos de campo se basan en los datos de los últimos 28 días en el Informe de experiencia del usuario de Chrome (CrUX), y dentro de eso, solo el percentil 75 de esos datos. El uso de datos de 28 días y los percentiles 75 de datos son cosas buenas, ya que eliminan las variaciones y los extremos para brindar un reflejo más preciso del rendimiento de su sitio sin causar mucho ruido que es difícil de interpretar.

Las métricas de rendimiento son muy susceptibles a la red y los dispositivos, por lo que debemos suavizar este ruido para llegar a la historia real del rendimiento de su sitio web para la mayoría de los usuarios. Sin embargo, la otra cara de esto es que son frustrantemente lentos para actualizar, creando un ciclo de retroalimentación muy lento desde la corrección de problemas, hasta que vea los resultados de esa corrección reflejados allí.

El percentil 75 (o p75) en particular es interesante y el retraso que crea, ya que no creo que se entienda bien. Analiza qué métrica representa el 75 % de las visitas a la página de sus visitantes durante esos 28 días para cada uno de los Core Web Vitals.

Por lo tanto, es el puntaje más alto de Core Web Vital del 75% de las vistas de su página (o, por el contrario, el puntaje más bajo de Core Web Vitals que el 75% de las visitas de su página tendrán menos). Así que no es la media de este 75% de páginas vistas, sino el peor valor de ese conjunto de usuarios.

Esto crea un retraso en la notificación que no se produciría con un promedio móvil no basado en percentiles. Tendremos que ser un poco matemáticos aquí (intentaré mantenerlo al mínimo), pero digamos, por simplicidad, que todos obtuvieron un LCP de 10 segundos durante el último mes, y lo arreglaron, así que ahora solo toma 1 segundo, y digamos que tuvo exactamente la misma cantidad de visitantes todos los días y todos obtuvieron este LCP.

En ese escenario demasiado simplista, obtendrías las siguientes métricas:

Entonces puede ver que no ve sus mejoras drásticas en el puntaje CrUX hasta el día 22, cuando de repente salta al nuevo valor más bajo (una vez que cruzamos el 75% del promedio de 28 días, ¡no es coincidencia!). Hasta entonces, más del 25 % de sus usuarios se basaban en datos recopilados antes del cambio, por lo que obtenemos el valor anterior de 10 y, por lo tanto, su valor de p75 se quedó atascado en 10.

Por lo tanto, parece que no ha progresado en absoluto durante mucho tiempo, mientras que un promedio medio (si se usó) mostraría una disminución gradual que comenzaría de inmediato y, por lo tanto, podría verse el progreso. En el lado positivo, durante los últimos días, la media es en realidad más alta que el valor de p75 ya que p75, por definición, filtra los extremos por completo.

El ejemplo de la tabla anterior, aunque enormemente simplificado, explica una de las razones por las que muchos pueden ver gráficos Web Vitals como el siguiente, en el que un día todas sus páginas cruzan un umbral y luego son buenas ( ¡woohoo! ):

Esto puede sorprender a aquellos que esperan cambios más graduales (e instantáneos) a medida que resuelven los problemas de la página y que algunas páginas se visitan con más frecuencia que otras. En una nota relacionada, tampoco es inusual ver que el gráfico de Search Console pasa por un período ámbar , dependiendo de sus correcciones y cómo afectan los umbrales, antes de alcanzar ese dulce color verde:

Dave Smart, llevó a cabo un experimento fascinante, Seguimiento de cambios en los datos vitales de la web de Report Core de Search Console, en el que quería ver la rapidez con la que se actualizaban los gráficos. No tuvo en cuenta la porción del percentil 75 de CrUX (lo que hace que la falta de movimiento en algunos de sus gráficos tenga más sentido), ¡pero sigue siendo un experimento fascinante de la vida real sobre cómo se actualiza este gráfico y vale la pena leerlo!

Mi propia experiencia es que esta metodología p75 de 28 días no explica completamente el retraso en el informe Core Web Vitals, y discutiremos algunas otras posibles razones en un momento.

Entonces, ¿es lo mejor que puede hacer, hacer las correcciones, luego esperar pacientemente, tocando con los dedos, hasta que CrUX considere que sus correcciones valen la pena y actualice el gráfico en Search Console y PageSpeed ​​Insights? Y si resulta que sus arreglos no fueron lo suficientemente buenos, ¿entonces comienza todo el ciclo de nuevo? En este día de retroalimentación instantánea para satisfacer nuestros antojos, y ciclos de retroalimentación estrechos para que los desarrolladores mejoren la productividad , ¡eso no es nada satisfactorio!

Bueno, hay algunas cosas que puede hacer mientras tanto para tratar de ver si las correcciones tendrán el impacto deseado.

Profundizando en los datos cruciales con más detalle

Dado que el núcleo de la medición son los datos de CrUX, profundicemos un poco más y veamos qué más nos puede decir. Volviendo a PageSpeed ​​Insights, podemos ver que muestra no solo el valor p75 del sitio, sino también el porcentaje de visitas a la página en cada uno de los cubos verde, ámbar y rojo que se muestran en las barras de colores debajo:

La captura de pantalla anterior muestra que CLS está fallando en la puntuación de Core Web Vitals con un valor p75 de 0.11, que está por encima del límite de aprobación de 0.1. Sin embargo, a pesar de que el color de la fuente es rojo, en realidad se trata de una clasificación ámbar (ya que el rojo estaría por encima de 0,25). Más interesante es que la barra verde está en el 73 %: una vez que llega al 75 %, esta página está pasando Core Web Vitals.

Si bien no puede ver los valores históricos de CrUX, puede monitorear esto a lo largo del tiempo. Si llega al 74% mañana, entonces estamos en la dirección correcta (¡sujeto a fluctuaciones!) y podemos esperar alcanzar el mágico 75% pronto. Para los valores que están más alejados, puede verificar periódicamente y ver el aumento , y luego proyectar cuándo podría comenzar a mostrarse como aprobado.

CrUX también está disponible como una API gratuita para obtener cifras más precisas de esos porcentajes. Una vez que se haya registrado para obtener una clave API, puede llamarla con un comando curl como este (reemplazando API_KEY, formFactor y URL según corresponda):

 curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --data '{"formFactor":"PHONE","url":"https://www.example.com"}'

Y obtendrá una respuesta JSON, como esta:

 { "record": { "key": { "formFactor": "PHONE", "url": "https://www.example.com/" }, "metrics": { "cumulative_layout_shift": { "histogram": [ { "start": "0.00", "end": "0.10", "density": 0.99959769344240312 }, { "start": "0.10", "end": "0.25", "density": 0.00040230655759688886 }, { "start": "0.25" } ], "percentiles": { "p75": "0.00" } }, "first_contentful_paint": { ... } } }, "urlNormalizationDetails": { "originalUrl": "https://www.example.com", "normalizedUrl": "https://www.example.com/" } }

Por cierto, si lo anterior lo asusta un poco y desea una forma más rápida de ver estos datos para una sola URL, entonces PageSpeed ​​Insights también devuelve esta precisión que puede ver abriendo DevTools y luego ejecutando su prueba de PageSpeed ​​Insights, y encontrar la llamada XHR que hace:

También hay un explorador de API CrUX interactivo que le permite realizar consultas de muestra de la API CrUX. Sin embargo, para llamar regularmente a la API, obtener una clave gratuita y usar Curl o alguna otra herramienta API suele ser más fácil.

La API también se puede llamar con un "origen", en lugar de una URL, momento en el que proporcionará el valor resumido de todas las visitas a la página de ese dominio. PageSpeed ​​Insights expone esta información, que puede ser útil si su URL no tiene información de CrUX disponible, pero Google Search Console no. Google no ha declarado (¡y es poco probable que lo haga!) exactamente cómo Core Web Vitals afectará la clasificación . ¿La puntuación del nivel de origen afectará las clasificaciones o solo las puntuaciones de URL individuales? O, al igual que PageSpeed ​​Insights, ¿Google volverá a las puntuaciones de nivel originales cuando no existan datos de URL individuales? Es difícil saberlo en este momento y la única pista hasta ahora es esta en las preguntas frecuentes:

P : ¿Cómo se calcula una puntuación para una URL que se publicó recientemente y aún no ha generado 28 días de datos?

R : De forma similar a cómo Search Console informa los datos de experiencia de la página, podemos emplear técnicas como agrupar páginas que son similares y calcular puntuaciones en función de esa agregación. Esto se aplica a las páginas que reciben poco o ningún tráfico, por lo que los sitios pequeños sin datos de campo no deben preocuparse.

La API de CrUX se puede llamar mediante programación, y Rick Viscomi del equipo de Google CrUX creó un monitor de Hojas de cálculo de Google que le permite verificar URL u orígenes de forma masiva, e incluso rastrear automáticamente los datos de CrUX a lo largo del tiempo si desea monitorear de cerca una cantidad de URL u orígenes. . Simplemente clone la hoja, vaya a Tools → Script Editor de secuencias de comandos y luego ingrese una propiedad de secuencia de comandos de CRUX_API_KEY con su clave (esto debe hacerse en el editor heredado), y luego ejecute la secuencia de comandos y llamará a la API CrUX para el dado URL u orígenes y agregue filas al final de la hoja con los datos. Esto se puede ejecutar periódicamente o programar para que se ejecute regularmente.

Utilicé esto para verificar todas las URL de un sitio con un informe Core Web Vitals de actualización lenta en Google Search Console y confirmó que CrUX no tenía datos para muchas de las URL y la mayoría del resto había pasado, por lo que nuevamente muestra que el El informe de Google Search Console está atrasado, incluso de los datos de CrUX en los que se supone que se basa. No estoy seguro de si se debe a URL que fallaron anteriormente pero que ahora no tienen suficiente tráfico para obtener datos actualizados de CrUX que los muestren, o si se debe a otra cosa, pero esto me demuestra que este informe es definitivamente lento .

Sospecho que una gran parte de eso se debe a las URL sin datos en CrUX y la Búsqueda de Google hace todo lo posible para representar un valor para ellos. Por lo tanto, este informe es un excelente lugar para comenzar a obtener una descripción general de su sitio y para monitorear en el futuro, pero no es un excelente informe para trabajar en los problemas en los que desea recibir comentarios más inmediatos.

Para aquellos que quieran profundizar aún más en CrUX, hay tablas mensuales de datos de CrUX disponibles en BigQuery (solo en el nivel de origen, por lo que no para URL individuales) y Rick también ha documentado cómo puede crear un tablero de CrUX basado en eso que puede ser una buena manera de monitorear el rendimiento general de su sitio web a lo largo de los meses.

Otra información sobre los datos de Crux

Entonces, con lo anterior, debe tener una buena comprensión del conjunto de datos CrUX, por qué algunas de las herramientas que lo usan parecen ser lentas y erráticas para actualizar, y también cómo explorarlo un poco más. Pero antes de pasar a las alternativas, hay algunas cosas más que entender sobre CrUX para ayudarlo a comprender realmente los datos que muestra. Así que aquí hay una colección de otra información útil que he recopilado sobre CrUX en relación con Core Web Vitals.

CrUX es solo para Chrome . Todos esos usuarios de iOS y otros navegadores (Desktop Safari, Firefox, Edge... etc.), sin mencionar los navegadores más antiguos (Internet Explorer: ¡apúrate y desvanécete, por favor!) no tienen su experiencia de usuario reflejada en los datos de CrUX y, por lo tanto, en la vista de Google de Core Web Vitals.

Ahora, el uso de Chrome es muy alto (¿aunque quizás no para los visitantes de su sitio?) y, en la mayoría de los casos, los problemas de rendimiento que destaca también afectarán a esos otros navegadores, pero es algo que debe tener en cuenta. Y se siente un poco "repugnante", por decir lo menos, que la posición de monopolio de Google en la búsqueda ahora está alentando a las personas a optimizar para su navegador. Hablaremos a continuación sobre soluciones alternativas para esta vista limitada.

La versión de Chrome que se utilice también tendrá un impacto, ya que estas métricas (CLS en particular) siguen evolucionando y se están detectando y solucionando errores . Esto añade otra dimensión de complejidad a la comprensión de los datos. Ha habido mejoras continuas en CLS en versiones recientes de Chrome, con una redefinición más grande de CLS que aterrizó en Chrome 91. Una vez más, el hecho de que se utilicen datos de campo significa que estos cambios pueden tardar algún tiempo en transmitirse a los usuarios, y luego en los datos de CrUX.

CrUX es solo para usuarios que iniciaron sesión en Chrome , o para citar la definición real:

"[CrUX es] agregado de usuarios que han optado por sincronizar su historial de navegación, no han configurado una frase de contraseña de sincronización y tienen habilitados los informes de estadísticas de uso".

— Informe de la experiencia del usuario de Chrome, Google Developers

Por lo tanto, si está buscando información en un sitio visitado principalmente desde redes corporativas, donde dichas configuraciones están desactivadas por las políticas centrales de TI, es posible que no vea muchos datos, especialmente si esos pobres usuarios corporativos todavía se ven obligados a usar Internet. ¡Explorador también!

CrUX incluye todas las páginas, incluidas aquellas que normalmente no aparecen en la Búsqueda de Google, como "se incluirán páginas no indexadas / robadas / registradas" (aunque hay umbrales mínimos para que una URL y un origen se expongan en CrUX). Ahora, es probable que esas categorías de páginas no se incluyan en los resultados de búsqueda de Google y, por lo tanto, el impacto en el ranking probablemente no sea importante, pero aún se incluirán en CrUX. Sin embargo, el informe Core Web Vitals en Google Search Console parece mostrar solo las URL indexadas , por lo que no aparecerán allí.

La cifra de origen que se muestra en PageSpeed ​​Insights y en los datos sin procesar de CrUX incluirá esas páginas no indexadas y no públicas y, como mencioné anteriormente, no estamos seguros del impacto de eso. Un sitio en el que trabajo tiene un gran porcentaje de visitantes que visitan nuestras páginas de inicio de sesión, y aunque las páginas públicas tenían un gran rendimiento, las páginas de inicio de sesión no lo eran, y eso distorsionó gravemente las puntuaciones de origen de Web Vitals.

La API CrUX se puede usar para obtener los datos de estas URL de inicio de sesión , pero las herramientas como PageSpeed ​​Insights no pueden (ya que ejecutan un navegador real y, por lo tanto, serán redirigidos a las páginas de inicio de sesión). Una vez que vimos los datos de CrUX y nos dimos cuenta del impacto, los arreglamos, y las cifras de origen comenzaron a caer, pero, como siempre, lleva tiempo alimentarlos.

Las páginas no indexadas o iniciadas también suelen ser "aplicaciones", en lugar de colecciones individuales de páginas, por lo que pueden estar utilizando una metodología de aplicación de página única con una URL real, pero muchas páginas diferentes debajo de eso. Esto puede afectar a CLS en particular debido a que se mide durante toda la vida útil de la página (aunque es de esperar que los próximos cambios en CLS ayuden con eso).

Como se mencionó anteriormente, el informe Core Web Vitals en Google Search Console, aunque se basa en CrUX, definitivamente no es la misma información. Como dije anteriormente, sospecho que esto se debe principalmente a que Google Search Console intenta estimar Web Vitals para URL donde no existen datos de CrUX. Las URL de muestra en este informe también están desfasadas con los datos de CrUX.

I've seen many instances of URLs that have been fixed, and the CrUX data in either PageSpeed Insights, or directly via the API, will show it passing Web Vitals, yet when you click on the red line in the Core Web Vitals report and get sample URLs these passing URLs will be included as if they are failing . I'm not sure what heuristics Google Search Console uses for this grouping, or how often it and sample URLs are updated, but it could do with updating more often in my opinion!

CrUX is based on page views . That means your most popular pages will have a large influence on your origin CrUX data. Some pages will drop in and out of CrUX each day as they meet these thresholds or not, and perhaps the origin data is coming into play for those? Also if you had a big campaign for a period and lots of visits, then made improvements but have fewer visits since, you will see a larger proportion of the older, worse data.

CrUX data is separated into Mobile , Desktop and Tablet — though only Mobile and Desktop are exposed in most tools. The CrUX API and BigQuery allows you to look at Tablet data if you really want to, but I'd advise concentrating on Mobile and then Desktop. Also, note in some cases (like the CrUX API) it's marked as PHONE rather than MOBILE to reflect it's based on the form factor, rather than that the data is based on being on a mobile network.

All in all, a lot of these issues are impacts of field (RUM) data gathering, but all these nuances can be a lot to take on when you've been tasked with “fixing our Core Web Vitals”. The more you understand how these Core Web Vitals are gathered and processed, the more the data will make sense, and the more time you can spend on fixing the actual issues, rather than scratching your head wondering why it's not reporting what you think it should be.

Getting Faster Feedback

OK, so by now you should have a good handle on how the Core Web Vitals are collected and exposed through the various tools, but that still leaves us with the issue of how we can get better and quicker feedback. Waiting 21–28 days to see the impact in CrUX data — only to realize your fixes weren't sufficient — is way too slow. So while some of the tips above can be used to see if CrUX is trending in the right direction, it's still not ideal. The only solution, therefore, is to look beyond CrUX in order to replicate what it's doing, but expose the data faster.

There are a number of great commercial RUM products on the market that measure user performance of your site and expose the data in dashboards or APIs to allow you to query the data in much more depth and at much more granular frequency than CrUX allows. I'll not give any names of products here to avoid accusations of favoritism, or offend anyone I leave off! As the Core Web Vitals are exposed as browser APIs (by Chromium-based browsers at least, other browsers like Safari and Firefox do not yet expose some of the newer metrics like LCP and CLS), they should, in theory, be the same data as exposed to CrUX and therefore to Google — with the same above caveats in mind!

For those without access to these RUM products, Google has also made available a Web Vitals JavaScript library, which allows you to get access to these metrics and report them back as you see fit. This can be used to send this data back to Google Analytics by running the following script on your web pages:

 <script type="module"> import {getFCP, getLCP, getCLS, getTTFB, getFID} from 'https://unpkg.com/web-vitals?module'; function sendWebVitals() { function sendWebVitalsGAEvents({name, delta, id, entries}) { if ("function" == typeof ga) { ga('send', 'event', { eventCategory: 'Web Vitals', eventAction: name, // The `id` value will be unique to the current page load. When sending // multiple values from the same page (eg for CLS), Google Analytics can // compute a total by grouping on this ID (note: requires `eventLabel` to // be a dimension in your report). eventLabel: id, // Google Analytics metrics must be integers, so the value is rounded. // For CLS the value is first multiplied by 1000 for greater precision // (note: increase the multiplier for greater precision if needed). eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta), // Use a non-interaction event to avoid affecting bounce rate. nonInteraction: true, // Use `sendBeacon()` if the browser supports it. transport: 'beacon' }); } } // Register function to send Core Web Vitals and other metrics as they become available getFCP(sendWebVitalsGAEvents); getLCP(sendWebVitalsGAEvents); getCLS(sendWebVitalsGAEvents); getTTFB(sendWebVitalsGAEvents); getFID(sendWebVitalsGAEvents); } sendWebVitals(); </script>

Or alternatively, you can include this as an external script instead:

 <script type="module" src="/javascript/send-web-vitals.js"></script>

Now I realize the irony of adding another script to measure the impact of your website, which is probably slow in part because of too much JavaScript, but as you can see above, the script is quite small and the library it loads is only a further 1.7 kB compressed (4.0 kB uncompressed). Additionally, as a module (which will be ignored by older browsers that don't understand web vitals), its execution is deferred so shouldn't impact your site too much, and the data it can gather can be invaluable to help you investigate your Core Web Vital, in a more real-time manner than the CrUX data allows.

The script registers a function to send a Google Analytics event when each metric becomes available. For FCP and TTFB this is as soon as the page is loaded, for FID after the first interaction from the user, while for LCP and CLS it is when the page is navigated away from or backgrounded and the actual LCP and CLS are definitely known. You can use developer tools to see these beacons being sent for that page, whereas the CrUX data happens in the background without being exposed here.

The benefit of putting this data in a tool like Google Analytics is you can slice and dice the data based on all the other information you have in there, including form factor (desktop or mobile), new or returning visitors, funnel conversions, Chrome version, and so on. And, as it's RUM data, it will be affected by real usage — users on faster or slower devices will report back faster or slower values — rather than a developer testing on their high spec machine and saying it's fine.

At the same time, you need to bear in mind that the reason the CrUX data is aggregated over 28 days, and only looks at the 75th percentile is to remove the variance. Having access to the raw data allows you to see more granular data , but that means you're more susceptible to extreme variations. Still, as long as you keep that in mind, keeping early access to data can be very valuable.

Google's Phil Walton created a Web-Vitals dashboard, that can be pointed at your Google Analytics account to download this data, calculate the 75th percentile (so that helps with the variations!) and then display your Core Web Vitals score, a histogram of information, a time series of the data, and your top 5 visited pages with the top elements causing those scores.

Using this dashboard, you can filter on individual pages (using a ga:pagePath==/page/path/index.html filter), and see a very satisfying graph like this within a day of you releasing your fix, and know your fix has been successful and you can move on to your next challenge!:

With a little bit more JavaScript you can also expose more information (like what the LCP element is, or which element is causing the most CLS) into a Google Analytics Custom Dimension. Phil wrote an excellent Debug Web Vitals in the field post on this which basically shows how you can enhance the above script to send this debug information as well, as shown in this version of the script.

These dimensions can also be reported in the dashboard (using ga:dimension1 as the Debug dimension field, assuming this is being sent back in Google Analytics Customer Dimension 1 in the script), to get data like this to see the LCP element as seen by those browsers:

Como dije anteriormente, los productos comerciales de RUM a menudo también expondrán este tipo de datos (¡y más!), pero para aquellos que simplemente se sumergen en el agua y no están listos para el compromiso financiero de esos productos, esto al menos ofrece la primera incursión. en métricas basadas en RUM y lo útiles que pueden ser para obtener esa retroalimentación crucial más rápida sobre las mejoras que está implementando. Y si esto abre su apetito por esta información, definitivamente mire los otros productos de RUM para ver cómo pueden ayudarlo también.

Cuando busque medidas alternativas y productos RUM, recuerde volver a lo que Google está viendo para su sitio, ya que puede ser diferente. ¡Sería una pena trabajar duro en el rendimiento y no obtener todos los beneficios de clasificación al mismo tiempo! Así que esté atento a los gráficos de Search Console para asegurarse de que no se está perdiendo nada.

Conclusión

Los Core Web Vitals son un conjunto interesante de métricas clave que buscan representar la experiencia del usuario al navegar por la web. Como un entusiasta defensor del rendimiento web, agradezco cualquier impulso para mejorar el rendimiento de los sitios y el impacto en la clasificación de estas métricas sin duda ha creado un gran revuelo en las comunidades de rendimiento web y SEO.

Si bien las métricas en sí mismas son muy interesantes, lo que quizás sea más emocionante es el uso de datos de CrUX para medirlas. Básicamente, esto expone los datos RUM a sitios web que nunca antes habían considerado medir el rendimiento del sitio en el campo de esta manera. Los datos RUM son lo que los usuarios realmente están experimentando , en todas sus configuraciones salvajes y variadas, y no hay sustituto para comprender cómo se está desempeñando realmente su sitio web y cómo lo experimentan sus usuarios.

Pero la razón por la que hemos dependido tanto de los datos de laboratorio durante tanto tiempo es porque los datos RUM son ruidosos. Los pasos que toma CrUX para reducir esto ayudan a brindar una vista más estable, pero a costa de que sea difícil ver los cambios recientes.

Con suerte, esta publicación explica de alguna manera las diversas formas de acceder a los datos de Core Web Vitals para su sitio web y algunas de las limitaciones de cada método. También espero que sirva de alguna manera para explicar algunos de los datos que ha estado luchando por comprender, así como para sugerir algunas formas de solucionar esas limitaciones.

¡Feliz optimización!