El Futuro de las Herramientas de Rendimiento

Hola a todos, mi nombre es Adi Osmani. Soy un gerente de ingeniería que trabaja en el equipo de Chrome en Google. Y hoy vamos a hablar sobre el futuro de las performance tooling. Es posible que me conozcas de internet por publicar sobre las características de DevTools y hablar sobre performance, pero he pasado por la pandemia de la misma manera que todos los demás. Ha sido una larga pandemia. Ha habido muchas personas recientemente anunciando que tienen nuevos trabajos. Yo también estoy emocionado de anunciar mi nueva posición. Es la posición fetal. He estado en ella durante algún tiempo. Probablemente voy a permanecer en ella justo después de esto. Los últimos dos años fueron una buena prueba de resistencia.

Ahora, como mencioné, tiendo a hablar mucho sobre cosas como JavaScript y los paquetes de JavaScript, pero hoy quería dar un paso atrás y centrarme en la experiencia del usuario. Ahora, los usuarios a menudo experimentan las páginas web como un viaje, y hay algunos momentos clave para ello. ¿Está sucediendo? ¿Es útil? ¿Es usable? ¿Es agradable? El deleite puede significar hacer la experiencia más agradable a través de la adición de cosas como animaciones.

Ahora, como mencioné, me encanta compartir consejos de DevTools, y una cosa que algunas personas, ya sabes, muchas personas no saben es que DevTools en realidad tiene un inspector de animaciones incorporado. Aquí está en acción. Puedes usarlo para modificar el tiempo de las animaciones, retrasos, duraciones, y mucho más. Aquí está trabajando contra una aplicación de transiciones de página de Sarah Drasner. Me encanta el inspector de animaciones. Es una de mis características favoritas. Ahora, a veces la gente pregunta, bueno, ¿hay esfuerzos para llevar tales APIs a la plataforma? Jake Archibald dio una gran charla sobre una nueva API de Transiciones de Página. Y aquí hay una demostración genial de ella construida por la comunidad. Así que tenemos una transición de elemento compartido aquí donde al hacer clic en una URL, nos lleva a esta página. Volvemos atrás, y verás que tanto la barra de URL está cambiando, así como nos da estas hermosas animaciones. Ahora, queda mucho trabajo por hacer para soportar cosas como las Transiciones de Página en el inspector de animaciones, pero ya podemos ver cosas como ser capaces de reproducir estas animaciones y ver todos los diferentes tipos de movimiento que estamos añadiendo a nuestras páginas. Cosas realmente poderosas, y me encanta.

Así que a nuestra pregunta principal, ¿cómo es el futuro de las herramientas de rendimiento? Ahora, creo que son tres cosas. Creo que es centrado en el usuario, accionable y contextual. Empecemos con centrado en el usuario. Ahora, en los últimos años, Chrome ha hablado de la importancia de centrarse en las métricas de rendimiento centradas en el usuario, como las Core Web Vitals. Ahora, las Core Web Vitals son tres métricas. Son Largest Contentful Paints, First Input Delay, y Cumulative Layout Shift. Esto cubre la carga, la interactividad y la estabilidad visual. Ahora, estas son geniales. Recomendamos revisarlas utilizando datos reales en el campo, o en el laboratorio. Pero hay mucho más que podemos hacer para acercar cómo pensamos sobre el rendimiento a la experiencia del usuario. Ahora, probablemente hay un conjunto de viajes de usuario centrales que te importan en tu sitio estos días. Esto no es algo que las herramientas de rendimiento de laboratorio, o las herramientas que usamos en nuestros portátiles, hayan reconocido completamente todavía. En cambio, nos hemos centrado en cosas como el rendimiento de la carga inicial de la página. Esto sigue siendo muy importante, por cierto. Pero es una historia que hemos contado en algunos lugares, como en Lighthouse y en DevTools.

