Medición de la velocidad web para marketers paso a paso

Medir la velocidad de un sitio web es una tarea algo engañosa que, además, evoluciona bastante, como lo demuestra la reciente implementación de la evaluación de Google llamada Page Experience.

Quienes no se dedican plenamente al campo de la "performance web" – como marketers, gerentes o diseñadores – a menudo caen en la trampa de utilizar herramientas inadecuadas en fases incorrectas de la medición.

El 7 de abril tuve la oportunidad de hablar sobre esto en la conferencia SEO Restart. A continuación, te transmito la idea principal: mostrar el procedimiento más sencillo para obtener datos de velocidad y la forma recomendada de comunicarlos a los desarrolladores.

Aquí mostraré capturas de pantalla de nuestro tester de velocidad versión 3.0, que recientemente hemos ampliado para incluir cuentas de usuario y la posibilidad de monitorear múltiples sitios web de tus clientes, incluso junto a tus colegas.

Como ejemplo, he tomado el dominio Mall.cz, que aunque no es uno de nuestros clientes, es interesante por su tamaño y la diversidad de sus tipos de páginas. Puedes realizar un test público de velocidad de Mall en pagespeed.one/app/r/73f8e7b84404.

Ciclo de trabajo en la velocidad web#

Debemos empezar un poco amplios, con el proceso general de trabajo en la velocidad.

Google define el proceso en sus materiales como un ciclo de tres pasos. Primero recolectamos datos, luego optimizamos y finalmente monitoreamos, porque generalmente algo vuelve a fallar pocas semanas después de las optimizaciones.

Permíteme simplificar ese proceso en dos pasos:

1. Optimización (generalmente manejada por los desarrolladores).
2. Datos y monitoreo (también conocido como recopilación de datos a lo largo del tiempo – pueden manejarlo los desarrolladores, pero generalmente lo realiza alguien con un enfoque más analítico, que ve el proyecto de forma más general y "desde arriba").

En el marco de los servicios del equipo PageSpeed.ONE, trabajamos en la intersección de ambos – vigilamos los datos y, al mismo tiempo, proporcionamos a los desarrolladores oportunidades de optimización concretas.

Google Page Experience y páginas, grupos, dominios#

Para los no iniciados, recordaré que la velocidad del sitio web se evalúa mediante las métricas Core Web Vitals dentro de un conjunto de señales de evaluación que Google ha denominado Page Experience.

Se trata de datos del Chrome UX Report (CrUX), es decir, de usuarios específicos de tu web, no de datos de pruebas con herramientas como Lighthouse o PageSpeed Insights.

Los datos de los usuarios que necesitas los verás, por ejemplo, en Google Search Console:

Para el proceso mencionado en el artículo, es crucial saber que existen tres niveles de evaluación de Web Vitals:

• URL específica – las direcciones más visitadas tienen su propia evaluación.
• Grupo de páginas – si la URL no tiene datos propios de Core Web Vitals, Google utiliza un grupo para la evaluación. Por ejemplo, en un e-commerce, podría ser un grupo con el detalle del producto.
• Dominio – si la URL no tiene una evaluación propia ni pertenece a un grupo, Google utiliza los datos del dominio completo para su evaluación.

En todos los casos, Google calcula el percentil 75 de los valores de las métricas Core Web Vitals de todas las visitas de los últimos 28 días de forma acumulativa. Estos son los datos que luego ves en todas las herramientas que utilizan CrUX como fuente de datos, incluido nuestro tester en pagespeed.one.

Originalmente pensaba que casi todas las URL estaban al menos clasificadas en un grupo de páginas, pero la realidad parece ser diferente.

En nuestros clientes, veo que la evaluación para URL tiene siempre como máximo solo unas pocas decenas de direcciones, en sitios menos visitados, más bien unas pocas. La evaluación para el grupo, que solo se puede ver en Search Console, tiene para nuestros clientes aproximadamente solo la mitad de las URL.

Existen también extremos, grandes sitios como Livesport.cz, en los cuales hasta el 90% de las URL pueden heredar la evaluación del dominio. Esto lo deduzco de la diferencia entre la cantidad total de URL que Google conoce y la cantidad de URL clasificadas en grupos de páginas en los reportes de Web Vitals dentro de Google Search Console.

Primer paso: medición del dominio#

Al medir la velocidad, siempre comenzamos observando los datos para todo el dominio. Es la expresión más sencilla (aunque un poco simplificada) del estado de la velocidad del sitio web.

Por supuesto, puedes mirar en PageSpeed Insights y allí verás el estado de Web Vitals para el dominio:

Ya desde estos números y gráficos vemos la métrica que necesita más optimización. En mall.cz se trata de CLS (Cumulative Layout Shift).

