Rendimiento de HTTP/3 para desarrolladores de JS

Spanish audio is available in the player settings
Rate this content
Bookmark

HTTP/3 es el nuevo protocolo de red de moda, ¡disponible hoy! Si bien obtienes la mayoría de sus beneficios de forma predeterminada, también hay algunas cosas que puedes y debes hacer para maximizar el rendimiento.


En esta charla, analizaremos la optimización de las cargas útiles de JS para las primeras rondas de red, cómo los navegadores priorizan JS frente a otros tipos de recursos, las sutilezas de SPA vs MPA y cómo utilizar de manera óptima las funciones de 0-RTT y 103 Early Hints. También veremos la integración del protocolo con fetch() y hablaremos sobre el próximo WebTransport.

21 min
05 Jun, 2023

Video Summary and Transcription

HTTP 3, también conocido como H3, es la última versión del protocolo HTTP con nuevas características relacionadas con el rendimiento. Habilitar HTTP 3 requiere un esfuerzo mínimo y proporciona beneficios significativos, pero limita el control detallado sobre las características de rendimiento. Zero RTT tiene limitaciones debido a razones de seguridad y restricciones en las solicitudes permitidas. La carga y priorización de recursos en HTTP 3 tienen algunos problemas, ya que los navegadores pueden no estar de acuerdo en la importancia de los recursos. La prioridad de fetch permite un control detallado sobre el orden de carga de los recursos y el descubrimiento de recursos se puede mejorar con 103 Early Hints. WebTransport proporciona acceso de bajo nivel a las características de QUIC y HTTP3 para casos de uso en tiempo real.

Available in English

1. Introducción a HTTP 3

Short description:

Hola, soy Robin Marks y trabajo en Akamai. Hoy me gustaría hablar sobre HTTP 3, la última versión del protocolo HTTP. HTTP 3, también conocido como H3, tiene muchas características nuevas relacionadas con el rendimiento que lo hacen más eficiente que H2 y TCP. Habilitar HTTP 3 requiere un esfuerzo mínimo y proporciona beneficios significativos. Sin embargo, también limita el control detallado sobre las características de rendimiento, como la API Fetch de JavaScript y la función de cero RTT.

Hola, soy Robin Marks y trabajo en Akamai. Y me gustaría hablarles hoy un poco sobre HTTP 3, que es la última y mejor versión del protocolo HTTP.

Y como pueden ver, es bastante diferente de HTTP 2. Uno de los grandes cambios que ocurrieron fue que ya no usamos TCP como base. Pero nos hemos movido a un nuevo protocolo de transporte llamado QUIC. QUIC en sí, que se ejecuta sobre UDP. Realmente no necesitan conocer todos estos detalles.

Lo principal que necesitan saber hoy es que QUIC y H3 tienen muchas características nuevas relacionadas con el rendimiento a bordo, cosas que lo hacen mucho más eficiente que H2 y TCP, y que ayudan a que sus páginas web se carguen mucho más rápido. Ahora, podrían pensar, oh, esto parece interesante, pero probablemente será mucho trabajo para mí, ¿verdad, empezar a usar todas estas nuevas características? Bueno, ahí es donde llegan las buenas noticias. Eso no es cierto. Básicamente, si simplemente habilitan HTTP 3, que a menudo es solo cambiar un interruptor, obtienen todas estas características de forma predeterminada. De hecho, ni siquiera tienen que cambiar nada en sus páginas web para aprovechar al máximo, siempre y cuando ya estén optimizadas para HTTP 2, lo cual, siendo honestos, después de ocho años, realmente deberían estarlo. Esto debería funcionar muy bien en HTTP 3 también. Así que esto es bastante bueno. Pueden obtener todos los beneficios con poco esfuerzo.

