Métricas endebles: el estado de la web y los elementos fundamentales de la web [Part 2]

En el Primer comentario En esta serie, hablé sobre cómo relativamente pocas URL en la web están superando actualmente el doble obstáculo requerido para un aumento máximo de clasificación CWV (Core Web Vitals):

Para el cronograma de implementación original de Google en mayo, habríamos tenido un 9% de URL que borraron esta barra. Para agosto de 2021, esto había alcanzado el 14%.

Esto por sí solo puede haber sido suficiente para que Google retrasara, minimizara y diluyera su propia actualización. Pero hay otro problema crítico que creo que puede haber socavado la capacidad de Google para presentar Page Experience como un factor de clasificación importante: métricas endebles.

Métricas endebles

Es un resumen desafiante capturar las frustraciones de millones de experiencias de usuarios dispares con un puñado de métricas simples. Quizás uno imposible. En cualquier caso, las opciones de Google ciertamente no están exentas de peculiaridades. Mi cargo principal es que muchos comportamientos frustrantes del sitio web no solo pasan desapercibidos por las tres nuevas métricas, sino que también se incentivan activamente.

Para ser claros, estoy seguro de que la experiencia medida por CWV está ampliamente correlacionada con una buena experiencia en la página. Pero cuanto más espacio de maniobra hay y cuanto más confusos son los datos, menos peso puede aplicar Google a la experiencia de la página como factor de clasificación. Si me pueden acusar de mantener a Google a un nivel poco realista aquí, entonces lo vería como una cama de su propia creación.

Pintura con contenido más grande (LCP)

Quizás esta sea la más segura de las tres nuevas métricas, ya que es esencialmente un proxy de la velocidad de carga de la página. Específicamente, sin embargo, mide el tiempo necesario para la elemento más grande para terminar de cargar. Ese “elemento más grande” es la parte que plantea todo tipo de problemas.

Eche un vistazo a la página de inicio del Blog de Moz, por ejemplo. Aquí hay una captura de pantalla de un día cercano al lanzamiento original planeado de CWV:

¿Cuál dirías que es el elemento más grande aquí? ¿Quizás las imágenes de los héroes? ¿Los títulos de las publicaciones del blog o los anuncios publicitarios?

Para los datos del mundo real en el conjunto de datos CrUX, por supuesto, el elemento más grande puede variar según el tipo de dispositivo. Pero para un agente de usuario de teléfono inteligente estándar (Moz Pro usa un Moto G4 como su agente de usuario móvil), es el pasaje en la parte superior (“Los mejores magos, médicos y otros expertos de la industria …”). En el escritorio, a veces son los títulos de las páginas, dependiendo de la longitud de los dos títulos más recientes. Por supuesto, eso es parte del problema aquí: debes recordar echar un vistazo con el dispositivo correcto. Pero incluso si lo hace, no es exactamente obvio.

(Si no me cree, puede configurar una campaña para Moz.com en Moz Pro y comprobarlo usted mismo en la función de métricas de rendimiento dentro de la herramienta de rastreo de sitios).

Hay dos razones por las que esto termina siendo una métrica de comparación particularmente inútil.

1. Las páginas tienen estructuras muy diferentes

La importancia del “elemento más grande” varía enormemente de una página a otra. A veces, es un bloque de texto insignificante, como con Moz arriba. A veces es la característica principal real de la página. A veces es una superposición de cookies, como este ejemplo de Ebuyer:

Esto se convierte en una comparación bastante injusta, de manzanas a naranjas, y en muchos casos anima a centrarse en elementos arbitrarios.

2. Fácil manipulación

Cuando los pocos elementos más grandes tienen un tamaño similar (como con Moz arriba), existe un incentivo para hacer que el más rápido sea un poco más grande. Esto no supone una mejora real para la experiencia del usuario, pero mejorará el LCP.

Retardo de la primera entrada (FID)

El retardo de la primera entrada es una métrica mucho menos intuitiva. Esto registra la cantidad de tiempo que se tarda en procesar la primera interacción del usuario (contando los clics en elementos interactivos, pero no se desplaza ni hace zoom) desde que el navegador empieza para procesar esa interacción. Por lo tanto, el tiempo real que se tarda en finalizar el procesamiento es irrelevante: es solo el retraso entre una acción del usuario y el inicio del procesamiento.

Naturalmente, si el usuario intenta hacer clic en algo mientras la página aún se está cargando, este retraso será considerable. Por otro lado, si ese clic ocurre mucho más tarde, es probable que la página esté en una buena posición para responder rápidamente.

