Aplicaciones web de alta velocidad: más allá de lo básico

Rate this content
Bookmark

Saber cómo ejecutar pruebas de rendimiento en tu aplicación web de manera adecuada es una cosa, y aprovechar esas métricas de manera efectiva es otra. Y ambos aspectos son cruciales para el éxito general de tus esfuerzos de optimización de rendimiento. Sin embargo, a veces puede ser todo un desafío, ya que implica tener un entendimiento preciso de todos los detalles tanto de los datos de rendimiento como de las herramientas de rendimiento. Esta charla arrojará luz sobre cómo superar este desafío y te guiará a través de los obstáculos y trucos del oficio de Chrome DevTools, brindándote una hoja de ruta completa para el análisis y optimización de rendimiento.

30 min
20 Jun, 2022

Video Summary and Transcription

Esta charla cubre las últimas características de Chrome DevTools, incluyendo el análisis de la pestaña de red, la optimización de la pestaña de rendimiento y los flujos de usuario. Se discute la optimización de las solicitudes HTTP con prioridad de búsqueda para mejorar el tiempo de carga. La pestaña de rendimiento proporciona información sobre caídas de fotogramas, tareas largas y la importancia de minimizar el tiempo total de bloqueo. La charla también destaca la optimización de la representación de la página e introduce los flujos de usuario en Chrome DevTools.

Available in English

1. Introduction to Chrome DevTools

Short description:

Hola y bienvenidos a mi charla, Aplicaciones web de alta velocidad más allá de lo básico. Cubriré las últimas características en Chrome DevTools, incluyendo el análisis de la pestaña de red, la optimización de la pestaña de rendimiento y los flujos de usuario. Comencemos con la pestaña de red, donde puedes analizar las solicitudes HTTP y utilizar la prioridad de fetch para optimizar el contenido. En la pestaña de rendimiento, demostraré optimizaciones utilizando la visibilidad y programación de contenido. Por último, presentaré los flujos de usuario y presentaré las últimas herramientas para medir el rendimiento en tiempo de ejecución.

Hola y bienvenidos a mi charla, Aplicaciones web de alta velocidad más allá de lo básico, una charla sobre las últimas y mejores características en Chrome DevTools. Permítanme presentarme rápidamente. Mi nombre es Michael, Michael Lutke. Muy difícil de leer, escribir y pronunciar, así que quedémonos con Michael. Lo que hago es consultorías, capacitaciones y masterclasses en el campo de las optimizaciones de rendimiento, Angular y programación reactiva. También dirijo una empresa llamada Pushbased. Pueden visitarla, simplemente hagan clic en el enlace en mis diapositivas. Pero ahora veamos qué hay en la agenda. En primer lugar, hablaré sobre la pestaña de red. Les mostraré lo que pueden ver en la pestaña de red y luego intentaré ver algunas de las últimas características. Una de las características geniales que se envían en Chrome es la prioridad de fetch y utilizaré la prioridad de fetch para optimizar el contenido más grande para la pintura con una imagen, así como con las solicitudes HTTP. Más adelante les mostraré cómo ver la pestaña de rendimiento. Esto no es realmente fácil porque hay mucha información y espero o mejor dicho, prometo que después de la charla podrán al menos tener un poco más de comprensión sobre lo que verán allí y qué buscar. Para demostrar algunas optimizaciones en la pestaña de rendimiento, utilizaré la visibilidad de contenido, una característica de CSS muy interesante y también les presentaré la programación y fragmentación del trabajo en el hilo principal. Al final de mi charla, algunas cosas realmente emocionantes de las que quiero hablar son los flujos de usuario. El flujo de usuario es básicamente una nueva herramienta que actualmente solo está disponible en Canary Chrome y nos permite medir el rendimiento en tiempo de ejecución de formas completamente nuevas. Al final, les presentaré las últimas y mejores herramientas sobre el flujo de usuario, cómo usarlas y también cómo integrar esas cosas en su CI. Sin más pausas, pasaré directamente al análisis de red y la pestaña de red. Entonces, lo que ven aquí en esta herramienta es, en primer lugar, seleccioné la pestaña de red y luego tienen mucha información presente. Mucha información sobre todas las solicitudes HTTP que se realizan desde su aplicación. Y si observan más de cerca la parte derecha de esa diapositiva, verán el diagrama de cascada. En el diagrama de cascada, básicamente ven un gráfico de barras de tiempo que muestra todas nuestras solicitudes HTTP, su inicio, su final y el tiempo que están compuestas. Si pasan el cursor sobre una de esas pestañas, verán el tiempo de la solicitud. Y el tiempo de la solicitud puede mostrarles información sobre el tiempo de conexión, cuántos datos había y todos los demás tiempos y duraciones que fueron necesarios para recibir todos esos datos. En esta diapositiva ven una columna que básicamente nos habla sobre la prioridad de las solicitudes HTTP. Podemos ver que algunas de esas solicitudes HTTP son más importantes, tienen una prioridad más alta que otras, y quiero aprovechar una de las últimas características, la Prioridad de Fetch, para demostrar lo que se puede lograr con la prioridad en su aplicación. Sin más información en la pestaña de red, pasaré directamente a la práctica y les mostraré cómo podemos cambiar todas las solicitudes que se realizan y cómo podemos mejorarlas. Una de las primeras cosas que quiero mejorar, también visible en la pestaña de red, es el tiempo de conexión. En esta diapositiva ven en la parte superior una versión no optimizada de dos solicitudes HTTP a dos dominios diferentes y como pueden ver, hay un bloque naranja que se conecta y luego un bloque azul que se descarga, otro bloque naranja que se conecta y otro bloque azul que se descarga. Entonces, si aprovechamos el atributo pre-connect en nuestros enlaces, básicamente le decimos al navegador, mira a esos dos puntos finales de la API, realizaremos solicitudes en el futuro, así que ¿por qué no estableces la conexión justo al comienzo de la aplicación y luego podemos ahorrar tiempo de conexión más tarde?

