El Futuro de las Herramientas de Rendimiento

Rate this content
Bookmark

Nuestra comprensión del rendimiento y la experiencia del usuario ha evolucionado considerablemente a lo largo de los años. Las herramientas de desarrollo web deben evolucionar de manera similar para asegurarse de que sean centradas en el usuario, accionables y contextuales en lo que respecta a las experiencias modernas. En esta charla, Addy te guiará a través de cómo Chrome y otros han estado pensando en este problema y qué actualizaciones han estado realizando en las herramientas de rendimiento para reducir la fricción en la creación de grandes experiencias en la web.

21 min
16 Jun, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

La charla de hoy analiza el futuro de las herramientas de rendimiento, centrándose en enfoques centrados en el usuario, accionables y contextuales. La introducción destaca la experiencia de Adi Osmani en herramientas de rendimiento y su pasión por las características de DevTools. La charla explora la integración de flujos de usuario en DevTools y Lighthouse, permitiendo la medición y optimización del rendimiento. También muestra la función de importación/exportación para flujos de usuario y el potencial de colaboración con Lighthouse. La charla profundiza en el uso de flujos con otras herramientas como web page test y Cypress, ofreciendo capacidades de prueba multi-navegador. El aspecto accionable enfatiza la importancia de métricas como la Interacción hasta el Próximo Pintado y el Tiempo Total de Bloqueo, así como las mejoras en Lighthouse y las herramientas de depuración de rendimiento. Por último, la charla enfatiza la naturaleza iterativa de la mejora del rendimiento y el futuro centrado en el usuario, accionable y contextual de las herramientas de rendimiento.

Available in English

1. Introducción

Short description:

Hola a todos, mi nombre es Adi Osmani. Soy un gerente de ingeniería que trabaja en el equipo de Chrome en Google. Hoy vamos a hablar sobre el futuro de las herramientas de rendimiento. Es posible que me conozcan de internet por publicar sobre las características de DevTools y hablar sobre 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 herramientas de rendimiento. Es posible que me conozcan de internet por publicar sobre las características de DevTools y hablar sobre rendimiento, pero he pasado por la pandemia de la misma manera que todos los demás. Ha sido una pandemia larga. Recientemente, ha habido muchas personas que anuncian 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 seguiré en ella justo después de esto. Los últimos dos años fueron una buena prueba en seco.

2. The Future of Performance Tooling

Short description:

Hoy vamos a hablar sobre el futuro de las herramientas de rendimiento. La satisfacción puede significar hacer que la experiencia sea más agradable mediante la adición de cosas como animaciones. DevTools tiene un inspector de animaciones incorporado. Es una de mis características favoritas. Hay esfuerzos para llevar este tipo de API a la plataforma. El futuro de las herramientas de rendimiento es centrado en el usuario, práctico y contextual. Core Web Vitals son tres métricas que abarcan la carga, la interactividad y la estabilidad visual. Podemos hacer más para acercar nuestra forma de pensar sobre el rendimiento a la experiencia del usuario.

Ahora, como mencioné, suelo hablar mucho sobre cosas como JavaScript y paquetes de JavaScript, pero hoy quiero dar un paso atrás y centrarme en la experiencia del usuario. Los usuarios a menudo experimentan las páginas web como un viaje, y hay algunos momentos clave en ese viaje. ¿Está sucediendo, es útil, es utilizable y es agradable? La satisfacción puede significar hacer que la experiencia sea más agradable mediante la adición de cosas como animaciones.

Como mencioné, me encanta compartir consejos sobre DevTools, y una cosa que mucha gente no sabe es que DevTools tiene un inspector de animaciones incorporado. Aquí lo tienes en acción. Puedes usarlo para modificar el tiempo de las animaciones, los retrasos, las duraciones y mucho más. Aquí está funcionando en una aplicación de transiciones de página creada por Sarah Drasner. El inspector de animaciones es una de mis características favoritas.

