Creamos una Web mejor: un YouTube más rápido

Un caso de éxito sobre los cambios que realizó el equipo web de YouTube para mejorar el rendimiento, aumentar sus tasas de aprobación de las Métricas web esenciales y mejorar las métricas comerciales clave.

Sriram Krishnan
Sriram Krishnan

El equipo de Chrome suele hablar de “crear una Web mejor”, pero ¿qué significa eso? Las experiencias web deben ser rápidas, accesibles y usar las funciones del dispositivo en el momento en que los usuarios más las necesitan. El uso interno es parte de la cultura de Google, por lo que el equipo de Chrome se asoció con YouTube para compartir las lecciones aprendidas en el camino en una nueva serie llamada "Cómo crear una Web mejor". En la primera parte de la serie, se analizará cómo YouTube creó una experiencia web más rápida.

PageSpeed Insights muestra los datos del Informe de UX de Chrome.
La página de reproducción de YouTube para la Web móvil supera los umbrales de las Métricas web esenciales.

En YouTube, el rendimiento se relaciona con la rapidez con la que se cargan los videos y otro contenido, como las recomendaciones y los comentarios, en las páginas web. El rendimiento también se mide en función de la rapidez con la que YouTube responde a las interacciones de los usuarios, como la búsqueda, el control del reproductor, los Me gusta y los compartidos.

Los mercados emergentes en crecimiento, como Brasil, India e Indonesia, son importantes para la Web móvil de YouTube. Debido a que muchos usuarios de estas regiones tienen dispositivos más lentos y un ancho de banda de red limitado, garantizar una experiencia rápida y fluida es un objetivo fundamental.

Para proporcionar una experiencia inclusiva para todos los usuarios, YouTube se propuso mejorar las métricas de rendimiento, como las Métricas web esenciales, a través de la carga diferida y la modernización del código.

Mejora las métricas web esenciales

Para identificar áreas de mejora, el equipo de YouTube usó el Informe sobre la experiencia del usuario en Chrome (CrUX) para ver cómo los usuarios reales experimentaban las páginas de resultados de búsqueda y reproducción de videos en dispositivos móviles en el campo. Se percataron de que sus métricas de Métricas web esenciales tenían mucho margen de mejora, ya que la métrica Largest Contentful Paint (LCP) registraba entre 4 y 6 segundos en algunos casos. Esto era mucho más alto que su objetivo de 2.5 segundos.

Gráficos de FCP y LCP que muestran los porcentajes de aprobación de las páginas de reproducción de YouTube, así como el origen de YouTube.

Para identificar las áreas de mejora, recurrieron a Lighthouse para auditar las páginas de reproducción de YouTube, lo que reveló una puntuación baja de Lighthouse (lab) con un primer procesamiento de imagen con contenido (FCP) de 3.5 segundos y un LCP de 8.5 segundos.

Informe de Lighthouse para YouTube para dispositivos móviles.
Chrome establece un objetivo de 1.8 s para el FCP y de 2.5 s para el LCP como estándar de oro. El FCP y el LCP estaban claramente en amarillo y rojo a los 3.5 s y 8.5 s, respectivamente.

Para optimizar el FCP y el LCP, el equipo de YouTube realizó varios experimentos, que arrojaron dos grandes descubrimientos.

  1. El primer descubrimiento fue que podían mejorar el rendimiento si movían el código HTML del reproductor de video por encima de la secuencia de comandos que lo hace interactivo. Las pruebas de laboratorio indicaron que esto podría mejorar el FCP y el LCP de 4.4 segundos a 1.1 segundos.

  2. El segundo descubrimiento fue que el LCP solo considera las imágenes de póster del elemento <video> y no los fotogramas de la transmisión de video en sí. Tradicionalmente, YouTube se ha optimizado para que el video comience a reproducirse lo más rápido posible. Por lo tanto, para mejorar el LCP, el equipo también comenzó a optimizar la rapidez con la que se podía entregar la imagen del póster. Experimentaron con algunas variaciones de imágenes de pósteres y eligieron la que obtuvo la mejor puntuación en las pruebas de usuario. Como resultado de este trabajo, tanto el FCP como el LCP mostraron una mejora notable, y el LCP de campo mejoró de 4.6 segundos a 2.0 segundos.

Mira el experimento de LCP de la página para la Web móvil que muestra el control, el experimento A (miniatura de imagen) y el experimento B (miniatura negra)
En el lab, observamos una mejora en el FCP y el LCP de 4.4 s a 1.1 s después de que se implementó este cambio. Experimento A: Usar la miniatura real del video funciona bien en las páginas en las que el video comienza pausado, pero en las páginas de video con reproducción automática, como la página de reproducción, tuvo un rendimiento bajo en los estudios de usuarios. También generó una disminución en la cantidad de usuarios activos. Experimento B: El uso de una imagen de póster negra sólida mostró los mejores resultados en los estudios de usuarios. Los usuarios consideraron que la transición del negro sólido al primer fotograma del video es una experiencia menos discordante para los videos con reproducción automática.
La miniatura negra se implementó en producción para todos los usuarios de la Web móvil en julio de 2021, lo que mostró una mejora significativa en el FCP y el LCP, como se ve en el análisis de RUM anterior.
La miniatura negra se implementó en producción para todos los usuarios de la Web móvil en julio de 2021, lo que mostró una mejora significativa en el FCP y el LCP, como se ve en el análisis de RUM anterior.