2. Optimización de las solicitudes HTTP con prioridad de fetch

Short description:

Esta sección trata sobre la paralelización de bloqueos de conexión, la prioridad de las solicitudes HTTP y el uso de la prioridad de fetch para optimizar la pintura más grande y significativa de una imagen. El ejemplo demuestra la mejora en el tiempo de carga y la importancia de tener la pintura más grande y significativa al principio. La siguiente optimización implica aprovechar la prioridad de fetch en las solicitudes HTTP.

en adelante. Esto se demuestra en la parte inferior de la imagen y se puede ver que ambos bloqueos de conexión ahora se paralelizan desde el principio y todo el gráfico es mucho más corto. Lo siguiente, y esto es lo nuevo y genial, es la prioridad de esas solicitudes HTTP. Nuevamente, en este gráfico se muestra una versión no optimizada en la parte superior, alguna ejecución de script, algunas solicitudes de recursos A, solicitudes de recursos B y luego la renderización. Por supuesto, la renderización de una imagen es más importante que ejecutar algún script o solicitar algunos recursos que se utilizan más adelante. Entonces, lo primero que debemos hacer es hacer que todos los bloques de script amarillos sean asíncronos y no bloqueantes. Esto se puede lograr mediante los atributos defer, preload, o prefetch. Deferir scripts significa mover ese script al final de la cola y continuar con el procesamiento, con el análisis de su HTML. Y la precarga y el prefetch básicamente significa que intento obtener datos al principio de, digamos, la parte que no es visible en la página. Entonces, la precarga sería precargar recursos que se acceden en un momento posterior en esta misma página. Y el prefetch podría significar precargar algunas cosas que se utilizan después de una navegación. Con esas tres cosas ya podemos avanzar mucho, pero hay otra característica realmente genial y muy útil: la prioridad de fetch. Con la prioridad de fetch, básicamente podemos determinar qué solicitudes HTTP tienen más prioridad que otras y quiero usarla para actualizar la pintura más grande y significativa de una imagen. Si observamos este fragmento de código aquí, vemos dos enlaces que solicitan algunas imágenes de héroe y una de esas dos imágenes es más importante que la otra. Normalmente, solo por el orden del contenido HTML, primero solicitaríamos la imagen de héroe 1 y más adelante la imagen de héroe 2. Pero ahora, con la prioridad de fetch, podemos indicarle al navegador que la segunda imagen, aunque sea más adelante en el tiempo, tiene más prioridad que la primera y el navegador cambiaría la ejecución de esas dos solicitudes HTTP y solicitaría la segunda antes en el tiempo. ¿Cómo se vería eso en la práctica? Tomé ObservableHQ como un sitio web ficticio y lo que vemos aquí es una imagen de video, o como dije, una pequeña imagen de un video que comenzaremos a reproducir más adelante y esto es definitivamente la pintura más grande y significativa, la parte más importante que el usuario debería ver al principio. Al aplicar algunos ajustes al HTML y usar la precarga, obtenemos la siguiente mejora. Entonces, lo que ven en la parte superior es la primera línea de esta tira de películas que muestra la página predeterminada y la segunda línea de esta tira de películas muestra cuál es el resultado de mi optimización. Hay dos cosas diferentes. En primer lugar, todo el gráfico ahora es mucho más corto. Básicamente, pasé de 7 segundos en total a 4.5 segundos. Pero la parte realmente importante e interesante aquí es que la pintura más grande y significativa ahora está presente al principio. Pasé de 7 segundos de la pintura más grande y significativa, que se puede ver aquí en la parte superior, a 2.5 segundos. Esto también es visible aquí en el diagrama detallado en la parte inferior. Y pueden ver que la imagen es realmente lo primero visible y luego de eso hay algunas solicitudes. Pero la imagen siempre es visible y brinda una experiencia de usuario muy agradable para los usuarios que desean consumir este video o al menos quieren ver un primer vistazo.