A veces la gente pregunta si hay esfuerzos para llevar este tipo de API a la plataforma. Jake Archibald dio una gran charla sobre una nueva API de transiciones de página. Y aquí tienes una demo genial creada por la comunidad. 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 como que nos ofrece estas hermosas animaciones. Aún queda mucho trabajo por hacer para admitir cosas como las transiciones de página en el inspector de animaciones, pero ya podemos ver cosas como poder reproducir estas animaciones y ver todos los diferentes tipos de movimiento que estamos agregando a nuestras páginas. Realmente es algo poderoso y me encanta.

Así que pasemos a nuestra pregunta principal, ¿cómo será el futuro de las herramientas de rendimiento? Creo que hay tres aspectos importantes. Creo que será centrado en el usuario, práctico y contextual. Comencemos con el enfoque centrado en el usuario. En los últimos años, Chrome ha hablado sobre la importancia de centrarse en métricas de rendimiento centradas en el usuario, como los Core Web Vitals. Los Core Web Vitals son tres métricas: Largest Contentful Paint, First Input Delay y Cumulative Layout Shift. Esto abarca la carga, la interactividad y la estabilidad visual. Estas son métricas excelentes. Recomendamos verificarlas utilizando datos del mundo real en el campo o en el laboratorio. Pero hay mucho más que podemos hacer para acercar nuestra forma de pensar sobre el rendimiento a la experiencia del usuario. Probablemente haya un conjunto de rutas de usuario principales que te importan en tu sitio en estos días. Esto no es algo que las herramientas de rendimiento de laboratorio o las herramientas que usamos en nuestras computadoras portátiles hayan reconocido completamente todavía. En cambio, nos hemos centrado en cosas como el rendimiento inicial de carga 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.

3. Understanding User Flows and DevTools Recorder

Short description:

Estamos evolucionando nuestra comprensión de la experiencia del usuario, incluyendo el rendimiento posterior a la carga y los flujos de usuario. Los flujos de usuario son una serie de pasos que un usuario realiza para lograr un objetivo. Hemos agregado soporte para flujos de usuario en DevTools y Lighthouse, comenzando con el grabador de DevTools. Captura interacciones y selectores.

Pero estamos evolucionando nuestra comprensión de la experiencia del usuario todo el tiempo. Ahora, si observas el núcleo de las métricas de Vitals, algunos de ellos ya están pensando en ese rendimiento posterior a la carga, incluyendo cosas como cambios de diseño que pueden ocurrir después de que la página inicial se haya establecido. Tu mayor contenido visible puede cambiar. Y hay muchos factores que influyen aquí, como si eres un MPA o un SPA, si tienes una navegación suave, si estás prefijando o pre-renderizando, cuál es tu estrategia de almacenamiento en caché. Hay muchos matices aquí.

Así que me gustaría que pensemos en los flujos de usuario. Ahora, un flujo de usuario es una serie de pasos que un usuario realiza para lograr un objetivo significativo. Esta es una de las mejores definiciones que existen. Y es de Alexander Handley. Normalmente, un flujo de usuario comienza en el punto de entrada del usuario en una experiencia. Y generalmente termina al completar una tarea específica, como completar un registro o realizar un pedido. Aquí hay varios ejemplos de flujos. Puedes estar haciendo cosas como tratar de comprar un producto, pasando por las fases de encontrar lo que quieres, personalizarlo, etc., hasta agregarlo a tu carrito y realizar el pago. Puedes estar en proceso de incorporación, puedes estar intentando crear cosas o cancelar un plan. Ahora, la forma en que hemos pensado en medir el rendimiento de estos tipos de experiencias es generalmente dividiéndolos en URL. Entonces diremos, bueno, ¿cuál es el rendimiento de carga de la página del paso uno, del paso dos, del paso tres, en lugar de razonar sobre ellos en su conjunto o en su totalidad, de la forma en que un usuario los experimenta. Y creo que hay una oportunidad para hacer algo que se acerque mucho a lo que siente el usuario. Me complace compartir que hemos agregado soporte para flujos de usuario en DevTools y Lighthouse. Esto es muy importante. Hemos estado trabajando en ello durante algún tiempo y estoy realmente emocionado de mostrártelo. Todo comienza con el grabador de DevTools. Así que aquí está el grabador que nos permite medir a lo largo de todo el recorrido. Voy a comenzar con un flujo de Agregar al carrito. Tengo nuestra experiencia de comercio. Estoy navegando por categorías. Estoy agregando algunas cosas a mi carrito. Tal vez quiera usar la función de búsqueda para encontrar una camiseta. Así que lo haremos. Vamos a personalizar algunos colores. Luego procederemos al pago. Aquí puedo detenerme y verás que todas esas interacciones fueron capturadas por DevTools, incluyendo los selectores.

