1. Introducción
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 conozcas de internet por publicar sobre las características de DevTools y hablar sobre el 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.
2. El Futuro de las Herramientas de Rendimiento
Hoy, vamos a hablar sobre el futuro de las herramientas de rendimiento. El deleite puede significar hacer la experiencia más agradable a través de 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 dichas APIs a la plataforma. El futuro de las herramientas de rendimiento es centrado en el usuario, accionable y contextual. Core Web Vitals son tres métricas que cubren la carga, la interactividad y la estabilidad visual. Podemos hacer más para acercar cómo pensamos sobre el rendimiento a la experiencia del usuario.
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.
3. Entendiendo los Flujos de Usuario y el Grabador de DevTools
Estamos evolucionando nuestra comprensión de la experiencia del usuario, incluyendo el rendimiento después de la carga y los flujos de usuario. Los flujos de usuario son una serie de pasos que un usuario realiza para alcanzar un objetivo. Hemos añadido 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 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
4. Reproducción de Flujos y Medición del Rendimiento
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 pueden ser exportados a Puppeteer para pruebas y utilizados con Lighthouse para visualizar pasos, ver auditorías e identificar áreas de mejora.
que estuvieron involucrados. Ahora puedo reproducir ese flujo. No tengo que ir y decirle a cada miembro de mi equipo que lo haga ellos mismos. Puedo pulsar replay. Va a ir de principio a fin y allí vamos. Hemos hecho el checkout. Puedo medir el
performance de este flujo. Así que tenemos un botón de medir
performance aquí. Va a reproducir el flujo entero, generar un rastro de la experiencia de principio a fin y aquí lo tenemos. Estamos en el panel de
performance de
DevTools y puedo hacer zoom en cualquier parte de esa experiencia que quiera 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 algunos bonos. Así que en este caso estoy usando una característica de Lighthouse que nos permite anotar cosas como intervalos de tiempo y capturas de pantalla y a través de Puppeteer soy capaz de obtener este nuevo informe, este informe de flujo. Esto nos permite visualizar todos esos diferentes pasos
5. Importación/Exportación de Flujos de Usuario y Soporte de Lighthouse
En Chrome Canary, el panel del grabador 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 desplazamiento acumulativo de diseño. Encuentra esta poderosa característica en Canary y sácale el máximo provecho.
y ver auditorías para partes de la experiencia que podrían necesitar un poco de trabajo. Ahora en Chrome Canary hemos continuado iterando en este soporte. El panel del grabador ahora también te permite importar y exportar flujos de usuario, incluyendo el uso de JSON. Esta adición hace realmente trivial que puedas comprometer tus flujos de usuario a tu repositorio de GitHub, compartir con los miembros de tu equipo, compartirlo con
QA, y va a 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 que podrías esperar. También en Canary tenemos soporte de panel de Lighthouse para flujos, por lo que puedes seleccionar un lapso de tiempo, puedes iniciar el lapso de tiempo, y comenzar a interactuar con esa experiencia. Esta es la primera vez que te hemos permitido interactuar mientras Lighthouse ha estado funcionando, por lo que puedes interactuar con esta experiencia, puedes personalizar tus productos. Y luego, cuando hayas terminado con la parte del flujo que quieres medir, puedes finalizar el lapso de tiempo. Esto irá y generará una parte de ese informe de flujo y podemos usarlo para descubrir cosas como, ya sabes, ¿necesito hacer un poco más de trabajo en mi desplazamiento acumulativo de diseño, porque tal vez hubo algún desplazamiento de diseño que ocurrió durante mis interacciones. Esto es realmente poderoso,
6. Flujos con Otras Herramientas y Pruebas en Diferentes Navegadores
Ahora exploremos el uso de flujos con otras herramientas. El equipo de web page test tiene un repositorio de scripts de grabador de DevTools a web page test. Al exportar flujos a un archivo cart.json, podemos razonar sobre todo el flujo de usuario, obteniendo información de rendimiento, filmstrips y procesos de carga visual de la página. También podemos utilizar las características de cascada de web page test. Además, cypress.io ofrece un paquete para exportar pruebas de Cypress desde las grabaciones de Chrome DevTools. Esto permite pruebas en diferentes navegadores y reproducción de flujos grabados, permitiendo la depuración y una poderosa interoperabilidad entre navegadores.
puedes encontrarlo en canary y esperamos que lo encuentres útil. Ahora otra pregunta que tuvimos después de trabajar en flujos fue ¿qué pasaría si pudieras usar flujos con otras herramientas? Estoy feliz de compartir algo muy experimental, muy emocionante. Me encanta usar web page test, y el equipo de web page test ha creado un útil repositorio de scripts de grabador de
DevTools a web page test que puedes revisar. Así que digamos que he exportado mi flujo a un archivo cart.json usando uno de los pasos anteriores. Puedo usar esto con este script. Así es como se ve la salida. No es muy interesante, pero vamos a saltar adelante. Y déjame mostrarte lo que esto permite. Podemos pegar esto en nuestra ejecución de web page test y ahora puedo razonar sobre todo mi flujo de usuario. Obtengo información de 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. Soy capaz de desplazarme hacia abajo, soy capaz de usar cualquiera de las grandes características de cascada de web page test para entender los cuellos de botella. Todo esto es realmente genial y nos da un paso hacia la interoperabilidad de herramientas, lo cual me emociona mucho. Aquí, por ejemplo, podemos ver que también tenemos características como los videos de web page test, que me encanta usar. Ahora otra pregunta que nos hacemos es ¿qué pasa con las pruebas de flujos en diferentes navegadores? Tal vez sepas a dónde vamos con esto. Así que cypress.io es una herramienta de automatización de pruebas amigable para el usuario para pruebas de extremo a extremo. Es genial para cosas como pruebas de
UI, suites de regresión, integración y pruebas unitarias. Ahora, el equipo de
Cypress tiene un nuevo paquete especial que puede exportar pruebas de
Cypress desde las 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 de Recorder en mi cart.json. Vamos a seguir adelante y decir que hemos terminado eso. Ahora vamos a ejecutar
Cypress. Veamos qué pasa. Así que npx
cypress open, va a 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 está reproduciendo todo mi flujo en Firefox. Esto es genial. Puedo ir a todos los diferentes pasos y secuencias que estuvieron involucrados en este flujo. Puedo depurar, sabes, qué podría no estar funcionando bien en diferentes navegadores o podría no estar funcionando bien y es realmente poderoso que obtengas este tipo de interoperabilidad entre navegadores
7. Cuenta de Cypress y Grabación
Si tienes una cuenta de Cypress y una clave API, puedes grabar y persistir las grabaciones de flujos en tu panel de Cypress. Puedes compartir y reproducir las grabaciones, proporcionando una experiencia poderosa. ¡Compruébalo!
casi a través de dicha
tooling. Es realmente, realmente genial. Ahora, si tienes una cuenta de
Cypress y tienes una clave API, puedes hacer cosas como usar record para persistir tu grabación de flujo en tu panel de
Cypress. Así que, aquí tienes un ejemplo de eso. Voy a mostrarte algo que hice anteriormente. Aquí, tenemos nuestra experiencia de Añadir al Carrito y podemos ver lo que acabamos de... Ya sabes, donde estamos demostrando. 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 yo mismo. Así que, realmente, realmente poderoso
8. Acción: Nuevas métricas y mejoras en Lighthouse
A continuación, tenemos Acción. Ahora, mencioné antes que estaba emocionado de anunciar mi nueva posición. Ahora, cuando la gente a menudo mira la línea de tiempo, el panel de rendimiento, lo encuentran desalentador. Casi quieren llorar. Ahora, un buen consejo de vida es que si JavaScript no trae alegría a los usuarios, agradézcanlo y deséchenlo. Hemos estado trabajando para asegurarnos de que herramientas como Lighthouse sean lo más accionables posible para los web vitals. Hemos estado trabajando en una nueva métrica de preparación de interacción llamada Interacción hasta la siguiente pintura. Mide la capacidad de respuesta en tiempo de ejecución, la latencia de interacción completa, e incluye toques, arrastres y eventos de entrada de teclado. El tiempo total de bloqueo es una buena métrica a considerar.
cosas. Espero que lo revisen. A continuación, tenemos Acción. Ahora, mencioné antes que estaba emocionado de anunciar mi nueva posición. Así es como me veo cuando estoy mirando rastreos de
performance en
DevTools la mayor parte del tiempo. Me encantan los
DevTools, por cierto. Ahora, cuando la gente a menudo mira la línea de tiempo, el panel de
performance, lo encuentran desalentador. Casi quieren llorar. A veces lloro cuando estoy mirando el panel de
performance. ¿Sabías que hay algo así como 17 músculos que se activan cuando estás llorando? 17 músculos. Genial para el fitness. He estado haciendo algo de eso durante la pandemia también, no voy a mentir. Ahora, cuando estás mirando el panel de
performance, a menudo tienes muchos
data aquí. Aquí tenemos una tarea larga. Si alguna vez te has preguntado por qué el tiempo hasta interactivo no es genial, a menudo es porque las tareas largas de
JavaScript mantienen ocupado el hilo principal. Ahora, un buen consejo de vida es que si
JavaScript no trae alegría a los usuarios, agradézcalo y deséchelo. Estoy bastante seguro de que esto es de un especial de Marie Kondo. De hecho, ella no dijo
JavaScript. Pero creo que este es un buen tipo de consejo Evergreen.
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.
9. Mejorando las Métricas de Rendimiento y Depuración
Descubrimos que el 70% de los usuarios tienen una experiencia terrible con la capacidad de respuesta al menos una vez a la semana. Optimizar para métricas como el tiempo total de bloqueo e IMP es crucial. IMP ha sido introducido en las herramientas de Chrome, incluyendo PageSpeed Insights y Lighthouse. La nueva función Fast Crux proporciona acceso instantáneo a los datos de campo. Lighthouse ahora incluye la interacción hasta la próxima pintura en sus informes, junto con una nueva auditoría llamada Minimizar el Trabajo Durante la Interacción Clave. La Extensión Web Vitals también soporta la interacción hasta la próxima pintura. Estamos trabajando constantemente en la mejora de las herramientas de depuración de rendimiento, y tenemos una vista previa del experimento de insights de rendimiento.
En el laboratorio, el Tiempo Total de Bloqueo es una métrica proxy bastante buena a la que hay que prestar atención. Descubrimos que se correlaciona bastante bien con la Interacción hasta la Próxima Pintura. Una de las cosas agradables de esto es que es automático y está listo para usar. La Interacción hasta la Próxima Pintura es una métrica de campo principalmente y puede variar dependiendo de las interacciones que un usuario esté realizando. Esta es una de las razones por las que es genial usar cosas como los flujos de usuario porque te permite saber cuáles son las interacciones clave.
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
10. Contextual: Stack Packs y Mejorando el Rendimiento
Mejorar el rendimiento es un viaje. Pequeños cambios pueden llevar a grandes ganancias. El primer paso podría ser un esquema, el segundo paso no es una solución repentina. Es el resultado de invertir iterativamente en mejorar la experiencia del usuario con el tiempo. Tus usuarios te agradecerán por una experiencia de rendimiento mejorada. El futuro de las herramientas de rendimiento es centrado en el usuario, accionable y contextual.
te presento el experimento de insights de
performance. Esto está disponible como una vista previa y esperamos que lo revises y te sientas libre de compartir tus comentarios. Y finalmente tenemos lo contextual. Ahora hemos introducido una característica llamada stack packs que permite a Lighthouse mostrar
suggestions específicas del stack. Sabemos que mucha gente a menudo está usando
frameworks o CMSs cuando están construyendo cosas y por lo tanto hemos estado trabajando duro para asegurarnos de que Lighthouse pueda empezar a darte un contexto un poco mejor si estás usando un stack moderno. Aquí tienes un ejemplo. Así que en una aplicación que está usando
Next.js en lugar de simplemente decirte que deberías estar usando un formato de imagen moderno, te diremos que deberías estar usando la API de
optimization de imagen de
Next.js para servir formatos modernos como avif. En lugar de decirte simplemente que cargues tus imágenes de forma perezosa, te diremos que uses el componente de imagen de
Next.js que por defecto tiene la carga igual a perezosa. Cosas realmente poderosas, cosas realmente contextuales. También te diremos cuándo deberías considerar dividir tus paquetes de
JavaScript usando react.lazy o usando una biblioteca de terceros como loadable components.
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.
React Summit 2023
Comments