La siguiente optimización que quiero hacer es aprovechar la prioridad de fetch en las solicitudes HTTP. Entonces, cuando usas la API de fetch, ahora también puedes darle una importancia a esta solicitud HTTP y esto se hace simplemente aplicando otra configuración como se muestra aquí. Con esta técnica, veamos qué hice en la práctica con ella. Si observamos la página, vemos dos contenidos dinámicos diferentes en la página.

3. Optimización de carga con prioridad de fetch

Short description:

Podemos optimizar el orden de las solicitudes HTTP utilizando la prioridad de fetch, asegurando que el contenido crítico se obtenga primero. Esta característica nos permite mejorar el tiempo de carga de nuestras aplicaciones web.

Vemos una lista de películas y un menú lateral con una sección que está compuesta por elementos de menú obtenidos dinámicamente. Y como pueden ver, esas solicitudes HTTP se realizan bastante tarde en el tiempo. Entonces, cuando aplico la prioridad de fetch y observan la siguiente diapositiva, pueden ver que moví estas cosas al principio y también pude cambiar básicamente el orden de esas dos solicitudes HTTP para que las imágenes de la lista de películas se obtengan primero y después la lista dinámica en el menú lateral. Bastante genial, cosas emocionantes. Todo lo que vieron es básicamente posible con esta nueva y genial característica, la Prioridad de Fetch.

4. Performance Tab and Long Tasks

Short description:

A continuación, profundizaremos en la pestaña de rendimiento, que proporciona información valiosa pero puede ser compleja de interpretar. Exploraremos las caídas de fotogramas, las tareas largas y la importancia de permitir que el navegador procese las interacciones del usuario rápidamente. Las tareas largas se identifican mediante áreas rojas o triángulos rojos, y la vista general en la parte superior muestra la velocidad de fotogramas por segundo. Nuestro objetivo será minimizar las tareas largas y el tiempo total de bloqueo para mejorar el rendimiento.

¿Qué sigue? A continuación está la pestaña de rendimiento. La pestaña de rendimiento es una de las más informativas, pero también una de las gráficas más complicadas de leer cuando se trata de herramientas de rendimiento. En la siguiente diapositiva, quiero darles un vistazo de lo que pueden observar y también cómo mejorar eso. Comencemos con qué es una caída de fotogramas o una tarea larga. En primer lugar, un usuario siempre desea interactuar con su página. La interacción implica hacer clic, desplazarse o cualquier otra cosa que pueda ocurrir en el teclado o a través del teclado. Una de las partes más importantes es darle al navegador la oportunidad de procesar esas interacciones siempre que sea necesario o, digamos, lo más rápido posible. Si observan el gráfico, verán cajas grises y esas cajas grises son tareas. Una tarea es básicamente una unidad de trabajo que el navegador necesita procesar antes de poder hacer cualquier otra cosa, por ejemplo, reaccionar a una entrada del usuario. Podemos identificar esas tareas largas, tareas que tardaron demasiado en bloquear la entrada del usuario o el procesamiento de la entrada del usuario, mediante esta área roja o mediante el pequeño triángulo rojo que pueden ver en la parte superior derecha aquí. Otro lugar donde pueden identificar eso es también la vista general en la parte superior, allí verán estas barras rojas y las ondulaciones verdes, y esas dos cosas básicamente nos indican A dónde están nuestras tareas largas y B cómo es la velocidad de fotogramas por segundo y si la velocidad de fotogramas es constante, podemos asumir que nuestras tareas no están bloqueando demasiado. En la parte inferior número 3, verán una vista general en este caso del tiempo total de nuestras tareas largas y su tiempo de bloqueo, y el tiempo total de bloqueo es una de las medidas más importantes en, por ejemplo, la puntuación de Lighthouse y siempre debemos tratar de reducir las tareas largas o el tiempo total de bloqueo al mínimo.