Sin embargo, también hay un inconveniente en esto, porque significa que no tienen mucho control detallado sobre estas nuevas características geniales de rendimiento. Un buen ejemplo de esto es la API Fetch de JavaScript, de la cual probablemente todos saben que solo tienen acceso a la opción superior. No hay forma de decir explícitamente que les gustaría usar HTTP3 en lugar de HTTP2 para una llamada. Esto es algo que decide el propio navegador basado en algunas heurísticas internas bastante complejas. Así que no pueden pasar un parámetro de protocolo o no hay fetch HTTP3. Y gracias a Dios, la última línea aquí no es algo por lo que optamos, no es una URL específica de HTTPS3. Eso hubiera sido absolutamente loco. Otro ejemplo de esto es la función de cero RTT. Esta es una de las nuevas características principales de rendimiento en H3 en el sentido de que acorta un poco la configuración de la conexión. Entonces, para H2 en TCP, esto normalmente toma tres rondas individuales en la red antes de comenzar a recibir datos HTTP. Quick en H3 reduce esto a solo dos rondas porque Quick puede combinar el transporte y el apretón de manos criptográfico TLS en una ronda. Y luego está esta nueva función mágica llamada cero RTT donde ya pueden hacer una solicitud HTTP 3 y obtener alguna respuesta en la primera ronda de la conexión que es lo más rápido que podemos hacer. Todo esto suena muy bien pero nuevamente realmente no tienen mucho control sobre si, por ejemplo, se utiliza cero RTT en, digamos, una llamada fetch. No hay forma de habilitar o deshabilitar esto.

2. Limitaciones de Zero RTT

Short description:

El navegador y el servidor determinan las limitaciones de cero RTT por razones de seguridad. A menudo está limitado en muchas implementaciones y tiene restricciones sobre los tipos de solicitudes permitidas. La falta de control puede llevar a que el navegador envíe solicitudes incorrectas, lo que resulta en un potencial desperdiciado. Si bien obtienes las características de forma gratuita, no está exento de limitaciones.

Esto es algo que el navegador elige por ti. Y en este caso no solo es el navegador, también es el servidor el que te va a guiar. Por algunas razones complejas relacionadas con la security seguridad, el cero RTT a menudo está bastante limitado en muchas implementaciones. Por ejemplo, el código que tengo aquí dice que solo puedes usar solicitudes get sin parámetros de consulta en una solicitud de cero RTT. Lo cual, como puedes imaginar, realmente reduce la cantidad de casos de uso en los que puedes utilizar esto. Por ejemplo, es prácticamente inútil para la mayoría de las solicitudes relacionadas con API. Y nuevamente, debido a que no tienes mucho control sobre esto, es posible que el navegador se equivoque. El navegador envía un tipo incorrecto de solicitud en cero RTT. El servidor la rechazará y el navegador tendrá que volver a intentarlo después de ese primer viaje de ida y vuelta. Desperdiciando así el potencial de cero RTT. Entonces sí, obtienes todas las características de forma gratuita. Pero no es tan increíble como parece.

3. Resource Loading and Prioritization

Short description:

Quiero hablar sobre cómo cargamos recursos individuales en una página y cómo priorizamos cuándo deben cargarse. HTTP 3 utiliza un mecanismo simple para asignar prioridades a los recursos, pero hay algunos problemas con este enfoque. Los navegadores pueden no estar de acuerdo sobre la importancia de los recursos y su priorización puede diferir de lo que los desarrolladores esperan.

Ahora, por supuesto, no quiero hablar solo de las cosas que no puedes hacer con H3. Quiero hablar de las cosas que sí puedes hacer. El navegador te protege de estos detalles internos. El protocolo es como una caja negra. Pero te brinda características de nivel superior que puedes usar para ajustar algunos de estos comportamientos. Y me gustaría hablar de algunas de estas contigo hoy.

La primera se trata de cómo cargamos recursos individuales en una página y cómo priorizamos cuándo deben cargarse. Como probablemente sabes, HTTP 2 y también H3 utilizan solo una conexión de red para cargar todos los recursos. Esto significa que debemos decidir de alguna manera en qué orden se cargan los recursos en esa única conexión. Podrías pensar en una solución muy ingenua que los cargue en el orden en que aparecen en el HTML pero eso sería bastante inflexible en la práctica. Y también puedes ver que hay muchas opciones diferentes en las que podrías decidir enviar estos recursos. No tiene que ser solo secuencial uno tras otro.