4. Replaying Flows and Performance Measurement

Short description:

Ahora puedo reproducir flujos de usuario, medir el rendimiento y optimizar partes específicas de la experiencia en el panel de rendimiento de DevTools. Los flujos también se pueden exportar a Puppeteer para realizar pruebas y usar con Lighthouse para visualizar los pasos, ver auditorías e identificar áreas de mejora.

que estuvieron involucrados. Ahora puedo reproducir ese flujo. No tengo que decirle a cada miembro de mi equipo que lo haga ellos mismos. Puedo presionar reproducir. Va a ir de principio a fin y ahí vamos. Hemos realizado el pago. Puedo medir el rendimiento de este flujo. Así que tenemos un botón de medir rendimiento aquí. Va a reproducir todo el flujo, generar un rastro de la experiencia de principio a fin y aquí lo tenemos. Estamos en el panel de rendimiento de DevTools y puedo acercarme a cualquier parte de esa experiencia que desee optimizar. También podemos exportar flujos a Puppeteer en caso de que estemos escribiendo pruebas y queramos que esas pruebas también reflejen lo que estamos haciendo. Así que aquí estoy. Me ha generado un script de Puppeteer. También podemos usar estos scripts de Puppeteer con Lighthouse para obtener algunos beneficios adicionales. En este caso, estoy utilizando una función de Lighthouse que nos permite anotar cosas como intervalos de tiempo y capturas de pantalla y a través de Puppeteer puedo obtener este nuevo informe, este informe de flujo. Esto nos permite visualizar todos esos diferentes pasos.

5. User Flow Import/Export and Lighthouse Support

Short description:

En Chrome Canary, el panel de grabación ahora te permite importar y exportar flujos de usuario utilizando JSON. Esta adición facilita compartir y colaborar en flujos de usuario. También puedes editar flujos de usuario, personalizar productos y medir partes específicas del flujo utilizando el panel de Lighthouse. Esto te permite identificar áreas de mejora, como problemas de cambio de diseño acumulativo. Encuentra esta poderosa función en Canary y aprovecha al máximo.

Ahora puedes ver auditorías para partes de la experiencia que puedan necesitar un poco de trabajo. Ahora, en Chrome Canary, hemos seguido iterando en este soporte. El panel de grabación ahora también te permite importar y exportar flujos de usuario, incluyendo el uso de JSON. Esta adición hace que sea realmente trivial para que puedas comprometer tus flujos de usuario en tu repositorio de GitHub, compartirlo con los miembros de tu equipo, compartirlo con QA, y será realmente poderoso para tu historia de compartir. También puedes hacer cosas como editar flujos de usuario para sus selectores y tiempos de espera en caso de que las cosas tomen un poco más de tiempo de lo esperado. También en Canary tenemos soporte para el panel de Lighthouse para flujos, por lo que puedes seleccionar un intervalo de tiempo, puedes iniciar el intervalo de tiempo y comenzar a interactuar con esa experiencia. Esta es la primera vez que te permitimos interactuar mientras Lighthouse está en ejecución, por lo que puedes interactuar con esta experiencia, puedes personalizar tus productos. Y cuando hayas terminado con la parte del flujo que deseas medir, puedes finalizar el intervalo de tiempo. Esto generará un informe de esa parte del flujo y podemos usarlo para descubrir cosas como, ¿necesito hacer un poco más de trabajo en mi cambio de diseño acumulativo, porque tal vez hubo algún cambio de diseño que ocurrió durante mis interacciones? Esto es realmente poderoso.