5. Understanding Single Tasks and Long Tasks

Short description:

Ahora vamos a acercarnos y entender cómo se ve una sola tarea. El cuadro gris marca la tarea y el color indica el tipo de trabajo. Vemos los detalles de lo que se ha programado, diseñado o pintado. Las tareas largas se marcan con un triángulo rojo e indican tiempo extra. Nuestro objetivo es eliminar las tareas que duren más de 50 milisegundos.

Ahora vamos a acercarnos un poco más y entender cómo puede verse una sola tarea. En esta imagen vemos una tarea en detalle. Vemos que en la parte superior hay un cuadro gris. El cuadro gris marca, por supuesto, la tarea, pero lo que también vemos es el tipo de trabajo. Amarillo, morado o verde. Programación, diseño o pintura. Debajo de todo eso puedes ver los detalles. ¿Qué exactamente se ha programado? ¿O qué exactamente se ha diseñado o pintado? En esta diapositiva vemos que esta tarea se marca como una tarea larga y vemos el área de tiempo extra en estas líneas rojas punteadas, o no punteadas, pero afiladas, y luego también vemos la marca de tarea larga, el triángulo rojo en la esquina superior derecha de cada cuadro gris de cada tarea que se marca como una tarea larga. Esta información es muy importante para nosotros porque esto es lo que necesitamos eliminar. Lo que necesitamos eliminar es todo lo que dure más de 50 milisegundos. Como puedes ver aquí, 50 milisegundos es una tarea larga aceptable y todo lo que esté por encima de los 50 milisegundos es básicamente el tiempo extra de una tarea.

6. Optimizing Page Relay Outing and Paint

Short description:

Con las últimas funciones del navegador disponibles en Edge y Chrome, podemos optimizar la salida y pintura de la página. Las mediciones de laboratorio muestran mejoras significativas en los tiempos de pintura y diseño. Los datos de campo demuestran el impacto de optimizar el tiempo de renderizado e introducen la programación y el presupuesto de cuadros para reducir el tiempo total de bloqueo. También se muestra la optimización del tiempo total de bloqueo y la demora de entrada, junto con la emocionante nueva función de Flujos de Usuario en Chrome DevTools.

Con toda esa información en mente, pasemos a la salida y pintura de la página. Esto es lo que quiero mostrarte cómo optimizar, y quiero utilizar las últimas funciones del navegador disponibles en Edge y también en Chrome. En esta presentación de diapositivas, puedes ver en CanIUse dónde es compatible y ya te he dicho que, desafortunadamente, solo es compatible con Edge y Chrome, pero todos los demás navegadores están trabajando mucho para implementarlo.

