En un par de meses, el sitio web de noticias líder del Reino Unido logró mejorar su CLS del percentil 75 en un 250%, de 0.25 a 0.1.
El desafío de la estabilidad visual
Los cambios de diseño pueden ser muy disruptivos. En Telegraph Media Group (TMG), la estabilidad visual es particularmente importante porque los lectores usan nuestras aplicaciones de forma predominante para consumir noticias. Si el diseño cambia mientras se lee un artículo, es probable que el lector pierda el lugar en el que se encontraba. Esto puede ser una experiencia frustrante y distraída.
Desde una perspectiva de ingeniería, garantizar que las páginas no se muevan ni interrumpan al lector puede ser un desafío, en especial cuando las áreas de tu aplicación se cargan de forma asíncrona y se agregan a la página de forma dinámica.
En TMG, tenemos varios equipos que contribuyen con código del cliente:
- Ingeniería principal. Implementar soluciones de terceros para potenciar áreas como las recomendaciones de contenido y los comentarios
- Marketing. Ejecutamos pruebas A/B para evaluar cómo nuestros lectores interactúan con las funciones o los cambios nuevos.
- Publicidad. Administrar solicitudes de anuncios y ofertas previas a la publicación de anuncios
- Editorial. Incorporar código en artículos, como tweets o videos, así como widgets personalizados (por ejemplo, un rastreador de casos de coronavirus)
Puede ser difícil garantizar que cada uno de estos equipos no haga que el diseño de la página se vea afectado. Con la métrica Cambio de diseño acumulativo para medir la frecuencia con la que ocurre para nuestros lectores, los equipos obtuvieron más información sobre la experiencia real del usuario y un objetivo claro al que aspirar. Esto generó que nuestro CLS del percentil 75 mejorara de 0.25 a 0.1 y que nuestro bucket de aprobación aumentara del 57% al 72%.
250%
Mejora del CLS en el percentil 75
15%
Más usuarios con una buena puntuación de CLS
Dónde comenzamos
Con los paneles de CrUX, pudimos establecer que nuestras páginas se desplazaban más de lo que nos gustaría.
Lo ideal sería que al menos el 75% de nuestros lectores tuviera una experiencia “buena”, por lo que comenzamos a identificar las causas de la inestabilidad del diseño.
Cómo medimos los cambios de diseño
Usamos una combinación de Herramientas para desarrolladores de Chrome y WebPageTest para ayudar a reconocer qué causaba que el diseño cambiara. En DevTools, usamos la sección Experiencia de la pestaña Rendimiento para destacar instancias individuales de cambio de diseño y cómo contribuyeron a la puntuación general.
WebPageTest destaca de forma útil dónde se produce el cambio de diseño en la vista de línea de tiempo cuando se selecciona "Destacar cambios de diseño".
Después de revisar cada cambio en nuestras plantillas más visitadas, elaboramos una lista de ideas sobre cómo podríamos mejorar.
Cómo reducir los cambios de diseño
Nos enfocamos en cuatro áreas en las que podíamos reducir los cambios de diseño: - Anuncios - Imágenes - Encabezados - Elementos incorporados
Anuncios
Los anuncios se cargan después de la pintura inicial a través de JavaScript. Algunos de los contenedores en los que se cargaron no tenían ninguna altura reservada.
Aunque no conocemos la altura exacta, podemos reservar espacio con el tamaño de anuncio más común cargado en el espacio.
En algunos casos, subestimamos la altura promedio del anuncio. En el caso de los lectores de tablets, la ranura se contraía.
Volvimos a revisar la ranura y ajustamos la altura para usar el tamaño más común.
Imágenes
Muchas de las imágenes del sitio web se cargan de forma diferida y tienen su espacio reservado.
Sin embargo, las imágenes intercaladas en la parte superior de los artículos no tenían ningún espacio reservado en el contenedor ni atributos de ancho y alto asociados con las etiquetas. Esto hizo que el diseño cambiara a medida que se cargaba.
Simplemente, agregar los atributos de ancho y altura a las imágenes aseguró que el diseño no cambiara.
Encabezado
El encabezado estaba debajo del contenido en el marcado y se posicionó en la parte superior con CSS. La idea original era priorizar la carga del contenido antes de la navegación, pero esto hizo que la página cambiara momentáneamente.
Mover el encabezado a la parte superior del marcado permitió que la página se renderizara sin este cambio.
Incorporaciones
Algunos de los elementos incorporados de uso frecuente tienen una relación de aspecto definida. Por ejemplo, los videos de YouTube. Mientras se carga el reproductor, extraemos la miniatura de YouTube y la usamos como marcador de posición mientras se carga el video.
Cómo medir el impacto
Pudimos medir el impacto a nivel de la función con bastante facilidad con las herramientas que se mencionaron al comienzo del artículo. Sin embargo, queríamos medir los CLS a nivel de la plantilla y del sitio. De manera sintética, usamos SpeedCurve para validar los cambios en la etapa de preproducción y producción.
Luego, podemos validar los resultados en nuestros datos de RUM (proporcionados por mPulse) una vez que el código llegue a producción.
Verificar los datos de RUM nos brinda un buen nivel de confianza en que los cambios que realizamos tienen un impacto positivo para nuestros lectores.
Las cifras finales que analizamos corresponden a los datos de RUM que recopila Google. Esto es especialmente relevante ahora, ya que pronto tendrán un impacto en la clasificación de la página. Para empezar, usamos el Informe de UX de Chrome, tanto en los datos mensuales a nivel del origen disponibles a través del panel de CrUX como a través de consultas a BigQuery para recuperar datos históricos del p75. De esta manera, pudimos ver fácilmente que, para todo el tráfico medido por CrUX, nuestro CLS del percentil 75 mejoró un 250%, de 0.25 a 0.1, y nuestro bucket de aprobación aumentó del 57% al 72%.
Además, pudimos usar la API de Chrome UX Report y crear algunos paneles internos divididos en plantillas.
Cómo evitar regresiones de CLS
Un aspecto importante para realizar mejoras de rendimiento es evitar las regresiones. Configuramos algunos presupuestos de rendimiento básicos para nuestras métricas clave y, además, incluimos la CLS en ellos.
Si la prueba supera el presupuesto, se enviará un mensaje a un canal de Slack para que podamos investigar la causa. También configuramos informes semanales para que, incluso si las plantillas se mantienen dentro del presupuesto, podamos detectar cualquier cambio que haya tenido un impacto negativo.
También planeamos expandir nuestros presupuestos para usar datos de RUM y datos sintéticos, con mPulse para configurar alertas estáticas y, posiblemente, detección de anomalías, que nos informaría sobre cualquier cambio fuera de lo común.
Es importante que abordemos las funciones nuevas teniendo en cuenta el CLS. Muchos de los cambios que mencioné son los que tuvimos que corregir después de que se lanzaron a nuestros lectores. La estabilidad del diseño será una consideración para el diseño de la solución de cualquier función nueva en el futuro, de modo que podamos evitar cualquier cambio de diseño inesperado desde el principio.
Conclusión
Las mejoras que realizamos hasta el momento fueron bastante fáciles de implementar y tuvieron un impacto significativo. Muchos de los cambios que describí en este artículo no tardaron mucho en implementarse y se aplicaron a todas las plantillas más usadas, lo que significa que tuvieron un impacto positivo generalizado para nuestros lectores.
Aún hay áreas del sitio que debemos mejorar. Estamos explorando formas en las que podríamos hacer más de nuestra lógica del cliente del servidor, lo que mejorará aún más el CLS. Seguiremos haciendo un seguimiento y supervisando nuestras métricas con el objetivo de mejorarlas constantemente y brindar a nuestros lectores la mejor experiencia del usuario posible.