6. Flows with Other Tools and Cross-Browser Testing

Short description:

Ahora exploremos el uso de flujos con otras herramientas. El equipo de pruebas de páginas web tiene un grabador de DevTools para scripts de pruebas de páginas web. Al exportar flujos a un archivo cart.json, podemos analizar todo el flujo del usuario, obtener información sobre el rendimiento, filmstrips y procesos de carga visual de la página. También podemos utilizar las características de la cascada de pruebas de páginas web. Además, cypress.io ofrece un paquete para exportar pruebas de Cypress desde grabaciones de Chrome DevTools. Esto permite realizar pruebas en varios navegadores y reproducir flujos grabados, lo que permite la depuración y una potente interoperabilidad entre navegadores.

En Canary puedes encontrarlo y esperamos que te resulte útil. Ahora, otra pregunta que teníamos después de trabajar en los flujos era: ¿qué pasaría si pudieras usar flujos con otras herramientas? Me complace compartir algo muy experimental y emocionante. Me encanta usar web page test, y el equipo de pruebas de páginas web ha creado un práctico grabador de DevTools para scripts de pruebas de páginas web que puedes revisar. Así que digamos que he exportado mi flujo a un archivo cart.json utilizando uno de los pasos anteriores. Puedo usar esto con este script. Esto es cómo se ve la salida. No es muy interesante, pero vamos a saltar adelante. Y déjame mostrarte lo que esto permite. Podemos pegarlo en nuestra ejecución de web page test y ahora puedo analizar todo el flujo del usuario. Obtengo información sobre el rendimiento para mis navegaciones, para mis clics. Obtengo filmstrips. Puedo ver el proceso de carga visual de la página para cualquiera de mis pasos. Puedo desplazarme hacia abajo, puedo utilizar cualquiera de las excelentes características de la cascada de pruebas de páginas web para comprender los cuellos de botella. Todo esto es realmente genial y nos acerca a la interoperabilidad de las herramientas, lo cual me entusiasma mucho. Aquí, por ejemplo, podemos ver que también tenemos características como los videos de pruebas de páginas web, que me encanta usar. Ahora, otra pregunta que nos hacemos es: ¿qué pasa con las pruebas en varios navegadores de los flujos? Tal vez sepas a dónde vamos con esto. Entonces, cypress.io es una herramienta de automatización de pruebas fácil de usar para pruebas de extremo a extremo. Es excelente para cosas como pruebas de interfaz de usuario, suites de regresión, integración y pruebas unitarias. Ahora, el equipo de Cypress tiene un paquete especial nuevo que puede exportar pruebas de Cypress desde grabaciones de Google Chrome DevTools. Digamos que tomamos nuestro cart.json una vez más, y quiero ejecutarlo con Cypress. Voy a usar el paquete de conversión del grabador en mi cart.json. Vamos a seguir adelante y decir que lo hemos hecho. Ahora vamos a ejecutar Cypress. Veamos qué sucede. Así que npx cypress open, se abrirá una ventana de Cypress. Puedo seleccionar un navegador aquí. Así que voy a seleccionar Firefox, nuestro users.spec.js es el script de Cypress convertido. Y aquí estoy con el flujo que grabé usando Chrome DevTools y se está reproduciendo todo mi flujo en Firefox. Esto es tan genial. Puedo ir a todos los diferentes pasos y secuencias que estuvieron involucrados en este flujo. Puedo depurar, ya sabes, qué puede no estar funcionando bien en varios navegadores y es realmente poderoso que obtengas este tipo de interoperabilidad entre navegadores.

7. Cypress Account and Recording

Short description:

Si tienes una cuenta de Cypress y una clave de API, puedes grabar y persistir grabaciones de flujos en tu panel de control de Cypress. Puedes compartir y reproducir las grabaciones, lo que brinda una experiencia poderosa. ¡Échale un vistazo!