Entonces, ¿qué sucede en la práctica? ¿Quién decide cómo se hace esto? Bueno, esto lo deciden los navegadores. Para cada solicitud que realiza el navegador se le asigna lo que se llama una prioridad. Una indicación de la importancia del recurso y cuándo debe cargarse. Al menos en HTTP 3, este es un mecanismo muy simple. Es solo una cabecera de solicitud HTTP con un nombre muy predecible: prioridad. Incluso puedes ver esto en las herramientas de desarrollo del navegador. Una prioridad tiene solo dos parámetros. Un parámetro de urgencia que es solo un número que indica la importancia y luego un parámetro incremental que indica si este recurso se puede mezclar con datos de otros recursos o no. Ahora, los detalles no son muy importantes para nosotros hoy.

Lo que es más importante e interesante es que hay algunos problemas con este enfoque. En primer lugar, los navegadores no necesariamente están de acuerdo sobre qué recursos deben ser más importantes. Y en segundo lugar, incluso si están de acuerdo, pueden llegar a una solución diferente a la que tú, como desarrollador, podrías esperar intuitivamente. Así que veamos algunos ejemplos de esto. Hace unos meses, analicé cómo los navegadores hacen esta priorización. Y aquí puedes ver la línea superior. Todos los navegadores están de acuerdo en que el HTML es de hecho una prioridad muy alta, importante para cargar una página web. Eso es lógico. Lo mismo ocurre con el CSS, la línea inferior aquí.

4. Browser Priorities for Fonts and JavaScript

Short description:

Los navegadores tienen diferentes prioridades para las fuentes y los archivos JavaScript. Firefox asigna una prioridad media a los archivos JavaScript que no bloquean el análisis, mientras que Chrome les asigna una prioridad de red más baja. Safari asigna una alta prioridad a todos los archivos JavaScript, excepto a los etiquetados como async. La precarga de JavaScript en Chrome siempre le asigna una alta prioridad, lo cual puede ser demasiado alto en algunos casos. Una nueva función llamada fetch priority permite un control detallado sobre la prioridad de los recursos.

Puedes ver que los navegadores están de acuerdo en que es bastante importante. Aunque es un poco más importante en Chrome que en los otros dos. Pero las cosas son muy diferentes para las fuentes. Por ejemplo, Firefox realmente no se preocupa por el departamento de marketing de tus fuentes personalizadas, lo cual es lo contrario de lo que hace Chrome, que les asigna la máxima prioridad posible a las fuentes. Así que ya hay grandes diferencias aquí.

Veamos qué hacen con el JavaScript, porque el JavaScript tiene muchas formas de cargar archivos JavaScript. Veamos primero Chrome y Firefox. Si tienes un JavaScript en el encabezado, que bloquea el análisis, es decir, se carga de forma sincrónica, eso, por supuesto, será una prioridad alta en ambos. Pero luego las cosas difieren. Luego, Firefox dice que para cualquier otro tipo de JavaScript, realmente no le importa, simplemente les asignará a todos una prioridad media. Chrome es un poco más detallado, dice, ya sabes, si los etiquetas como async o defer, haz que no bloqueen el análisis, esto en realidad los hará tener una prioridad más baja en la red también. Ahora, podría estar equivocado, pero supongo que lo que tú como desarrollador esperas es probablemente lo que Chrome está haciendo, ¿verdad? Async y defer son señales claras de que estos recursos son un poco menos importantes que el JavaScript que bloquea el análisis. Así que eso tiene sentido, pero ahora agárrate a tu asiento porque veamos qué hace Safari con esto.

