Cómo evaluar los informes del Vigía

El Vigía monitorea diariamente la velocidad de las páginas medidas de su sitio web en el monitoreo PLUS. Si alguna métrica clave cambia, el Vigía de velocidad le avisará. En este texto, se explica quién y cómo debería evaluar estos informes.

Ha llegado un informe del Vigía de velocidad. ¿Y ahora qué?

Hemos ajustado el Vigía basándonos en nuestra experiencia de consultoría con nuestros clientes y lo utilizamos nosotros mismos, pero aún así, se necesita cierto conocimiento para evaluar sus informes.

Por ejemplo, debido a la naturaleza de las mediciones sintéticas, puede ocurrir que el Vigía envíe una notificación incluso cuando no hay un gran problema en el sitio web.

Sin embargo, con los conocimientos adquiridos en este texto, podrá manejar los informes del Vigía.

¿Cómo funciona el Vigía?#

En pocas palabras, el Vigía opera de la siguiente manera:

• El Vigía recopila datos de mediciones sintéticas. (Vea la diferencia entre los diferentes tipos de mediciones.)
• Cada día, el Vigía prueba todas las URL introducidas en la configuración de la prueba.
• Para cada métrica de velocidad, genera un único valor para todo el sitio web.
• Cada métrica tiene establecidos distintos límites de cambios permitidos.
• Si se supera el límite, recibirá una notificación por correo electrónico o en Slack o Teams.

Más sobre el funcionamiento del Vigía.

Los informes son principalmente para desarrolladores#

Recomendamos que el monitoreo del Vigía sea seguido principalmente por desarrolladores y personas de su equipo que se dediquen diariamente a la velocidad del sitio web. Esto requiere conocimientos técnicos y tiempo.

Para gerentes, especialistas en marketing, UX y otras profesiones similares, tenemos otros informes en el monitoreo PLUS. Por ejemplo, un informe mensual por correo electrónico sobre el estado de la velocidad o un panel de control para el equipo.

Por lo tanto, recomendamos a los gerentes desactivar las notificaciones del Vigía:

En la configuración de correos electrónicos, puede desactivar las notificaciones del Vigía si sus colegas ya están monitoreando los cambios.

¿Cómo evaluar generalmente los informes?#

Si recibe un correo electrónico o una notificación en Slack, sus primeras preguntas para evaluar el informe deberían ser las siguientes:

1. ¿El cambio también afecta a las métricas de los usuarios, es decir, los datos CrUX?
2. ¿Hubo implementaciones de cambios en el sitio web en los días del cambio de la métrica (y son visibles en las notas)?
3. ¿Qué tipos específicos de páginas influyen en este cambio?
4. ¿Es posible ver el cambio en el detalle de la ejecución de la prueba?

¿El cambio afecta a las métricas de los usuarios?#

Los más experimentados ya saben que no todas las métricas son iguales. El Vigía recopila datos de mediciones sintéticas cada día, pero nos interesa su impacto en los datos de los usuarios.

No podemos evaluar los datos de los usuarios (CrUX) diariamente porque tienen un retraso de varias semanas.

Vayamos a la evaluación del cambio en el Vigía. Vaya al informe de Dominio, donde tenemos datos del Chrome UX Report (CrUX). ¿Hay un problema visible en las mismas métricas? Para esto, le serán útiles varias informaciones:

• Es bueno saber que los datos CrUX se calculan de manera acumulativa por casi un mes atrás, por lo que en los datos de dominio puede verse solo un pequeño cambio. Pero incluso eso puede ser sospechoso.
• Además, es importante saber que un cambio en los datos del usuario puede ocurrir hasta tres días después del cambio real en el sitio web.
• Finalmente, no olvide que no todas las métricas obtenidas de los usuarios pueden medirse sintéticamente. Vea las guías para métricas específicas más abajo en este texto. Por ejemplo, la métrica TBT sintética puede (pero no necesariamente) afectar la velocidad de interacción, es decir, INP.

No olvide que los datos de los usuarios (CrUX) se calculan acumulativamente durante los últimos 28 días y pueden tener un retraso de varios días.