casi a través de estas tooling. Es realmente, realmente genial. Ahora, si tienes una cuenta de Cypress y tienes una clave de API, puedes hacer cosas como usar el registro para persistir tu grabación de flujo en tu panel de control de Cypress. Así que aquí tienes un ejemplo de eso. Voy a ir y mostrarte algo que hice antes. Aquí tenemos nuestra experiencia de Agregar al Carrito y podemos ver lo que acabamos de... Ya sabes, donde estamos haciendo la demostración. Aquí hay un video de esa experiencia. Puedo compartirlo con otros, puedo reproducirlo. Obtengo la misma experiencia de Cypress que obtendría si estuviera creando estos flujos personalmente. Realmente, realmente poderoso.

8. Actionable: New Metrics and Improving Lighthouse

Short description:

A continuación, tenemos Accionable. Ahora, mencioné anteriormente que estaba emocionado de anunciar mi nueva posición. Cuando las personas a menudo miran la línea de tiempo, el panel de rendimiento, lo encuentran desalentador. Casi quieren llorar. Un buen consejo de vida es que si JavaScript no brinda alegría a los usuarios, agradézcalo y deséchelo. Hemos estado trabajando para asegurarnos de que herramientas como Lighthouse sean lo más accionables posible para los vitales web. Hemos estado trabajando en una nueva métrica de preparación de interacción llamada Interacción hasta el siguiente pintado. Mide la capacidad de respuesta en tiempo de ejecución, la latencia completa de interacción e incluye toques, arrastres y eventos de entrada de teclado. El Tiempo de Bloqueo Total es una buena métrica a considerar.

cosas. Espero que lo revises. A continuación, tenemos Accionable. Ahora, mencioné anteriormente que estaba emocionado de anunciar mi nueva posición. Así es como me veo cuando estoy mirando trazas de rendimiento en DevTools la mayor parte del tiempo. Me encanta DevTools, por cierto. Ahora, cuando las personas a menudo miran la línea de tiempo, el panel de rendimiento, lo encuentran desalentador. Casi quieren llorar. A veces lloro cuando miro el panel de rendimiento. ¿Sabías que hay alrededor de 17 músculos que se activan cuando lloras? 17 músculos. Genial para el estado físico. También he estado haciendo algo de eso durante la pandemia, no voy a mentir. Ahora, cuando estás mirando el panel de rendimiento, a menudo tienes mucha data aquí. Aquí tenemos una tarea larga. Si alguna vez te has preguntado por qué el tiempo de interactividad no es bueno, a menudo se debe a que las tareas largas de JavaScript mantienen ocupado el hilo principal. Ahora, un buen consejo de vida es que si JavaScript no brinda alegría a los usuarios, agradézcalo y deséchelo. Estoy bastante seguro de que esto es de un especial de Marie Kondo. Ella no dijo, de hecho, JavaScript. Pero creo que este es un buen consejo siempre actual.

Ahora, hemos estado trabajando para asegurarnos de que herramientas como Lighthouse sean lo más accionables posible para los vitales web. Y si no has revisado Lighthouse recientemente, tenemos todo tipo de auditorías que pueden ayudarte a identificar tus tareas largas en el hilo principal o tus cambios de diseño grandes. Y tratamos de hacer esta experiencia bastante visual. Y tratamos de señalar exactamente qué nodos del DOM debes prestar atención. Ahora, hablamos mucho sobre la preparación de interacción. Y quería hablar contigo sobre la capacidad de respuesta de entrada por un momento. Entonces, ¿qué es la capacidad de respuesta? La capacidad de respuesta significa entender qué tan rápido responden las páginas web a la entrada del usuario. Esto puede significar cosas como cuando intento abrir el menú en un sitio web, ¿cuánto tiempo pasa antes de que realmente suceda algo? O si estoy tratando de agregar algo a mi carrito, ¿cuánto tiempo pasa antes de que pueda ver que se ha agregado mi artículo? Estos son todos 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 el siguiente pintado. Esta es una nueva métrica experimental de capacidad de respuesta. Mide la capacidad de respuesta en tiempo de ejecución, la latencia completa de interacción, 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 ve una respuesta visual, no solo el retraso inicial en el hilo principal.