Por si no queda claro, Safari básicamente dice, no me importa dónde se mencione el JavaScript en el HTML, simplemente le daré a todo una alta prioridad, no importa si está en el encabezado o en la parte inferior, todo es lo mismo para mí. La única excepción es si lo etiquetas como async, por alguna razón eso pasa a tener una prioridad media, lo cual fue una sorpresa para mí porque esperaba que eso sucediera con defer, no con async. Y realmente no sé la razón por la que Safari hace esto. Y esto ya es interesante, hagámoslo un poco peor. Introduzcamos la opción de precarga. ¿Qué sucede si precargas un archivo JavaScript? Lo que puedes ver aquí es que para Safari y Firefox, no importa mucho, mantienen sus prioridades estándar también para el recurso precargado. Pero para Chrome, realmente depende del archivo JavaScript que estés precargando porque siempre le asigna una alta prioridad. Así que digamos, por ejemplo, si precargas un JavaScript que está etiquetado como async o defer en Chrome, en realidad estás aumentando considerablemente su prioridad. A veces esto puede ser algo que deseas. Por ejemplo, un buen caso de uso es un administrador de consentimiento de cookies que necesitamos en Europa donde no quieres que bloquee el análisis. A menudo lo etiquetas como async, pero quieres que se descargue bastante rápido para mostrar el aviso de cookies a los usuarios. En ese caso, esto puede ser lo que deseas, pero también puedo imaginar varios otros casos de uso donde no deseas que aumente la prioridad si precargas JavaScript. Así que necesitamos un control más detallado. Y afortunadamente, recientemente se introdujo una nueva función que nos permite hacer precisamente eso. Esto se llama fetch priority. Y con eso, puedes ajustar la prioridad. No puedes decir literalmente uno de esos cinco niveles pero puedes decir que sea un poco más o un poco menos de lo que el navegador asignaría inicialmente.

5. Fetch Priority and Resource Discovery

Short description:

Puedes usar la prioridad de búsqueda para controlar el orden de carga de diferentes llamadas de búsqueda. Actualmente solo está disponible en Chrome, pero se implementará en Safari y Firefox. La búsqueda de recursos se puede mejorar utilizando 103 Early Hints, lo que permite al navegador descubrir recursos antes de que se genere el HTML.

Por ejemplo, si precargas defer, puedes decir simplemente quiero precargarlo. No quiero aumentar la prioridad. Mantén la prioridad de búsqueda baja. Y esto no solo es para JavaScript o precargas. También puedes usarlo, por ejemplo, para cargar imágenes. Por ejemplo, tu imagen de héroe pintada más grande podría tener una prioridad de búsqueda alta. Y hay muchos otros casos de uso. Te recomendaría leerlos en el enlace web.dev a continuación en la diapositiva.

Ahora, un caso especial que quiero mencionar es nuevamente la API de búsqueda. La búsqueda es un poco extraña porque puedes buscar muchos tipos diferentes de recursos. Pero internamente, el navegador siempre lo ve como el mismo tipo, siempre el tipo de búsqueda. Como puedes ver, los navegadores realmente no están de acuerdo en cuán importantes deben ser las llamadas de búsqueda. Esto es un poco molesto porque, digamos que tienes una aplicación JavaScript compleja donde tienes múltiples búsquedas paralelas al mismo tiempo. Algunas de ellas pueden ser claramente más importantes para la lógica de tu aplicación que otras. Entonces, es posible que desees decir que esas deben cargarse primero. Pero no puedes hacer esto con la búsqueda normal, aparentemente. Afortunadamente, la búsqueda también admite la prioridad de búsqueda. Está en el nombre, ¿verdad? Sin embargo, no se llama prioridad de búsqueda. Simplemente se llama prioridad cuando lo usas. Y por ejemplo, aquí puedes reducir la prioridad de algunas de tus búsquedas. Debería ser realmente poderoso si tienes una lógica de carga de recursos muy detallada. Esto solo está disponible en Chrome en este momento. Pero se está implementando en Safari y Firefox. Así que próximamente en un navegador cerca de ti.

Pero la segunda cosa de la que quería hablarles es el descubrimiento de recursos. Porque, por supuesto, solo podemos priorizar los recursos que hemos identificado como necesarios. Ahora, por lo general, ¿cómo descubre el navegador cosas? Está en el HTML. Entonces, si el HTML se genera lentamente. Si tenemos un alto tiempo de primer byte. La carga de la página completa también se ralentizará porque los recursos se descubren tarde. ¿No sería genial entonces si pudiéramos hacer algo como esto. Donde realmente podríamos hacer que el navegador descubra los recursos mucho antes. Incluso antes de que llegue cualquier HTML. Suena mágico, ¿verdad? En realidad, esta es una función que puedes usar en algunas configuraciones, incluso hoy. Se llama 103 Early Hints. Ahora, la configuración que estoy usando aquí hoy. El ejemplo es que estamos usando un servidor de borde, ¿verdad? CDN, algo como CloudFlare o Akamai. O si estás muy actualizado, Vercel o Netlify. Esto significa que el navegador se conectará al servidor de borde.