Ahora que entendemos dónde se puede usar, veamos cuál podría ser el impacto potencial. Aquí tenemos una medición de laboratorio de una página en un estado no optimizado, una página optimizada con visibilidad de contenido o nodos en pantalla, lo que significa que todo el contenido es visible dentro de la página, y luego todo el contenido fuera de pantalla, lo que significa que está debajo del tamaño de tu pantalla y no es visible para el usuario en ese momento. Si observamos los números, los números superiores están en verde, que representan la pintura, por lo que podemos pasar de una pintura no optimizada de seis milisegundos a una pintura optimizada en pantalla de un milisegundo y fuera de pantalla realmente, realmente rápida, de 0.1 milisegundos fuera de pantalla. Este es realmente un impacto interesante, diría que tremendo. Aún más interesante para el diseño, esta es la parte inferior de la diapositiva, puedes ver 11 milisegundos para actualizar el árbol de capas y pintar con la optimización todo en pantalla 0.5 milisegundos y luego todo fuera de pantalla es solo 61 microsegundos, lo cual es un número realmente interesante y un impacto dramático. Si bien las mediciones de laboratorio son útiles para aprender y comprender, lo que realmente nos interesa son los datos de campo. Así que veamos lo que logré en la práctica. La optimización del tiempo de renderizado es lo primero que quiero mostrarte, y en la siguiente diapositiva vemos nuevamente desde observable HQ en la parte superior alguna animación y trabajo de diseño que está presente aquí. Y la tarea más larga en este trabajo de diseño tomó básicamente 260 milisegundos. Por supuesto, es una tarea larga porque dura más de 50 milisegundos y con mi aplicación de visibilidad de contenido pude reducirlo a 15 milisegundos para el mismo trabajo realizado en el mismo sitio web. Esto es una mejora tremenda y realmente bueno ver lo que es posible con solo uno o dos pequeños cambios en tu aplicación. Lo siguiente que quiero demostrar o presentarte es la programación y el presupuesto de cuadros. Esto es especialmente importante para eliminar o al menos reducir el tiempo total de bloqueo de la ejecución de scripts. Lo que vemos en esta diapositiva es la programación del trabajo y cómo podría mejorar la entrada hasta el siguiente pintado, el tiempo total hasta la interactividad y el tiempo total de bloqueo. Imagina que hay un clic en un botón y ese clic en el botón causaría algún trabajo y en lugar de ejecutar ese trabajo de inmediato, tomo ese paquete de trabajo y lo muevo a la siguiente tarea, al siguiente cuadro gris, y lo ejecuto más tarde en el tiempo. En este ejemplo específico, utilicé el marco de animación para realizar la actualización porque era una actualización visual que cambiaba algunos píxeles pero esto básicamente también es posible con muchas otras APIs de programación. Lo que se marca aquí es el momento de programación en el tiempo y la duración de la programación. Veamos qué mejoraría teóricamente. Lo que vemos aquí en la línea horizontal punteada de color rosa intenso es el siguiente momento posible en el que el navegador podría procesar la interacción del usuario. Esto es una mejora muy buena y también aumentó el tiempo hasta la interactividad en cantidades tremendas como puedes ver en este primer paréntesis aquí y también redujimos el tiempo total de bloqueo en 50 milisegundos porque cada tarea está bien si dura menos de 50 milisegundos y ahora tenemos dos en lugar de una tarea. Mejoras realmente asombrosas y esto es solo la teoría. En la práctica, la optimización del tiempo total de bloqueo y la demora de entrada es lo siguiente que quiero mostrarte y en este ejemplo quiero demostrar nuevamente la aplicación de películas y la inicialización de esa aplicación. Si observamos este diagrama aquí, básicamente vemos una tarea enorme que está procesando algunos archivos JavaScript y luego ejecutando el framework. Después de algunas optimizaciones en la parte izquierda, todavía tenemos una tarea un poco grande porque optimizar un paquete de webpack y su compilación no es tan fácil, pero todo lo que está en el ámbito del framework ahora está optimizado y podemos ver muchas líneas verticales punteadas de color rosa intenso y esas básicamente son todas tareas separadas que permiten al navegador procesar la entrada del usuario y como puedes ver, todas esas tareas no son tareas largas, por lo que son mejoras realmente, realmente asombrosas que podríamos lograr con la programación y la fragmentación. Lo último y más emocionante que puedo demostrarte son los Flujos de Usuario. Los Flujos de Usuario son una de las nuevas y elegantes funciones que Chrome DevTools lanzará, actualmente solo se puede acceder en Chrome Canary, pero debes saber que hay una biblioteca de código abierto que puedes usar e instalar desde hoy y ejecutar todas esas cosas nuevas de manera totalmente estable en tu CI o desde tu CLI. El enlace aquí es

7. Flujos de Usuario y Chrome Lighthouse

Short description:

¿Qué son los flujos de usuario? Chrome Lighthouse ahora permite tres modos de medición: navegación, intervalo de tiempo y captura instantánea. El modo de medición de intervalo de tiempo te permite grabar las interacciones del usuario dentro de una duración específica. Un informe de flujo de usuario en Chrome DevTools muestra múltiples pasos, como ordenar café en línea. El visor de informes muestra la navegación a la aplicación del carrito de café y los detalles del intervalo de tiempo grabado para seleccionar un café.