9. Improving Performance Metrics and Debugging

Short description:

Descubrimos que el 70% de los usuarios tienen una experiencia terrible con la capacidad de respuesta al menos una vez a la semana. Optimizar métricas como el tiempo total de bloqueo y IMP es crucial. IMP se ha introducido en las herramientas de Chrome, incluyendo PageSpeed Insights y Lighthouse. La nueva función Fast Crux proporciona acceso instantáneo a datos de campo. Lighthouse ahora incluye la interacción hasta el siguiente pintado en sus informes, junto con una nueva auditoría llamada Minimizar el trabajo durante la interacción clave. La Extensión de Web Vitals también admite la interacción hasta el siguiente pintado. Siempre estamos trabajando en mejorar las herramientas de depuración de rendimiento, y tenemos una vista previa del experimento de información de rendimiento.

En el laboratorio, el Tiempo Total de Bloqueo es una métrica proxy bastante buena para analizar. Encontramos que se correlaciona bastante bien con la Interacción hasta el siguiente pintado. Una de las cosas buenas de esto es que es automático y viene incluido. La Interacción hasta el siguiente pintado es una métrica de campo principalmente y puede variar según las interacciones que realice un usuario. Esta es una de las razones por las que es genial usar cosas como flujos de usuario, porque te permite saber cuáles son las interacciones clave. Ahora, descubrimos que el 70% de los usuarios tienen una experiencia terrible en cuanto a la capacidad de respuesta al menos una vez a la semana. Esta es realmente una gran oportunidad para mejorar, especialmente dado que la investigación de UX dice que idealmente deberías mirar los 100 milisegundos para la latencia de entrada esperada. Encontramos que los usuarios de escritorio cargan el doble de páginas si experimentan una buena capacidad de respuesta allí. Así que hay muchas razones para optimizar estas métricas. A medida que estas métricas se han ido implementando, también hemos podido proporcionar orientación más concreta. Por ejemplo, si estás utilizando React 18 y envuelves tu interfaz de usuario en límites de suspense, puedes hacer que la hidratación no sea bloqueante porque ocurre en segmentos. Esto puede mejorar cosas como tu tiempo total de bloqueo. Y espero tener aún más orientación concreta para optimizar métricas como el tiempo total de bloqueo y IMP en un futuro cercano. Ahora hemos estado trabajando duro en introducir IMP en muchas de las herramientas de Chrome, comenzando con PageSpeed Insights. Lo primero que te voy a mostrar es una nueva función llamada Fast Crux. Esto te brinda acceso instantáneo a datos de campo. Verás que acabo de hacer clic en analizar. Esto no está acelerado y tienes acceso instantáneo a 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 intervalo de tiempo. Voy a interactuar con una de las experiencias más interactivas de Google, Google Flights, y aquí te voy a mostrar que estoy realizando varias interacciones. He acelerado esto un poco y vamos a terminar nuestro intervalo de tiempo aquí. Y lo que esto nos brinda es un informe de Lighthouse que incluye la interacción hasta el siguiente pintado. Podemos desplazarnos hacia abajo y ver que tenemos una nueva auditoría llamada Minimizar el trabajo durante la interacción clave. Esto incluye nuestra demora de entrada, demora de procesamiento, demora de presentación, así como todas las demás auditorías que Lighthouse suele proporcionar para razonar sobre tareas largas y rendimiento de JavaScript. Por último, hemos trabajado en herramientas como la Extensión de Web Vitals, que sé que a muchas personas les gusta. Esta también tiene ahora la interacción hasta el siguiente pintado. Ahora, en cuanto a la depuración de rendimiento, las personas han estado utilizando el panel de rendimiento durante años y en realidad comenzó en un lugar un poco más simple. Con el tiempo, agregamos gráficos de llama y la capacidad de razonar sobre la profundidad de la pila de llamadas, pero se inclinó un poco hacia herramientas que los ingenieros de navegadores utilizaban para depurar el rendimiento. ¿Podría ser mejor? Tenemos una vista previa de algo en lo que hemos estado pensando. Así que me gustaría presentar