Continúe con los siguientes pasos de evaluación solo si observa cambios tanto en el Vigía como en los datos de los usuarios.

Las métricas en el Vigía pueden tener un desarrollo salvaje a veces, pero no las verá en los datos CrUX. En tal caso, no es necesario entrar en pánico y buscar un problema. Lo importante es el desarrollo a largo plazo. Vea también el informe de Dominio.

¿Es un problema cíclico?#

Otro patrón común en los datos es la estacionalidad, por lo que la repetición cíclica de algunos problemas. ¿Cómo se puede ver un problema así?

En el informe del Vigía observe la tendencia a largo plazo (al menos 3 meses). Algunas métricas (como TBT) tienden a empeorar y mejorar cíclicamente.

La estacionalidad de la visita también puede jugar un papel en su caso, lo cual a menudo se refleja, por ejemplo, en la respuesta del servidor, TTFB.

¿Cómo evaluar métricas individuales?#

En la siguiente sección del texto, verá guías específicas para el proceso de métricas individuales. Pueden parecerse entre sí, pero no es del todo cierto. Preste atención a cada métrica individual.

Backend (TTFB)#

El Time To First Byte (TTFB) muestra el tiempo de respuesta del servidor, pero también incluye toda su infraestructura de servidor y la velocidad de conexión de los usuarios.

Es una métrica muy importante, cuyo empeoramiento tendrá un impacto directo en las métricas Core Web Vitals, especialmente en la velocidad de carga (LCP). Debido al crawl budget, es decir, la capacidad de Googlebot para rastrear su sitio web, la métrica TTFB también afecta el SEO.

¿Cómo evaluar informes sobre cambios en el tiempo de respuesta del servidor (TTFB)?

1. ¿Tiene impacto también en las métricas de los usuarios?
   Compare el desarrollo de la métrica en el Vigía con el valor de la métrica TTFB en los usuarios (Informe de “Dominios” > Desarrollo de la distribución de la métrica). Vea la sección ¿Cómo se desarrollan las métricas de los usuarios? arriba.
2. ¿Hubo implementaciones de cambios en el sitio web en los días del cambio de la métrica?
   Las notas en los gráficos pueden ayudarle a marcar implementaciones importantes en el sitio web.
3. ¿Qué tipos específicos de páginas tienen un impacto en este cambio?
   Vea el informe de “Páginas”, donde se muestra el desarrollo de la métrica TTFB para los tipos de páginas individuales de su sitio web. En los datos sintéticos y CrUX verá si el problema afecta todo el sitio web o solo partes específicas.
4. ¿Puede su infraestructura de servidor estar temporalmente bajo mayor carga?
   Durante campañas o en temporada, puede ocurrir un empeoramiento temporal en la respuesta de los servidores. Lo importante es que a largo plazo no se supere el límite óptimo de 0,8 s en los datos de los usuarios.
5. ¿Ve un empeoramiento continuo del TTFB?
   Monitoree los gráficos de consumo de memoria y CPU de su proveedor de hosting. Según nuestra experiencia, la actualización de hardware suele ser subestimada y puede ser la solución.
6. ¿Es posible ver el cambio en el detalle de la ejecución de la prueba?
   Al hacer clic en el gráfico con los resultados de las mediciones sintéticas, accederá al detalle de la ejecución de la prueba con el informe de la herramienta Lighthouse. Compare los resultados con el detalle de la ejecución de la prueba del día anterior. En el informe Lighthouse, también puede encontrar las causas específicas de los problemas y las oportunidades para optimizar esta métrica. Los desarrolladores deberían poder medir los Web Vitals directamente en el navegador, donde también pueden abrir los resultados del detalle de la ejecución de la prueba.

Dedíquese en el equipo a la optimización de la métrica TTFB no solo de forma reactiva cuando surge un problema, sino también de manera continua.

Primer pintado de contenido (FCP)#

La métrica First Contentful Paint (FCP) muestra el tiempo necesario para renderizar el primer contenido en su sitio web.