6. Edge Server Fetching and Preloading

Short description:

Si el servidor de borde no tiene el HTML en caché, lo obtiene del origen. Durante este tiempo, el servidor de borde puede enviar 103 Early Hints, que es una lista de enlaces. El navegador puede comenzar a precargar estos archivos, por lo que cuando llegue el HTML, el navegador ya tiene los archivos críticos. También es posible precargar y preconectar dominios de terceros.

Y si el servidor de borde no tiene, digamos, el HTML en caché, necesita ir a buscarlo al origen. Mientras eso sucede, el servidor de borde puede enviar 103 Early Hints. Lo que esto es, en realidad, es una lista de enlaces. Esto es realmente, nuevamente, precargas y preconexiones. Por lo general, colocarías esos en el HTML, pero por supuesto, aún no tenemos el HTML. Estamos esperando que se genere. Aquí, simplemente colocamos esto en los encabezados de respuesta HTTP directamente. Luego, el navegador recibe estos enlaces y puede comenzar a precargar estos archivos. Para que cuando el HTML llegue desde el origen, el navegador ya debería tener gran parte de tus archivos más críticos. Esto es lo que hace que esta magia suceda, y se vuelve aún mejor porque incluso puedes precargar y preconectar a dominios de terceros también.

7. Dominio estático y renderizado del lado del servidor

Short description:

Puedes abrir una nueva conexión a un dominio estático y cargar más recursos mientras esperas el HTML. Esto se basa en una generación lenta de HTML, que es más común con el renderizado del lado del servidor. Sugiero volver al renderizado del lado del servidor y abandonar el renderizado del lado del cliente.

Supongamos, por ejemplo, que tienes un dominio estático en el que solías alojar algunos recursos como fuentes. Mientras ocurre todo lo demás, mientras esperas el HTML, en paralelo, ya puedes abrir una nueva conexión al otro dominio y cargar más recursos. Esto es realmente muy poderoso, pero como puedes ver, realmente depende de tener un tiempo de generación de HTML bastante lento, lo cual, por supuesto, sucede principalmente si utilizas algo como el renderizado del lado del servidor y no tanto el renderizado del lado del cliente. ¿Estoy sugiriendo que todos volvamos masivamente al renderizado del lado del servidor, abandonando por completo el renderizado del lado del cliente? Bueno, sí, eso es exactamente lo que estoy sugiriendo. Sugiero que todos volvamos a usar PHP completo, olvidémonos de todo el JavaScript. Probablemente no es lo que esperabas escuchar en una conferencia de JavaScript, pero ¿qué puedo decir? Soy de la vieja escuela.

8. Introducción a Web Transporte

Short description:

Web Transporte es una opción poderosa para casos de uso en tiempo real, proporcionando acceso de bajo nivel a las características de QUIC y HTTP3. Permite elegir algoritmos de control de congestión, enviar datagramas no confiables y acceder a flujos HTTP3 sin procesar. Cuando se combina con próximas características web como WebAssembly y WebCodecs, permite un procesamiento y renderizado eficiente de datos. Sin embargo, WebTransporte puede retroceder a HTTP 2 si se bloquea HTTP 3 y el navegador abstrae algunos detalles. En general, HTTP 3 ofrece características de alto nivel y posibilidades emocionantes, incluyendo 103 Early Hints y Web Transporte.

Ahora lo último de lo que quería hablarles es algo llamado Web Transporte. Ya he hablado un poco sobre la API Fetch, y eso es generalmente lo que necesitas, pero para algunos casos de uso, especialmente algunos casos en tiempo real, necesitas un poco más de potencia. Y hasta ahora, tendrías que usar algo como web sockets sobre TCP o si realmente necesitabas UDP o datos no confiables, podrías usar algo como el canal de datos WebRTC para esto. Ambos funcionan, pero especialmente este último es un poco difícil de usar. No es muy intuitivo configurarlo, especialmente en un contexto de cliente a servidor.