PageSpeed Insights muestra los datos correctos, es decir, los valores de las métricas para los usuarios acumulados durante el mes del Chrome UX Report. Pero el problema es que no vemos el desarrollo en comparación con el período anterior y que no podemos ver varias dominios a la vez.

Por eso, en nuestro tester, hemos introducido un dashboard, donde tras iniciar sesión, puedes monitorizar los números de todos los sitios de tus clientes, por ejemplo:

En la imagen de arriba, se puede ver que en el móvil el dominio mall.cz no solo no cumple con CLS (el valor es 0,13), sino que también ha empeorado en el último mes.

Sabemos entonces qué está mal, y si seguimos los números regularmente, también sabremos si han cambiado recientemente. Pero, ¿qué pasa si solo podemos medir la velocidad una vez cada varios meses?

Aquí es donde nos puede ser útil otra característica de nuestro tester: los datos mensuales del Chrome UX Report:

Google proporciona estos números con retraso y tienen valores un poco diferentes a los datos de los últimos 28 días, según los cuales evalúa las páginas. Pero son excelentes para mostrar la evolución de la velocidad y, por tanto, el impacto de las optimizaciones o, ehm, del desarrollo no óptimo.

En el gráfico de arriba, se ve que mall.cz tenía hace un año valores muy malos de las métricas LCP y CLS, pero ahora la situación es considerablemente mejor. El valor "verde" de CLS en marzo confirma que hasta hace poco esta métrica estaba bien en móvil para todo el dominio mall.cz.

Probablemente, algo poco agradable ha sucedido con el Cumulative Layout Shift en móvil solo en el último mes.

Con este conocimiento del estado de las métricas para el dominio, podríamos darnos por satisfechos, pero aún te recomiendo una vista desde la indispensable Google Search Console.

Search Console en la parte de Page Experience muestra un gráfico con el número de URL que cumplen con las señales de evaluación de esta área. Es decir, además de la velocidad, también la usabilidad en móviles o el nivel de seguridad, que es aquel recientemente "hypeado" en la comunidad SEO HTTPS.

En el caso del gráfico de arriba, hubo una mejora para el cliente gracias a nuestras optimizaciones y durante un solo día los valores saltaron de cero a cien por ciento. Pero tendrías que tener suerte para ver un gráfico así. La mayoría de las veces es más "dentado", los valores cambian mucho con el tiempo.

Este gráfico, además, está fuertemente sujeto a diversas distorsiones – tanto desde el punto de vista del retraso de los datos como desde el punto de vista de varios errores en el lado de Google. Por eso, tomamos principalmente el desarrollo a largo plazo de él y no entramos en pánico ante fluctuaciones diarias.

Recapitulemos lo que sabemos: el dominio mall.cz tiene un mal valor de la métrica CLS tanto en móvil como en escritorio. Además, en móvil, ha habido un empeoramiento significativo en el último mes.

Paso dos: grupos de páginas#

En esta fase de la medición, prácticamente no podemos prescindir de Search Console. Google no proporciona estos datos externamente a través de su API. Espero que esto sea solo temporal y pronto sea posible trabajar con ellos de manera razonable desde el exterior.

De todas formas, lo que voy a mostrarte ahora es visible en la sección Web Vitals. Allí están disponibles los reportes divididos para móvil y escritorio. Y todos ellos se refieren precisamente a los grupos de páginas, tal como los ha dividido internamente Google.

En el primer paso, vemos un gráfico algo confuso con líneas amarillas, naranjas y verdes:

El problema con este gráfico es que no muestra el desarrollo de la velocidad del sitio, sino solo el número de URL en los grupos que cumplen con todas las métricas (verde) o tienen al menos una naranja o al menos una roja.

Dado que se trata del número de URL, los gráficos pueden parecer empeorar, incluso si, por ejemplo, está aumentando el número de direcciones que están clasificadas en algún grupo de URL. Sin embargo, en realidad, nada está empeorando, solo aumenta el número de páginas.

Malo es, sin embargo, si en algún momento disminuye el verde y aumenta el naranja o el rojo. Eso podría ser motivo de preocupación por la velocidad.

Por supuesto, también para estos gráficos se aplica que hay diversas distorsiones, retrasos y quién sabe qué más... Simplemente es bueno tener otras mediciones regulares que te verifiquen si realmente ha habido un cambio brusco.

Cuando abres el gráfico, ya ves un desglose para dispositivos específicos y métricas específicas:

Este gráfico nos muestra qué métricas son problemáticas en el dominio dentro de los grupos y a cuántas URL afecta.

En el caso de este gráfico en particular, es la métrica LCP y los valores naranjas (2,5 – 4 s). Si tuviéramos acceso a Search Console en Mall.cz, probablemente veríamos problemas principalmente con CLS.

También puedes abrir este reporte aún más hasta llegar al quid de la cuestión, es decir, una lista de grupos de URL que tienen este valor de la métrica:

En la imagen de arriba, he ocultado las direcciones URL específicas, pero seguro que puedes imaginarlas allí.

Este es un excelente reporte porque, además de los grupos de páginas, también nos revela su frecuencia y "valor agregado de la métrica". Cuanto más representado esté el grupo y cuanto peor sea su valor métrico, más importante es su optimización.

Google Search Console también proporciona muchos ejemplos de URL aquí, por lo que podemos tomarlos directamente y probarlos en el navegador o configurarlos para un monitoreo regular, lo cual haremos en el siguiente paso.

En el segundo paso, hemos descubierto qué grupos de páginas tienen el mayor impacto en la mala métrica (en el caso de Mall.cz sería CLS) y, por lo tanto, su optimización es prioritaria.

Paso tres: URL específicas#

La selección de las URL correctas que monitoreas es clave para el éxito de toda la medición de velocidad. Tengo algunos consejos para ti:

• Encuentra las páginas tipo que son clave para ti y representan contenido importante. Por ejemplo, en un e-commerce podría ser la homepage, el detalle del producto, la categoría, el post del blog y quizás la página de contacto.
• Elige representantes de los grupos de direcciones frecuentes que te ofrece Search Console.
• Selecciona las URL que tienen la mayor cantidad de visitas de este grupo.
• Elige idealmente páginas con evaluación propia de Web Vitals en CrUX.

Nuestro tester permite introducir hasta cinco URL, lo cual debería ser suficiente incluso para sitios grandes. En el caso de Mall.cz, será un poco al azar (no tenemos todos los datos), pero seleccionamos estas páginas:

En la imagen del test, vemos que el CLS problemático está principalmente en la categoría (/mobilni-telefony) y luego en la página /akce. También vemos un mal valor en la homepage, pero esta es solo una, por lo que no tendrá tanto impacto en la evaluación del dominio. Aunque debemos optimizarla, no es prioritario.

Monitoreo regular#

Una vez que tenemos estas direcciones configuradas en el tester, se medirán regularmente, en nuestro caso, una vez al día. Es un servicio que ofrecemos de forma gratuita, así que no dudes en utilizarlo.

El gráfico de monitoreo diario se ve algo así:

En el gráfico, se puede ver que en una de las páginas del cliente la métrica LCP empeoró. Sucedió a principios de febrero, y así podemos rastrear más fácilmente la causa. (En este caso, está fallando la barra de cookies.)

Así que, además de la vista a largo plazo de los dominios y grupos de páginas, ahora monitoreamos diariamente URL específicas. Podemos llegar a las métricas problemáticas, pero también a la fecha de sus cambios bruscos a peor, por lo tanto, a la causa probable.

Resultado de la medición del sitio web#

Ahora tenemos medidas la dominación, los grupos de páginas, pero también URL específicas. Por lo tanto, puedes proporcionar a los desarrolladores este resumen muy breve para la optimización:

En el dominio mall.cz, la métrica problematica es CLS:
En CrUX, los valores para móvil son 0,13, para escritorio 0,26.

Los grupos más importantes para optimizar y ejemplos de URL son estos:
…

Enlaces a las mediciones:
Search Console: …
PageSpeed.ONE: …
PageSpeed Insight: …

Sí, así de simple podría ser.

Ahora solo falta idear cómo solucionarlo, ¿verdad...?

¿Deberían los marketers intentar proporcionar recomendaciones a los desarrolladores?#

Creo que la mayoría de los marketers entienden bien los datos y su interpretación, pero no tienen un conocimiento tan profundo del funcionamiento del navegador o de las diversas tecnologías frontend.

Existen consejos generales, como los que da Lighthouse o también PageSpeed Insights, pero estos pueden funcionar bien solo en algunos sitios, generalmente en aquellos que no están bien optimizados.

Es necesario darse cuenta de que Lighthouse no conoce el contexto humano y tecnológico de tu proyecto, por lo que ciertos consejos pueden estar completamente fuera de lugar.

Desde nuestra experiencia, también es cierto que los consejos de Lighthouse suelen ser muy difíciles de implementar. El objetivo de la optimización debería ser buscar "frutas al alcance de la mano", es decir, ajustes que ofrezcan el mayor efecto por el menor costo.

Tales ajustes deberían poder encontrarlos los desarrolladores que trabajan en el proyecto. Sin embargo, cada vez más, vemos en los clientes que la capacidad de un desarrollo de calidad y eficaz y la capacidad de optimizar la velocidad parecen ser casi excluyentes.

Por supuesto, puedes tener la suerte de que tus desarrolladores se encarguen del rendimiento por completo (¡conocemos casos así!) o puedes tener aún más suerte y que estos conocimientos los tenga tu marketer, diseñador o product manager (también conocemos casos así).

En caso contrario, simplemente contáctanos, estaremos encantados de ayudarte. ;)

Etiquetas:SEOMeasurement