Pero estamos evolucionando nuestra comprensión de la user experience todo el tiempo. Ahora, si miras en el núcleo de las métricas de Vitals, algunas de ellas ya están pensando en ese rendimiento post-carga, incluyendo cosas como los cambios de diseño que podrían suceder después de que la página inicial se haya asentado. Tu pintura más grande y significativa puede cambiar. Y hay tantos factores que juegan aquí, como si eres una MPA o una SPA, ¿tienes una navegación suave? ¿Estás prebuscando o prerendiendo? ¿Cuál es tu estrategia de caché? Hay mucha sutileza aquí.

Y así, me gustaría que pensáramos en los flujos de usuario. Ahora, un flujo de usuario es una serie de pasos que un usuario realiza para alcanzar un objetivo significativo. Esta es una de las mejores definiciones que existen. Y es de Alexander Handley. Ahora, un flujo de usuario generalmente comienza en el punto de entrada de un usuario en una experiencia. Y generalmente termina completando una tarea particular, como completar un registro o hacer un pedido. Aquí hay varios ejemplos de flujos. Podrías estar haciendo cosas como intentar comprar un producto, sabes, pasando por las fases de encontrar lo que quieres, personalizarlo y así sucesivamente hasta que lo añades a tu carrito y pagas. Podrías estar en proceso de incorporación, podrías estar intentando crear cosas o cancelar un plan. Ahora, la forma en que hemos pensado en medir el rendimiento de este tipo de experiencias es generalmente dividiéndolas en URLs. Así que diremos, bueno, ¿cuál es el rendimiento de la carga de la página del paso uno, del paso dos, del paso tres, en lugar de razonar sobre ellos en conjunto o en su totalidad, de la forma en que un usuario los experimenta. Y creo que hay una oportunidad para hacer algo para acercar esto mucho más a lo que el usuario siente. Me alegra compartir que hemos añadido soporte para flujos de usuario en DevTools y Lighthouse. Esto es un gran avance. Hemos estado trabajando en ello durante algún tiempo y estoy realmente emocionado de guiarte a través de ello. Todo comienza con el grabador de DevTools. Así que aquí está el grabador que nos permite medir a través de todo un viaje. Voy a empezar con un flujo de Añadir al Carrito. Tengo nuestra experiencia de comercio. Estoy navegando por categorías. Estoy añadiendo algunas cosas a mi carrito. Quizás quiero usar la función de búsqueda para encontrar una camiseta. Así que vamos a hacer eso. Vamos a personalizar algunos colores. Luego vamos a proceder a nuestro pago. Ahora aquí puedo pulsar stop y verás que todas esas interacciones fueron capturadas por DevTools, incluyendo los selectores

Ahora, hemos estado trabajando para tratar de asegurarnos de que herramientas como Lighthouse sean tan accionables como sea posible para los web vitals. Y si no has revisado Lighthouse recientemente, tenemos todo tipo de auditorías que pueden ayudarte a hacer cosas como identificar tus tareas de hilo principal largas o cuáles son tus grandes cambios de diseño. Y tratamos de hacer esta experiencia bastante visual. Y tratamos de señalar exactamente a qué nodos DOM podrías querer prestar atención. Ahora, hablamos mucho sobre la preparación para la interacción. Y quería hablarles sobre la capacidad de respuesta de entrada por un momento. Entonces, ¿qué es la capacidad de respuesta? La capacidad de respuesta significa entender cuán rápido responden las páginas web a la entrada del usuario. Ahora, esto puede significar cosas como cuando intento abrir el menú en un sitio web, ¿cuánto tiempo tarda antes de que realmente suceda algo? O si estoy tratando de agregar algo a mi carrito, ¿cuánto tiempo tarda antes de que realmente pueda ver que mi artículo ha sido agregado? Todos estos son pasos importantes en un flujo de usuario. Ahora, hemos estado trabajando en una nueva métrica de preparación de interacción y la llamamos Interacción hasta la siguiente pintura. Esta es una nueva métrica de capacidad de respuesta experimental. Mide la capacidad de respuesta en tiempo de ejecución, la latencia de interacción completa, e incluye cosas como toques, arrastres y eventos de entrada de teclado también. La forma en que esto difiere del primer retraso de entrada es que mide toda la latencia de entrada desde que un usuario interactúa hasta que realmente ven una respuesta visual, no solo el retraso inicial en el hilo principal.