Con HTTP3 y QUIC, ahora obtenemos una tercera opción en esta lista, que se llama Web Transporte. Y me gusta decir, aunque no es completamente correcto, me gusta decir que el Web Transporte es lo más cercano que llegaremos a un socket de red sin procesar en el navegador. Como sabrán, no hay sockets TCP o UDP debido a razones de seguridad, pero el Web Transporte expone la mayoría de las características de bajo nivel de QUIC y HTTP3 de una manera relativamente fácil de usar. Por ejemplo, el Web Transporte aún no está terminado. Este es el diseño actual, aún podría cambiar, pero ya te da una idea de las capacidades que podrías tener. Por ejemplo, incluso podrías elegir el algoritmo de control de congestión que el navegador usaría, donde podrías ajustar ya sea para un alto rendimiento o baja latencia. De manera similar, algo que ves ahí se llama datagramas. Puedes enviar datagramas completamente no confiables. Estos no son datagramas UDP sin procesar. En realidad, son parte de la conexión QUIC, por lo que están completamente encriptados y controlados por flujo y congestión, pero aún así deberían ser muy interesantes para casos de uso como juegos en tiempo real y transmisión de medios. Y finalmente, tienes acceso a los flujos HTTP3 sin procesar utilizando una interfaz muy, creo, intuitiva para cualquier persona que haya usado otros tipos de flujos de JavaScript.

Así que el Web Transporte está llegando. Aún no está terminado, pero puedes probarlo en Firefox y Chrome en este momento. Realmente comienza a brillar, sin embargo, cuando lo combinas con otras características web próximas y existentes. Por ejemplo, mucha gente está usando esto para reproducir el caso de uso de WebRTC, transmisión de medios en vivo, pero de una manera mucho más a nivel bajo donde obtienes los datos a través, por ejemplo, de transportes web. Luego puedes usar algo como WebAssembly para procesar los datos de manera muy eficiente. Luego está algo nuevo llamado WebCodecs que realmente te permite decodificar o transcodificar los datos de medios de una manera muy eficiente directamente desde JavaScript o WebAssembly. Luego puedes renderizarlo. Y hay ejemplos dentro de un proyecto llamado MediaOverQuick. Están trabajando en un nuevo protocolo específicamente para esto que tiene algunos resultados realmente sorprendentes para videos de muy baja latencia directamente en el navegador sin toda la complejidad de WebRTC. Entonces, el Web Transporte es realmente solo un bloque de construcción para muchos casos de uso interesantes en la parte superior.

Por supuesto, siempre hay un inconveniente. Puede que hayas visto esto en una de las diapositivas anteriores. No es HTTP 3 sin procesar porque algunas redes bloquearán activamente o no permitirán HTTP 3 en la práctica. Entonces, el Web Transporte retrocederá a HTTP 2 si no está disponible. Y al menos por ahora, el plan es darte acceso a datagramas incluso en HTTP 2 aunque no sean realmente no confiables. Así que, ya sabes, algo a tener en cuenta nuevamente. El navegador abstrae algunos de estos a veces un poco demasiado. Con eso, es hora de concluir esto. Creo que está claro que HTTP 3 es de hecho un protocolo muy poderoso. Aunque no puedes hacer mucho con él, hay algunas características de alto nivel que puedes usar. Algunas de ellas son bastante complejas como la priorización y dependen del navegador, pero otras permitirán muchos casos de uso nuevos e interesantes como, por ejemplo, 103 Early Hints y especialmente Web Transporte. Con eso, diría si te gustaría saber más sobre esto o cómo era mejor en los buenos días de PHP, avísame y nos vemos la próxima vez.

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
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 🤐)
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 🤐)
React Summit 2022React Summit 2022
50 min
High-performance Next.js
Workshop
Next.js is a compelling framework that makes many tasks effortless by providing many out-of-the-box solutions. But as soon as our app needs to scale, it is essential to maintain high performance without compromising maintenance and server costs. In this workshop, we will see how to analyze Next.js performances, resources usage, how to scale it, and how to make the right decisions while writing the application architecture.
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