Un caso de éxito sobre los cambios que realizó el equipo web de YouTube para mejorar el rendimiento, aumentar las tasas de aprobación de las Métricas web esenciales y aumentar las métricas empresariales clave.
El equipo de Chrome suele hablar sobre cómo "crear una mejor Web", pero ¿qué significa eso? Las experiencias web deben ser rápidas, accesibles y aprovechar las capacidades del dispositivo en el momento en que los usuarios más las necesitan. La prueba interna 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 mejor Web". En la primera parte de la serie, se explicará cómo YouTube creó una experiencia web más rápida.
Una Web más rápida
En YouTube, el rendimiento se relaciona con la velocidad con la que se cargan los videos y otro tipo de contenido, como las recomendaciones y los comentarios, en las páginas web. El rendimiento también se mide según la rapidez con la que YouTube responde a las interacciones del usuario, como la búsqueda, el control del reproductor, los “me gusta” y las veces que se comparte el contenido.
El crecimiento de los mercados en desarrollo, como Brasil, Indonesia y la India, es importante 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 sin interrupciones es un objetivo fundamental.
Con el fin de ofrecer una experiencia inclusiva para todos los usuarios, YouTube se propuso mejorar las métricas de rendimiento, como las Métricas web esenciales, mediante la carga diferida y la modernización del código.
Mejora las Métricas web esenciales
Con el objetivo de identificar las áreas de mejora, el equipo de YouTube usó el Informe sobre la experiencia del usuario en Chrome (CrUX) para saber cómo los usuarios reales experimentaban las páginas de resultados de búsqueda y de reproducción de videos en dispositivos móviles en el campo. La empresa se dio cuenta de que sus Métricas web esenciales podían mejorarse mucho. La métrica Largest Contentful Paint (LCP) registraba entre 4 y 6 segundos en algunos casos. Este fue considerablemente más alto que su objetivo de 2.5 segundos.
Con el objetivo de identificar á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 una First Contentful Paint (FCP) de 3.5 segundos y un LCP de 8.5 segundos.
Para optimizar el FCP y el LCP, el equipo de YouTube realizó varios experimentos, lo que generó dos grandes descubrimientos.
El primer descubrimiento fue que podían mejorar el rendimiento al mover el código HTML del reproductor de video sobre la secuencia de comandos que hacía que el reproductor de video fuera interactivo. Las pruebas de laboratorio indicaron que esto podría mejorar tanto el FCP como el LCP de 4.4 a 1.1 segundos.
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 por Internet. Tradicionalmente, YouTube realiza optimizaciones para lograr el tiempo más rápido hasta que el video comienza a reproducirse, por lo que, para mejorar el LCP, el equipo también comenzó a optimizar la rapidez con la que podía entregar la imagen de póster. Experimentaron con algunas variaciones de imágenes de pósteres y seleccionaron 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 marcada, y el LCP del campo mejoró de 4.6 a 2.0 segundos.
Si bien estas optimizaciones mejoraron el LCP, el equipo sintió que la definición actual de la métrica de LCP no capturaba completamente, desde la perspectiva del usuario, cuándo se había cargado el "contenido principal" de la página, que es el objetivo de LCP.
Para abordar estas inquietudes, los miembros del equipo de YouTube se asociaron con miembros del equipo de Chrome para explorar formas en las que podría mejorarse la métrica de LCP a fin de 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 candidato para el LCP.
Una vez que este cambio llegue a Chrome, el equipo de YouTube tendrá el agrado de seguir trabajando en la optimización del LCP. Además, con la versión actualizada de la métrica, estas optimizaciones tendrán un impacto más directo en las experiencias de usuarios reales.
Modularización con carga diferida
Las páginas de YouTube contenían muchos módulos que se cargaron con anticipación. Para optimizar la forma en que se renderizan más de 50 componentes, el equipo compiló un componente en el mapa de módulos JS que le indica al cliente qué módulos cargar. Al marcar los componentes como diferidos, los módulos JS se cargarían más tarde, lo que reduce el tiempo de carga inicial de la página y la cantidad de código JavaScript sin usar que se envía al cliente.
Sin embargo, después de implementar la carga diferida, el equipo notó un efecto de cascada que provocaba que los componentes con carga diferida y sus dependencias se cargaran en momentos poco óptimos.
Para resolver este problema, el equipo determinó el conjunto mínimo de componentes necesarios en una vista y los organiza en lotes en una sola solicitud de red. Los resultados mejoraron la velocidad de la página, redujeron el tiempo de análisis de JavaScript y, en última instancia, mejoraron los tiempos de renderización iniciales.
Administración del estado de los 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 de reproducción y el progreso, se había vuelto demasiado componente con el tiempo.
Cada evento táctil de la barra de progreso activó dos recálculos de estilo adicionales y tardó 21.17 ms en ejecuciones de pruebas de rendimiento en el lab. Con el tiempo, a medida que se agregaban nuevos controles, el patrón de control descentralizado a menudo provocaba dependencias circulares y fugas de memoria, lo que afectaba negativamente el rendimiento de la página de reproducción.
Para solucionar los problemas debidos al control descentralizado, el equipo actualizó la IU del jugador para sincronizar todas las actualizaciones y, en esencia, refactorizó el reproductor a un componente de nivel superior que pasaría datos a sus elementos secundarios. Esto garantizaba solo un ciclo de actualización (renderización) de la IU para cualquier cambio de estado y eliminaba las actualizaciones encadenadas. El evento touch-move de la barra de progreso del jugador nuevo no tiene recálculos de estilo durante su ejecución de JavaScript y ahora solo requiere el 25% del tiempo del jugador anterior.
Esta modernización del código también generó mejoras adicionales en el rendimiento, como mejoras en los tiempos de carga de reproducción en dispositivos antiguos, menos reproducciones abandonadas y una menor cantidad de errores recuperables.
Conclusión
Como resultado de la inversión de YouTube en el rendimiento, las páginas de reproducción se cargan mucho más rápido, ya que el 76% de las URLs de los sitios web móviles de YouTube superan los umbrales de las métricas web esenciales en el campo. En las computadoras de escritorio, el LCP del lab para la página de reproducción se redujo de aproximadamente 4.6 segundos a 1.6 segundos. La interacción y el rendimiento de renderización del sitio, especialmente en el reproductor de video de YouTube, registran hasta un 75% menos de tiempo que antes en la ejecución de JavaScript.
Las mejoras en el rendimiento de la versión web de YouTube durante el último año también mejoraron las métricas comerciales, incluidos el tiempo de reproducción y los usuarios activos por día. En función del éxito de estos esfuerzos, planeamos seguir explorando aún más formas de optimizar en el futuro.
En la segunda parte de esta serie, “Cómo crear una Web accesible”, conocerás cómo YouTube hizo que su sitio web fuera más accesible para los usuarios de lectores de pantalla.
Queremos agradecerles de forma especial a los equipos de YouTube y Chrome por sus contribuciones en este trabajo, como DISPLAY Cocchi, Lauren Usui, Benji Bear, Bo Aye, Bogdan Balas, Kenny Tran, Matthew Smith, Phil Harnish, Leena Sahoni, Jeremy Wagner, Philip Walton y Harleen Batra, así como los equipos de YouTube y Chrome.