Cómo mejorar el Cambio de diseño acumulado en Telegraph Media Group

En un par de meses, el sitio web de noticias líder del Reino Unido logró mejorar su CLS de percentil 75 en un 250%, de 0.25 a 0.1.

Chris Boakes

El desafío de estabilidad visual

Los cambios de diseño pueden ser muy molestos. En Telegraph Media Group (TMG), la estabilidad visual es particularmente importante porque los lectores usan principalmente nuestras aplicaciones para consumir noticias. Si el diseño cambia mientras lee un artículo, es probable que el lector pierda su lugar. Esta puede ser una experiencia frustrante y que distraiga a los usuarios.

Desde una perspectiva de ingeniería, asegurarse de que las páginas no cambien ni interrumpan al lector puede ser un desafío, especialmente cuando áreas de tu aplicación se cargan de forma asíncrona y se agregan a la página de forma dinámica.

En TMG, contamos con varios equipos que contribuyen a la generación de código del cliente:

  • Ingeniería básica. Implementar soluciones de terceros para potenciar áreas como los comentarios y las recomendaciones de contenido
  • Marketing. Ejecutar pruebas A/B para evaluar cómo interactúan los lectores con las funciones o los cambios nuevos
  • Publicidad. Administrar las solicitudes y ofertas previas de anuncios
  • Requisitos editoriales. Incorporar código en artículos como tweets o videos, así como widgets personalizados (por ejemplo, la herramienta de seguimiento de casos de coronavirus)

Garantizar que cada uno de estos equipos no provoque que el diseño de la página se sacude puede ser difícil. Mediante el uso de la métrica Cambio de diseño acumulado para medir la frecuencia con la que se produce a nuestros lectores, los equipos obtuvieron más estadísticas sobre la experiencia real del usuario y un objetivo claro por el cual esforzarse. Esto dio como resultado que el CLS del percentil 75 mejorara de 0.25 a 0.1 y que nuestro bucket de aprobación creciera del 57% al 72%.

El 250%

Mejora del CLS en el percentil 75

15%

Más usuarios con una buena puntuación de CLS

Donde comenzamos

Con los paneles de CrUX, pudimos establecer que nuestras páginas cambiaban más de lo que queríamos.

El panel de CrUX muestra entre un 55% y un 60% de buenos resultados, un 15% necesita mejoras y un 25% de puntuaciones bajas.
Nuestras puntuaciones de Cambio de diseño acumulado entre junio de 2020 y febrero de 2021.

Idealmente, queríamos que al menos el 75% de nuestros lectores tuvieran una "buena" experiencia, 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 Chrome DevTools y WebPageTest para ayudar a reconocer la causa del cambio del diseño. En Herramientas para desarrolladores, 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.

La página principal de Telegraph con un anuncio en el encabezado, destacado con una superposición azul.
Se identifica un cambio de diseño causado por la carga de anuncios del lado del cliente sobre el encabezado en la sección Experiencia de las Herramientas para desarrolladores de Chrome.

WebPageTest destaca de manera útil dónde se produce el cambio de diseño en la vista de cronograma cuando se selecciona "Destacar cambios de diseño".

Vista de tira de película de WebPageTest del sitio web de Telegraph con el Layoutshift destacado con una superposición roja.
WebPageTest destaca dónde cambió el diseño.

Después de revisar cada turno en las plantillas más visitadas, se nos ocurrió 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 podríamos reducir los cambios de diseño: - anuncios - imágenes - encabezados - incorporaciones

Anuncios

Los anuncios se cargan después del procesamiento de imagen inicial a través de JavaScript. Algunos de los contenedores en los que cargaron no tenían ninguna altura reservada.

Animación del sitio web de Telegraph. La lista de historias se desplaza hacia abajo cuando se carga un anuncio encima de ella.
El bloque "Más historias" debajo del anuncio se desplaza hacia abajo después de que se carga el anuncio.

Aunque no sabemos la altura exacta, podemos reservar espacio mediante el tamaño de anuncio más común cargado en el espacio.

Animación del sitio web de Telegraph. Se coloca un rectángulo de marcador de posición para el anuncio sobre la lista de historias. El anuncio se carga en lugar del marcador de posición sin provocar un cambio de diseño.
Al reservar espacio para el anuncio, el bloque "Más historias" que aparece a continuación permanece estático antes y después de que se cargue el anuncio.

En algunos casos, habíamos juzgado erróneamente la altura promedio del anuncio. Para los lectores de tablets, la ranura se estaba contrayendo.

Animación que muestra la vista para tablets del sitio web de Telegraph. El espacio del marcador de posición es más grande que el anuncio, por lo que el contenido cambia hacia arriba después de que se carga el anuncio.
El espacio publicitario que se contrae después de que se carga para los lectores en dispositivos del tamaño de una tablet.

Revisamos el espacio y ajustamos la altura para usar el tamaño más común.

Animación que muestra la vista para tablets del sitio web de Telegraph. Como el marcador de posición coincide con el tamaño del anuncio, no se produce un cambio de diseño cuando se carga el anuncio.
Asegurarse de que el espacio que reservamos para el espacio publicitario coincidiera con la altura del anuncio que se publica con más frecuencia.

Imágenes

Muchas de las imágenes del sitio web se cargan de forma diferida y tienen su espacio reservado para ellas.

Animación de las tarjetas de vista previa de artículos cargando.
Carga diferida de imágenes sin interrumpir el diseño.