github.com slash push dash based slash user flow. Por favor, echa un vistazo, muy interesante. Entonces, ¿qué son los flujos de usuario? Si te imaginas que Chrome tiene esta herramienta llamada Chrome Lighthouse y Lighthouse hasta ahora solo podía medir el performance de inicio que medía el momento en que navegabas a una página por primera vez, y esto siempre era una navegación en frío y siempre, como dije, estaba limitado solo al performance de inicio. Con la versión 9 algo, Lighthouse ahora permite 3 modos de medición: navegación, intervalo de tiempo y captura instantánea. La navegación es básicamente la medición predeterminada de Lighthouse que ha estado presente desde siempre. Por lo tanto, cualquier medición era una medición de navegación o modo de navegación hasta la versión 9. El segundo modo de medición muy interesante y para mí el más emocionante es el modo de medición de intervalo de tiempo, donde puedes comenzar y detener la grabación durante una duración de tiempo y dentro de esa duración de tiempo puedes ejecutar algunas interacciones de usuario. Por ejemplo, completamente automatizado con Puppeteer. Y al final vemos la captura instantánea, que básicamente es una forma de tomar una captura de tu página en cualquier momento. Y es muy útil para determinar medidas de accessibility y otras cosas estáticas en un momento posterior, no solo en la navegación. Veamos cómo podría verse esto en la práctica. Lo que ves aquí y en un segundo te lo mostraré en vivo es un informe de flujo de usuario, básicamente un informe que se parece bastante a un informe de Lighthouse, pero como puedes ver tiene varios pasos diferentes. Y lo que hice aquí básicamente fue ordenar un café en línea. Permíteme salir rápidamente de las diapositivas y mostrarte cómo se ve este informe en la vida real. Abriré las herramientas de desarrollo de Chrome y, con suerte, si no cometo un error, podré arrastrar y soltar el informe directamente aquí. Como puedes ver, ¡pop! Este es el visor de informes de Lighthouse normal y ya admite flujos de usuario. El primero, déjame hacer clic en resumen, es una navegación a esta aplicación de carrito de café y yo abriré la aplicación para que puedas ver una aplicación muy primitiva. Puedo seleccionar un café, hacer clic en eso, ingresar algunos datos de usuario y luego ordenar básicamente un café. Veo el mensaje de confirmación en la parte inferior y eso es todo. Lo que quería grabar. Entonces volvamos y veamos esto. Lo que hice fue una navegación a esta página y por los números puedes ver que este es un puntaje de Lighthouse predeterminado. Puedo hacer clic en él y ver los detalles completos. Tengo todos mis web vitals aquí, algunas imágenes, el tiempo, el mapa de árbol y todos los diagnósticos visibles en la parte inferior. En un momento posterior, grabé el intervalo de tiempo de seleccionar un café. Desde un café no seleccionado hasta pasar el cursor sobre un café y luego hacer clic en ese café y seleccionarlo. Esto se grabó aquí. Como puedes ver, nos proporciona un número reducido de nuestra grabación. Vemos el tiempo total de bloqueo, los cambios de diseño acumulativos y otras cosas.

8. Userflow Insights and Conclusion

Short description:

Después de seleccionar un café, quería asegurarme de que se cumplieran la accesibilidad, los términos de CO y las mejores prácticas. Los números muestran una reducción, pero aún proporcionan información valiosa. Hay más mediciones para el proceso de pago y el envío del pedido. Recomiendo consultar el enlace de GitHub para Userflow. Gracias por su tiempo.

Y si sigo desplazándome hacia abajo, también vemos todas las grabaciones detalladas. La última es una captura de pantalla de la selección de un café. Así que después de seleccionar un café, quería asegurarme, ¿se sigue cumpliendo la accessibility? ¿Se cumplen los términos de CO, sigue siendo una buena práctica? Y como puedes ver, estos números aquí nos muestran que se ha reducido, pero aún nos brinda mucha información sobre lo que podemos hacer con estas nuevas herramientas. Por supuesto, hay más mediciones, nuevamente, más tiempo invertido en el proceso de pago, otra captura de pantalla para el proceso de pago, más tiempo invertido en el envío del pedido y otra captura de pantalla para el envío del pedido. Herramientas realmente útiles. Recomiendo encarecidamente que consultes el enlace anterior en GitHub push-based con una barra diagonal y flujo de usuario, y ya puedes usarlo directamente en tu proyecto, CLI, o incluso CI.

Permíteme volver a las diapositivas y abrirlas a pantalla completa. Y permíteme decirte, gracias por tu tiempo. Este es el final de esta charla muy pequeña, densa y breve sobre algunas de las últimas y mejores características. Sé que fue bastante en poco tiempo. Así que si tienes alguna pregunta, no dudes en enviarme un correo electrónico, michael.latki8-push-based.io. También estoy en Twitter y probablemente más activo en Twitter que en cualquier otra plataforma. Y nuevamente, el enlace de GitHub a la última y mejor característica, Userflow, por favor, échale un vistazo. Y nuevamente, muchas gracias por tu tiempo y nos vemos más tarde. Disfruta el resto de la conferencia. 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
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

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