Es una métrica auxiliar importante, cuyos cambios suelen afectar a la métrica de velocidad de carga (LCP) y a varias métricas de usuario, como la tasa de rebote inmediato.

¿Cómo evaluar los informes sobre cambios en el tiempo de la métrica FCP?

1. ¿Tiene impacto también en las métricas de los usuarios?
   Compare el desarrollo de la métrica en el Vigía con el valor de la métrica FCP en los usuarios (Informe de “Dominios” > Desarrollo de la distribución de la métrica). Vea la sección ¿Cómo se desarrollan las métricas de los usuarios? arriba.
2. ¿Hubo implementaciones de cambios en el sitio web en los días del cambio de la métrica? 
   Las notas en los gráficos pueden ayudarle a marcar implementaciones importantes en el sitio web.
3. ¿Qué tipos específicos de páginas tienen un impacto en este cambio?
   Vea el informe de “Páginas”, donde se muestra el desarrollo de la métrica FCP para los tipos de páginas individuales de su sitio web. En los datos sintéticos y CrUX verá si el problema afecta todo el sitio web o solo partes específicas.
4. ¿El núcleo del problema es medible con otra métrica?
   ¿También cambió en los informes la respuesta del servidor, es decir, la métrica TTFB? La velocidad del backend puede tener un impacto directo en las métricas FCP y LCP, por lo que a menudo encontrará al culpable aquí.
5. ¿El problema está en los recursos críticos y se puede encontrar en los indicadores técnicos?
   ¿Cambió el FCP pero no cambió el TTFB? La diferencia entre estas dos métricas radica en los recursos críticos necesarios para el primer renderizado de la página. Busque los cambios en el informe de “Técnico” y en los valores de indicadores como el volumen de datos HTML, CSS, número de JS bloqueantes... Es posible que haya ocurrido un cambio aquí que causó el empeoramiento del FCP.
6. ¿Es posible ver el cambio en el detalle de la ejecución de la prueba?
   Al hacer clic en el gráfico con los resultados de las mediciones sintéticas, accederá al detalle de la ejecución de la prueba con el informe de la herramienta Lighthouse. Compare los resultados con el detalle de la ejecución de la prueba del día anterior. En el informe Lighthouse, también puede encontrar las causas específicas de los problemas y las oportunidades para optimizar esta métrica. Los desarrolladores deberían poder medir los Web Vitals directamente en el navegador, donde también pueden abrir los resultados del detalle de la ejecución de la prueba.

Dedíquese a la optimización de la métrica FCP no solo de forma reactiva cuando surge un problema, sino también de manera continua.

Pintado del contenido más grande (LCP)#

La métrica Largest Contentful Paint (LCP) muestra el tiempo necesario para renderizar el contenido principal en una página específica de su sitio web.

Es una de las tres métricas más importantes, parte de Core Web Vitals, y un indicador que a menudo correlaciona con la tasa de conversión en sitios de comercio electrónico.

¿Cómo evaluar los informes sobre cambios en el tiempo de la métrica LCP?

1. ¿Tiene impacto también en las métricas de los usuarios?
   Compare el desarrollo de la métrica en el Vigía con el valor de la métrica LCP en los usuarios (Informe de “Dominios” > Desarrollo de la distribución de la métrica). Vea la sección ¿Cómo se desarrollan las métricas de los usuarios? arriba.
2. ¿Hubo implementaciones de cambios en el sitio web en los días del cambio de la métrica? 
   Las notas en los gráficos pueden ayudarle a marcar implementaciones importantes en el sitio web.
3. ¿Qué tipos específicos de páginas tienen un impacto en este cambio?
   Vea el informe de “Páginas”, donde se muestra el desarrollo de la métrica LCP para los tipos de páginas individuales de su sitio web. En los datos sintéticos y CrUX verá si el problema afecta todo el sitio web o solo partes específicas.
4. ¿El núcleo del problema es medible con otra métrica?
   ¿También cambió en los informes la respuesta del servidor, es decir, la métrica TTFB? La velocidad del backend puede tener un impacto directo en las métricas FCP y LCP, por lo que a menudo encontrará al culpable aquí.
   También puede encontrar el problema en los cambios de la métrica FCP, vea arriba. Si no cambió el TTFB, pero sí el FCP y el LCP, significa que el problema estará en el FCP. El culpable puede ser un aumento en el volumen de datos de los recursos críticos.