Sin embargo, las imágenes intercaladas en la parte superior de los artículos no tenían espacio reservado en el contenedor ni tenían atributos de ancho y alto asociados con las etiquetas. Esto provocó que el diseño cambiara a medida que se cargaran.

Animación de la carga de la página del artículo. Cuando la imagen principal se carga en la parte superior de la página, el texto se mueve hacia abajo.
Un cambio de diseño causado por la imagen principal del artículo.

Simplemente agregar los atributos de ancho y alto a las imágenes garantizó que no se cambiara el diseño.

Animación de la carga de la página del artículo con el marcador de posición reservado para la imagen principal. Cuando la imagen principal se carga en la parte superior de la página, no se produce un cambio de diseño.
La imagen del artículo principal se carga sin cambiar el diseño.

El encabezado estaba debajo del contenido en el lenguaje de marcado y se colocó en la parte superior con CSS. La idea original era priorizar la carga del contenido antes de la navegación, pero esto hacía que la página se cambiara temporalmente.

ALT_TEXT_HERE
El encabezado de la página que se carga de manera poco elegante.

Mover el encabezado a la parte superior del lenguaje de marcado permitió que la página se renderice sin este cambio.

ALT_TEXT_HERE
El encabezado de la carga de la página ya no interrumpe el diseño.

Incorporaciones

Algunas de las incorporaciones 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.

La ranura del reproductor de video que carga una miniatura de baja resolución mientras se carga el reproductor de video.
La ranura del reproductor de video carga una miniatura de baja resolución mientras se carga el reproductor de video.

Medición del impacto

Pudimos medir el impacto a nivel del atributo con bastante facilidad mediante las herramientas mencionadas al comienzo del artículo. Sin embargo, queríamos medir la métrica CLS a nivel de plantilla y del sitio. De manera sintética, usamos SpeedCurve para validar los cambios en la preproducción y la producción.

Gráfico de SpeedCurve que muestra una caída pronunciada en la puntuación de CLS.
Cómo hacer un seguimiento del progreso de CLS de forma sintética con SpeedCurve.

Luego, podemos validar los resultados en los datos de RUM (proporcionados por mPulse) una vez que el código alcanza la producción.

Gráfico de mPulse en el que se muestra una disminución en la puntuación de CLS.
Validación de las mejoras de CLS en todo el sitio con datos de RUM de mPulse antes y después de realizar cambios.

La verificación de los datos de RUM nos proporciona un buen nivel de confianza en que los cambios que hacemos tienen un impacto positivo para nuestros lectores.

Las últimas cifras que analizamos corresponden a los datos 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 comenzar, usamos el Informe de UX de Chrome, en los datos mensuales de nivel de origen disponibles a través del panel de CrUX y mediante consultas en BigQuery para recuperar datos históricos de P75. De esta manera, pudimos ver con facilidad que, para todo el tráfico medido por CrUX, nuestro CLS del percentil 75 mejoró en un 250%, de 0.25 a 0.1, y que nuestro bucket de pasar creció de un 57% a un 72%.

El panel de CrUX que muestra CLS p75 para telegraph.co.uk es 0.1.
Resultados del panel de Crux.
BigQuery muestra valores de p75 que mejoran mes a mes, de 0.25 a 0.1.
Se ejecuta BigQuery en la que se muestran los valores p75 desde 2021 hasta la fecha.

Además, pudimos usar la API de Chrome UX Report y crear algunos paneles internos divididos en plantillas.

Panel interno que muestra una puntuación promedio buena de 76.2, requiere mejoras de 9.3 y una puntuación baja de 14.6.
Paneles internos que utilizan la API de Chrome UX Report, en los que se destacan nuestra puntuación promedio y las páginas con peor rendimiento que usan esa plantilla.

Evita las regresiones de CLS

Un aspecto importante para mejorar el rendimiento es evitar regresiones. Configuramos algunos presupuestos de rendimiento básicos para nuestras métricas clave y, luego, incluimos CLS en ellas.

Un panel de presupuesto de rendimiento en el que se muestran verificaciones sintéticas que miden CLS en algunas de nuestras plantillas de alto tráfico. Actualmente, el presupuesto está establecido en 0.025.

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 en el presupuesto, estamos al tanto de cualquier cambio que haya tenido un impacto negativo.

También planeamos expandir nuestros presupuestos para usar datos de RUM y datos sintéticos, mediante el uso de mPulse para configurar alertas estáticas y, potencialmente, la detección de anomalías, lo que nos permitirá estar al tanto de cualquier cambio fuera de lo común.

Es importante que nos enfoquemos en los nuevos atributos con el CLS en mente. Muchos de los cambios que mencioné son aquellos que tuvimos que corregir después de lanzarlos a nuestros lectores. La estabilidad del diseño se tendrá en cuenta para el diseño de la solución de cualquier función nueva en el futuro, de modo que podamos evitar cambios de diseño inesperados desde el principio.

Conclusión

Las mejoras que realizamos hasta ahora fueron bastante fáciles de implementar y tuvieron un impacto significativo. Muchos de los cambios que describí en este artículo no llevaron mucho tiempo y se aplicaron a todas las plantillas de uso general, lo que significa que tuvieron un impacto positivo generalizado para nuestros lectores.

Todavía hay áreas del sitio que debemos mejorar. Estamos explorando formas de hacer más de la lógica del lado del cliente en el 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 proporcionar a nuestros lectores la mejor experiencia del usuario posible.