Un caso de éxito sobre los cambios que realizó el equipo web de YouTube para mejorar el rendimiento, aumentar los porcentajes de aprobación de las Métricas web esenciales y mejorar las métricas comerciales clave.
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, analizaremos cómo YouTube creó una experiencia 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 recomendaciones y 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 en desarrollo 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 a 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 sustancialmente más alto que su objetivo de 2.5 segundos.
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.
Para optimizar el FCP y el LCP, el equipo de YouTube realizó varios experimentos, que arrojaron dos grandes descubrimientos.
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.
El segundo descubrimiento fue que LCP solo considera las imágenes de póster del elemento
<video>y no los fotogramas de la transmisión de video por Internet en sí. Tradicionalmente, YouTube ha optimizado para el tiempo más rápido hasta que el video comienza a reproducirse, por lo que para mejorar el LCP, el equipo también empezó a optimizar la rapidez con la que podían publicar su imagen de 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.
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 a 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 cargaron con anticipación. 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 organizó en lotes 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 del estado en todos 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 y el progreso de la reproducción, se había sobrecomponentizado con el tiempo.
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.
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.
Esta modernización del código también generó mejoras adicionales en el rendimiento, como mejores tiempos de carga de reproducción en dispositivos antiguos, menos reproducciones abandonadas y una menor cantidad de errores recuperables.
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, muestra hasta un 75% menos de tiempo dedicado a la ejecución de 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 continuar explorando aún más formas de optimizar 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.