El incentivo aquí, entonces, es retrasar el primer clic del usuario. Aunque esto es contrario a la intuición, en realidad puede ser algo bueno, porque nos aleja de tener ventanas emergentes y otros elementos que bloquean el acceso al contenido. Sin embargo, si realmente quisiéramos ser cínicos, entonces podríamos optimizar esta métrica haciendo que los elementos sean más difíciles de hacer clic o inicialmente no interactivos. Al hacer de los elementos de navegación una experiencia más frustrante, ganaríamos tiempo para que la página terminara de cargarse.

Además de esto, vale la pena recordar que la FID no se puede medir en el laboratorio, porque requiere ese elemento humano. En cambio, Moz Pro y otras suites de laboratorio (incluida la de Google) utilizan el tiempo de bloqueo total, que está más cerca de aproximarse a lo que sucedería si un usuario intentara hacer clic en algo inmediatamente.

En general, creo que esta métrica no es una comparación tan injusta como la pintura con contenido más grande, porque jugar con el sistema aquí es un poco más un tiro en el propio pie. Todavía potencialmente una comparación injusta, en el sentido de que las páginas de navegación tendrán más dificultades que las páginas de contenido (porque en una página de navegación, hub o de categoría, los usuarios quieren hacer clic muy pronto). Pero se podría argumentar que las páginas de navegación son peores resultados de búsqueda de todos modos, por lo que quizás, darle a Google una porción XXL del beneficio de la duda, eso podría ser deliberado.

Cambio de diseño acumulativo (CLS)

Y, por último, está el Cambio de diseño acumulativo, otra métrica que parece intuitivamente buena: todos odiamos cuando las páginas se desplazan mientras intentamos leer o hacer clic en algo. El diablo, sin embargo, está una vez más en los detalles, porque CLS registra el cambio máximo en una ventana de “sesión” de 5 segundos.

Ignorando el problema con el uso de la palabra “sesión” que no tiene nada que ver con la definición de Google de la misma palabra en otros contextos, el problema aquí es que algunos de los peores infractores de una experiencia web discordante en realidad no se registran en esta métrica.

A saber:

1. Los anuncios a mitad de artículo, las inserciones en redes sociales, etc., a menudo se encuentran en la mitad inferior de la página, por lo que no tienen ningún impacto.

2. Las ventanas emergentes molestas y similares a menudo llegan después de un retraso, por lo que no durante la ventana de 5 segundos. (¡Y, en cualquier caso, se puede configurar para que no cuente para el cambio de diseño!)

A MozCon a principios de este año, Compartí este ejemplo de The Guardian, que tiene un impacto cero en su (bastante buena) puntuación CLS:

Entonces, en el mejor de los casos, esta métrica ignora a los peores infractores del tipo de mala experiencia que seguramente está tratando de capturar. Y en el peor de los casos, nuevamente podría incentivar un comportamiento que sea activamente malo. Por ejemplo, podría retrasar algún elemento molesto de mi página para que llegue fuera de la ventana inicial de 5 segundos. Esto lo haría aún más molesto, pero mejora mi puntuación.

¿Qué sigue?

Como mencioné en la primera parte, Google ha sido un poco vacilante y tímido con el lanzamiento de Core Web Vitals como factor de clasificación, y problemas como los que he cubierto aquí podrían ser parte de la razón. En el futuro, deberíamos esperar que Google siga ajustando estas métricas y agregue otras nuevas.

De hecho, los propios Google dijo el pasado mes de mayo que planearon incorporar más señales anualmente, y que se están mejorando las métricas de capacidad de respuesta discutido abiertamente. En última instancia, esto significa que no debe intentar optimizar en exceso o manipular cínicamente las métricas actuales; es probable que sufra por ello en el futuro.

Como mencioné en el primer artículo de esta serie, si tiene curiosidad acerca de cuál es su posición para los umbrales de CWV de su sitio hoy, Moz tiene una herramienta para ello actualmente en versión beta con el lanzamiento oficial a finales de este año.

¡Regístrese en Moz Pro para acceder a la versión beta!

¿Ya es cliente de Moz Pro? ¡Inicie sesión para acceder a la versión beta!

En la tercera y última parte de esta serie, cubriremos el impacto de CWV en las clasificaciones hasta ahora, para que podamos ver juntos cuánta atención prestar a las diversas equivocaciones del “desempate”.