Si bien estas optimizaciones mejoraron el LCP, el equipo consideró que la definición actual de la métrica no capturaba por completo, desde la perspectiva del usuario, cuándo se cargaba el "contenido principal" de la página, que es el objetivo del LCP.

Para abordar estas inquietudes, los miembros del equipo de YouTube se asociaron con los miembros del equipo de Chrome para explorar formas de mejorar la métrica de LCP y abordar su caso de uso. Después de considerar la viabilidad y el impacto de algunas opciones, los equipos llegaron a una propuesta para considerar el tiempo de pintura del primer fotograma de un elemento de video como un candidato de LCP.

Una vez que este cambio se implemente en Chrome, el equipo de YouTube continuará trabajando para optimizar la LCP. Además, la versión actualizada de la métrica significará que estas optimizaciones tendrán un impacto más directo en las experiencias de los usuarios reales.

Modularización con carga diferida

Las páginas de YouTube contenían muchos módulos que se cargaban de forma inmediata. Para optimizar la renderización de más de 50 componentes, el equipo creó un mapa de componentes para el módulo JS que le indicaría al cliente qué módulos cargar. Si marcas los componentes como diferidos, los módulos de JS se cargarán más tarde, lo que reducirá el tiempo de carga inicial de la página y la cantidad de JavaScript no utilizado que se envía al cliente.

Sin embargo, después de implementar la carga diferida, el equipo notó un efecto cascada que cargaba los componentes cargados de forma diferida y sus dependencias en momentos poco óptimos.

Para resolver este problema, el equipo determinó el conjunto mínimo de componentes necesarios en una vista y los agrupó en una sola solicitud de red. Los resultados fueron una mejora en la velocidad de la página, una reducción en el tiempo de análisis de JavaScript y, en última instancia, mejores tiempos de renderización iniciales.

Administración de estado en varios componentes

YouTube tenía problemas de rendimiento debido a los controles del reproductor, especialmente en dispositivos más antiguos. El análisis de código mostró que el reproductor, que permite a los usuarios controlar funciones como la velocidad y el progreso de la reproducción, se había sobrecomponentizado con el tiempo.

Reproductor y controles de YouTube visualizados
El reproductor de video de YouTube permite a los usuarios controlar la velocidad de reproducción, seguir el progreso, omitir secciones y mucho más. Cuando un usuario presiona un control en particular, el cambio en el estado se debe comunicar a otros controles, p.ej., el toque de un usuario en la barra de progreso se debe compartir con controles como el cabezal de reproducción, los subtítulos, etc.

Cada evento de movimiento táctil de la barra de progreso activó dos recalculos de estilo adicionales y tardó 21.17 ms durante las ejecuciones de pruebas de rendimiento en el laboratorio. A medida que se agregaban nuevos controles con el tiempo, el patrón de control descentralizado a menudo causaba dependencias circulares y fugas de memoria, lo que afectaba negativamente el rendimiento de la página de reproducción.

Evento de 21.17 ms que se muestra en el cronograma de rendimiento.
Chrome DevTools con una ejecución de rendimiento que ralentiza la CPU 4 veces.

Para solucionar los problemas debidos al control descentralizado, el equipo actualizó la IU del reproductor para sincronizar todas las actualizaciones, lo que, en esencia, refactorizó el reproductor en un componente de nivel superior que pasaría datos a sus elementos secundarios. Esto garantizaba un solo ciclo de actualización (renderización) de la IU para cualquier cambio de estado, lo que eliminaba las actualizaciones encadenadas. El nuevo evento de movimiento táctil de la barra de progreso del reproductor no tiene recalculos de estilo durante su ejecución de JavaScript y ahora solo requiere el 25% del tiempo del reproductor anterior.

Se redujo el tiempo de los eventos que se muestran en el cronograma de rendimiento.

Esta modernización del código también generó mejoras adicionales de rendimiento, como tiempos de carga de reproducción mejorados en dispositivos antiguos, menos reproducciones abandonadas y una menor cantidad de errores no fatales.

Resultados y optimizaciones

Como resultado de la inversión de YouTube en el rendimiento, las páginas de reproducción se cargan mucho más rápido, y el 76% de las URLs de los sitios web para dispositivos móviles de YouTube ahora superan los umbrales de métricas de las Métricas web esenciales en el campo. En computadoras de escritorio, el LCP de lab para la página de reproducción se redujo de aproximadamente 4.6 segundos a 1.6 segundos. El rendimiento de interacción y renderización del sitio, en especial en el reproductor de video de YouTube, ahora tarda hasta un 75% menos en ejecutar JavaScript que antes.

Las mejoras en el rendimiento de YouTube para la Web durante el último año también mejoraron las métricas empresariales, como el tiempo de reproducción y los usuarios activos diarios. En función del éxito de estos esfuerzos, planeamos seguir explorando aún más formas de realizar optimizaciones en el futuro.

Agradecemos especialmente a Gilberto Cocchi, Lauren Usui, Benji Bear, Bo Aye, Bogdan Balas, Kenny Tran, Matthew Smith, Phil Harnish, Leena Sahoni, Jeremy Wagner, Philip Walton, Harleen Batra y los equipos de YouTube y Chrome por sus contribuciones a este trabajo.