5. ¿El problema está en los recursos para los elementos LCP y se puede encontrar en los indicadores técnicos?
   Si no observa cambios en las métricas TTFB ni FCP, entonces el problema puede estar en la diferencia entre FCP y LCP, que es causada por la descarga y renderización de los elementos más grandes de la página. Estos a menudo son asíncronos: imágenes, componentes JavaScript, fuentes web y otros. Busque los cambios en el informe de “Técnico” y en los valores de indicadores como el volumen de datos JS, el volumen de datos de fuentes o el volumen de datos de imágenes.
6. ¿Es posible ver el cambio en el detalle de la ejecución de la prueba? Al hacer clic en el gráfico con los resultados de las mediciones sintéticas, accederá al detalle de la ejecución de la prueba con el informe de la herramienta Lighthouse. Compare los resultados con el detalle de la ejecución de la prueba del día anterior. En el informe Lighthouse, también puede encontrar las causas específicas de los problemas y las oportunidades para optimizar esta métrica. Los desarrolladores deberían poder medir los Web Vitals directamente en el navegador, donde también pueden abrir los resultados del detalle de la ejecución de la prueba.

Dedíquese a la optimización de la métrica LCP no solo de forma reactiva cuando surge un problema, sino también de manera continua.

Tiempo total de bloqueo de JS (TBT)#

La métrica Total Blocking Time (TBT) muestra el tiempo total que JavaScript bloquea el navegador y, por lo tanto, puede ralentizar las respuestas a las interacciones del usuario y empeorar la métrica INP.

La métrica de respuesta a las interacciones (INP), que es una parte importante de Core Web Vitals, solo puede medirse en los usuarios (datos CrUX), por lo que el Vigía no puede informar sus cambios.

La métrica TBT es medible sintéticamente, puede indicar un posible empeoramiento del INP, pero no hay una relación directa. Un empeoramiento del TBT puede empeorar el INP, pero el INP puede empeorar sin cambios en el TBT. Por lo tanto, recomendamos seguir tanto los informes del Vigía (TBT) como el desarrollo de los datos de los usuarios (INP).

También es necesario decir que la métrica TBT es la más "volátil" de todas. En el gráfico, los números oscilarán mucho entre valores bajos y altos. El Vigía informa inteligentemente solo de cambios mayores y le recomendamos que haga lo mismo. Simplemente tome la métrica TBT con algo más de "calma" que las demás.

¿Cómo evaluar los informes sobre cambios en el tiempo de la métrica TBT?

1. ¿Tiene impacto también en las métricas de los usuarios?
   Compare el desarrollo de la métrica en el Vigía con el valor de la métrica INP en los usuarios (Informe de “Dominios” > Desarrollo de la distribución de la métrica). Vea la sección ¿Cómo se desarrollan las métricas de los usuarios? arriba.
2. ¿Hubo implementaciones de cambios en el sitio web en los días del cambio de la métrica?
   Las notas en los gráficos pueden ayudarle a marcar implementaciones importantes en el sitio web.
3. ¿Qué tipos específicos de páginas tienen un impacto en este cambio?
   Vea el informe de “Páginas”, donde se muestra el desarrollo de la métrica TBT para los tipos de páginas individuales de su sitio web. En los datos sintéticos verá si el problema afecta todo el sitio web o solo partes específicas. De manera similar, en el mismo informe, podemos tratar el desarrollo de la métrica INP.
4. ¿Qué impacto tienen las componentes de terceros?
   En el informe “Páginas”, también observe el desarrollo de la métrica 3PBT, que muestra la parte del TBT que nuestra automatización ha asignado a las componentes de terceros. Si la proporción de tiempo de bloqueo de terceros es mayor que la mitad, definitivamente preste atención. En el informe “Detalle de la ejecución de la prueba” descubrirá qué terceros específicos son problemáticos aquí.