Ahora, lo que descubrimos es que el 70% de los usuarios tienen una experiencia que es terrible en lo que respecta a la capacidad de respuesta al menos una vez a la semana. Esta es realmente una gran oportunidad para nosotros de hacerlo mejor, especialmente dado que la investigación de UX dice que idealmente deberías estar mirando 100 milisegundos para la latencia de entrada esperada. Descubrimos que en el escritorio los usuarios cargan el doble de páginas si experimentan una buena capacidad de respuesta allí. Así que muchas razones para optimizar para estas métricas.

A medida que estas métricas han ido saliendo también hemos podido compartir una orientación más concreta. Por ejemplo, si estás usando React 18 y envuelves tu UI en límites de suspense puedes hacer que la hidratación no sea bloqueante porque ocurre en rebanadas en lugar de en un solo bloque. Esto puede mejorar cosas como tu tiempo total de bloqueo. Y estoy esperando con ansias aún más orientación concreta para optimizar métricas como el tiempo total de bloqueo e IMP que saldrá antes de mucho tiempo. Ahora, hemos estado trabajando duro en la introducción de IMP a muchas de las herramientas de Chrome, empezando por PageSpeed Insights. Así que lo primero que voy a mostrar es una nueva función llamada Fast Crux. Esto te da acceso instantáneo a los datos de campo. Verás que acabo de pulsar analizar. Esto no está acelerado y tienes acceso instantáneo a los datos de campo y luego se cargarán progresivamente tus datos de diagnóstico de Lighthouse para que entiendas dónde puedes mejorar. Así que IMP ya está en PageSpeed Insights. A continuación tenemos Lighthouse donde tenemos ese modo de lapso de tiempo. Voy a interactuar con una de las experiencias más interactivas de Google, Google Flights y aquí voy a mostrarte que estoy realizando una serie de interacciones. He acelerado esto un poco y vamos a terminar nuestro lapso de tiempo aquí. Y lo que esto nos da es un informe de Lighthouse que incluye la interacción hasta la Próxima Pintura. Podemos desplazarnos hacia abajo y podemos ver que tenemos una nueva auditoría llamada Minimizar el Trabajo Durante la Interacción Clave. Esto incluye nuestro retraso de entrada, retraso de procesamiento, retraso de presentación así como todas las otras auditorías que Lighthouse normalmente te da para razonar sobre tareas largas y el rendimiento de JavaScript. Finalmente hemos trabajado en herramientas como la Extensión Web Vitals que sé que a muchos les gusta. Esto también ahora tiene interacción hasta la Próxima Pintura. Ahora, en el lado de la depuración de rendimiento, la gente ha estado usando el panel de rendimiento durante años y años y en realidad comenzó en un lugar donde era un poco más simple. Con el tiempo añadimos gráficos de llama y la capacidad de razonar sobre la profundidad de la pila de llamadas pero se inclinó un poco hacia las herramientas que los ingenieros de navegadores usaban para la depuración de rendimiento. ¿Podría ser mejor? Tenemos una vista previa de algo en lo que hemos estado pensando. Así que me gustaría presentar

Ahora, un pensamiento final es que mejorar el performance es un viaje. Hay muchos pequeños cambios que pueden llevar a grandes ganancias. El primer paso podría ser un esquema. El segundo paso definitivamente no es esto. No vas a resolver de repente todos los problemas del mundo. Pero podrías terminar similar a donde yo usualmente lo hago con el performance, que es el paso 1.5. Está bien. Es el resultado de invertir iterativamente en mejorar tu user experience con el tiempo. Y eventualmente llegarás a algo más cercano a esto. Pero esto está bien. Todavía es bonito. Tus usuarios te van a agradecer por una experiencia de performance mejorada al final del día. Así que espero que hayas obtenido algún valor de esta charla. Creo que el futuro de las herramientas de performance es centrado en el usuario, accionable y contextual. He sido Adi Osmani. Muchas gracias.