10. Contextual: Stack Packs and Improving Performance

Short description:

Mejorar el rendimiento es un viaje. Pequeños cambios pueden llevar a grandes mejoras. El primer paso puede ser un esquema, el segundo no es una solución repentina. Es el resultado de invertir de forma iterativa en mejorar la experiencia del usuario con el tiempo. Tus usuarios te agradecerán una experiencia de rendimiento mejorada. El futuro de las herramientas de rendimiento es centrado en el usuario, accionable y contextual.

Permíteme presentarte al experimento de información de rendimiento. Esto está disponible como una vista previa que esperamos que revises y no dudes en compartir tus comentarios. Y finalmente tenemos el contexto. Ahora hemos introducido una función llamada stack packs que permite a Lighthouse mostrar sugerencias específicas para la pila de tecnología utilizada. Sabemos que muchas personas suelen utilizar frameworks o CMS al desarrollar, por lo que nos hemos esforzado en asegurarnos de que Lighthouse pueda brindarte un contexto ligeramente mejor si estás utilizando una pila de tecnología moderna. Aquí tienes un ejemplo. En una aplicación que utiliza Next.js, en lugar de simplemente decirte que deberías utilizar un formato de imagen moderno, te diremos que deberías utilizar la API de optimización de imágenes de Next.js para servir formatos modernos como avif. En lugar de decirte simplemente que cargues perezosamente tus imágenes, te diremos que utilices el componente de imagen de Next.js que tiene como valor predeterminado 'loading=lazy'. Cosas realmente poderosas, realmente útiles en contexto. También te diremos cuándo deberías considerar dividir tus paquetes de JavaScript utilizando 'react.lazy' o utilizando una biblioteca de terceros como 'loadable components'. En resumen, mejorar el rendimiento es un viaje. Hay muchos pequeños cambios que pueden llevar a grandes mejoras. El primer paso puede ser un esquema. El segundo definitivamente no es esto. No vas a resolver todos los problemas del mundo de repente. Pero podrías terminar en un punto similar al que suelo estar yo con el rendimiento, que es el paso 1.5. Está bien. Es el resultado de invertir de forma iterativa en mejorar la experiencia del usuario con el tiempo. Eventualmente llegarás a algo más cercano a esto. Pero esto está bien. Aún es bastante bueno. Tus usuarios te agradecerán una experiencia de rendimiento mejorada al final del día. Espero que hayas obtenido algún valor de esta charla. Creo que el futuro de las herramientas de rendimiento es centrado en el usuario, accionable y contextual. Soy Adi Osmani. Muchas gracias.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
JSNation 2023JSNation 2023
29 min
Modern Web Debugging
Few developers enjoy debugging, and debugging can be complex for modern web apps because of the multiple frameworks, languages, and libraries used. But, developer tools have come a long way in making the process easier. In this talk, Jecelyn will dig into the modern state of debugging, improvements in DevTools, and how you can use them to reliably debug your apps.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Vue.js London 2023Vue.js London 2023
49 min
Maximize App Performance by Optimizing Web Fonts
WorkshopFree
You've just landed on a web page and you try to click a certain element, but just before you do, an ad loads on top of it and you end up clicking that thing instead.
That…that’s a layout shift. Everyone, developers and users alike, know that layout shifts are bad. And the later they happen, the more disruptive they are to users. In this workshop we're going to look into how web fonts cause layout shifts and explore a few strategies of loading web fonts without causing big layout shifts.
Table of Contents:What’s CLS and how it’s calculated?How fonts can cause CLS?Font loading strategies for minimizing CLSRecap and conclusion