5. ¿Es posible ver el cambio en el detalle de la ejecución de la prueba?
   Al hacer clic en el gráfico con los resultados de las mediciones sintéticas, accederá al detalle de la ejecución de la prueba con el informe de la herramienta Lighthouse. Compare los resultados con el detalle de la ejecución de la prueba del día anterior. En el informe Lighthouse, también puede encontrar las causas específicas de los problemas y las oportunidades para optimizar esta métrica. Los desarrolladores deberían poder medir los Web Vitals directamente en el navegador, donde también pueden abrir los resultados del detalle de la ejecución de la prueba.

En general, si la métrica INP está bien, pero las métricas TBT o 3PBT han empeorado significativamente, entonces no debe considerar estos cambios como críticos.

Aun así, es bueno dedicar tiempo regularmente a la optimización de la métrica INP, y hacerlo de manera continua, no solo de forma reactiva cuando surge un problema.

Desplazamiento acumulativo del diseño (CLS)#

La métrica Cumulative Layout Shift (CLS) muestra el grado de desplazamientos no deseados del diseño que el usuario experimenta durante la carga y el uso posterior de la página.

Es una métrica importante, una de las tres Core Web Vitals, según las cuales Google evalúa los sitios web para SEO y PPC:

¿Cómo evaluar los informes sobre cambios en el tiempo de la métrica CLS?

1. ¿Tiene impacto también en las métricas de los usuarios?
   Compare el desarrollo de la métrica en el Vigía con el valor de la métrica CLS en los usuarios (Informe de “Dominios” > Desarrollo de la distribución de la métrica). Vea la sección ¿Cómo se desarrollan las métricas de los usuarios? arriba.
2. ¿Hubo implementaciones de cambios en el sitio web en los días del cambio de la métrica? 
   Las notas en los gráficos pueden ayudarle a marcar implementaciones importantes en el sitio web.
3. ¿Qué hacer si los datos CrUX y los datos sintéticos para la métrica CLS difieren mucho?
   Es necesario darse cuenta de que el CLS obtenido por el Vigía (es decir, la medición sintética) puede diferir del CLS obtenido de los datos de los usuarios (CrUX). Mientras que sintéticamente solo se pueden medir los desplazamientos del diseño visibles durante la carga inicial del sitio web, en los datos CrUX vemos “layout shifts” incluso durante el uso posterior de la página. Si ve un bajo CLS en la síntesis pero alto en CrUX, los desplazamientos no deseados no los verá en la carga inicial, sino durante el uso posterior de la página.
4. ¿Qué tipos específicos de páginas tienen un impacto en este cambio?
   Vea el informe de “Páginas”, donde se muestra el desarrollo de la métrica CLS para los tipos de páginas individuales de su sitio web. En los datos sintéticos y CrUX verá si el problema afecta todo el sitio web o solo partes específicas.
5. ¿Es posible ver el cambio en el detalle de la ejecución de la prueba?
   Al hacer clic en el gráfico con los resultados de las mediciones sintéticas, accederá al detalle de la ejecución de la prueba con el informe de la herramienta Lighthouse. Compare los resultados con el detalle de la ejecución de la prueba del día anterior. En el informe Lighthouse, también puede encontrar las causas específicas de los problemas y las oportunidades para optimizar esta métrica. Los desarrolladores deberían poder medir los Web Vitals directamente en el navegador, donde también pueden abrir los resultados del detalle de la ejecución de la prueba.

Dedíquese a la optimización de la métrica CLS no solo de forma reactiva cuando surge un problema, sino también de manera continua.

Resumen#

Evaluar los informes del Vigía de velocidad, junto con el propio monitoreo, es una parte importante del trabajo para mejorar o mantener una buena velocidad del sitio web.

Es importante que el equipo determine quién se encargará de seguir y evaluar los informes y realice esta actividad regularmente. Se necesitan habilidades técnicas y conocimiento de las métricas y del sitio web.

Si aún no lo ha hecho, le recomendamos que aprenda cómo funciona el Vigía y cómo configurar correctamente las notificaciones por correo electrónico o Slack.