Acelerando Tu Aplicación React Con Menos Javascript

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

¿Demasiado JavaScript te está agobiando? Los nuevos marcos que prometen no usar JavaScript parecen interesantes, pero tienes una aplicación React existente que mantener. ¿Y si Qwik React es tu respuesta para un inicio de aplicaciones más rápido y una mejor experiencia de usuario? Qwik React te permite convertir fácilmente tu aplicación React en una colección de islas, que pueden ser SSR y retrasar la hidratación, y en algunos casos, omitir la hidratación por completo. Y todo esto de manera incremental sin una reescritura.

This talk has been presented at React Advanced 2023, check out the latest edition of this React Conference.

FAQ

Quick es un proyecto que permite convertir aplicaciones React en islas más pequeñas, lo que ayuda a que carguen más rápido al reducir la cantidad de JavaScript necesario.

Builder.io es un CMS visual headless que permite integrar y registrar componentes existentes de React, facilitando al equipo de marketing la edición visual y la manipulación de componentes sin necesidad de intervención directa del desarrollador.

Mitosis es una herramienta que permite escribir componentes que pueden ser traducidos a diferentes frameworks, facilitando la creación de sistemas de diseño comunes en empresas que utilizan múltiples tecnologías.

La cantidad de JavaScript influye directamente en la velocidad de interpretación y ejecución por parte del navegador, siendo menor cantidad de código sinónimo de mejor rendimiento y mayor interactividad del sitio web.

La hidratación es un proceso donde el JavaScript se carga y ejecuta para hacer una página web interactiva. Sus desventajas incluyen el aumento de tiempo necesario para que la aplicación sea interactiva debido a la duplicación de contenido en HTML y JavaScript.

Existen alternativas como la Hidratación Parcial y los Componentes de Servidor de React, que segmentan la aplicación en islas que se activan bajo ciertas condiciones, mejorando el rendimiento al no sobrecargar el navegador inicialmente.

QUIC permite una arquitectura de islas en aplicaciones React, donde los componentes se activan bajo demanda, reduciendo la necesidad de hidratación completa y mejorando significativamente los tiempos de carga y la interactividad.

Miško Hevery
Miško Hevery
15 min
23 Oct, 2023

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Quick React es una herramienta que acelera las aplicaciones React con menos JavaScript, y Builder.io es un CMS visual que empodera a los equipos de marketing. El rendimiento web es un desafío, con la mayoría de los sitios web obteniendo puntuaciones bajas. La arquitectura de islas y la razonabilidad son enfoques alternativos a la hidratación que mejoran el rendimiento. QUIC permite aplicaciones reanudables y Quick React habilita la arquitectura de islas para tiempos de inicio más rápidos. La hidratación y la comunicación entre islas son cruciales para la interactividad en las aplicaciones React.

1. Introducción a Quick React

Short description:

Hablemos de Quick React y cómo puede acelerar tu aplicación React con menos JavaScript. Builder.io es un CMS visual sin cabeza que te permite registrar componentes React existentes y potenciar a tu equipo de marketing con un editor visual. Builder.io también ofrece Partytown, que ejecuta código de terceros en trabajadores web, y Mitosis, que genera código idiomático para diferentes marcos.

Hablemos de Quick React, y específicamente cómo acelerar tu aplicación React con menos JavaScript.

Hola, mi nombre es Misko Hevery, soy CTO en Builder.io y he construido estos proyectos anteriores llamados Angular, y hoy estoy trabajando en un proyecto llamado Quick, y quiero específicamente mostrarte cómo Quick puede ser utilizado para convertir las aplicaciones React en islas más pequeñas y cargar más rápido.

Así que trabajo para Builder.io, Builder.io es un CMS visual headless. Lo que significa es que puedes tomar tu aplicación React existente y hacer npm install builder en ella, y una vez que instales builder, puedes registrar los componentes existentes de React en tus aplicaciones que tienes, y eso permite a tu equipo de marketing tener un editor visual y pueden arrastrar y soltar tus componentes en la página, y a partir de los componentes ellos pueden cambiar cosas, programar cuándo las cosas se ponen en marcha, publicar y enviar los datos al sitio web. Así que no tienes que, como ingeniero, estar involucrado en cada pequeño cambio.

Tenemos un increíble equipo de contribuyentes de código abierto. En primer lugar, a Builder.io le encanta el código abierto, así que además de Quick, tenemos Partytown, que proporciona una forma de ejecutar código de terceros, como Google Analytics, dentro del trabajador web, lo que libera el hilo principal para manejar la aplicación, hace que la aplicación sea más receptiva. También tenemos Mitosis, que te permite escribir tus componentes en un estilo, y luego esos componentes se traducen a todos los frameworks existentes. Así que si tienes una empresa donde hay muchos equipos usando diferentes frameworks y quieres tener sistemas de diseño comunes en todos, Mitosis es una forma de hacerlo. Lo que hay que entender sobre Mitosis es que no es un envoltorio, sobre los web components existentes o algo así. En realidad genera código idiomático para todos los diferentes frameworks. Y por supuesto, tenemos a estos tres caballeros increíbles que están trabajando en el código abierto, Adam Bradley, quien es creador de Ionic, Manu Martinez, Almeda, quien también trabajó en Ionic y GEN, y finalmente, Sam Jaber, quien está trabajando en Mitosis.

2. Desafíos con el Rendimiento Web

Short description:

Nuestra web es increíble, pero no es tan rápida como debería ser. Google puntúa los sitios web basándose en la experiencia del usuario, y la mayoría de los sitios web obtienen una puntuación en rojo. Es difícil lograr un buen rendimiento.

Ahora, lo que quiero hablarles es que nuestra web es increíble, pero no es tan rápida como debería ser. Y a Google le importa esto, y ven que los usuarios abandonan los sitios que no rinden tan bien. Así que Google puntúa los sitios web, y tienen algo llamado Core web vitals. Y esto se registra en base a qué tipo de experiencia de usuario tienen las personas cuando usan el navegador Chrome. Y como puedes ver, la mayoría de los sitios web obtienen una puntuación en rojo. Solo los sitios web que dedican la mayor cantidad de tiempo y energía pueden obtener amarillo, y casi ningún sitio web, en realidad, que he visto en producción que tienen tráfico real logran obtener verde. Entonces, ¿qué está pasando? ¿Por qué es tan difícil obtener un buen rendimiento? Bueno, si miras la cantidad de JavaScript que se ha enviado al cliente a lo largo de los años, puedes ver que está aumentando constantemente.

3. Mejorando la Interactividad y Rendimiento Web

Short description:

Las aplicaciones de hoy son más interactivas y ricas que hace 10-20 años. Los marcos que mejor se desempeñan en términos de Lighthouse core también envían la menor cantidad de código. Sin embargo, todavía necesitamos enviar código para hacer la aplicación interactiva. La pre-renderización del lado del servidor puede parecer más rápida, pero aún requiere descargar, ejecutar y renderizar la aplicación. La interactividad es en realidad más lenta debido a las cantidades duplicadas de información que se envían. La hidratación comienza en un componente raíz y ejecuta recursivamente los componentes, aprendiendo sobre los oyentes, el estado y los límites del componente.

Y la razón de este aumento es porque las aplicaciones de hoy son mucho más interactivas, mucho más ricas que hace 10, 20 años, y por lo tanto, esperaríamos que esta tendencia particular continúe.

Ahora, no es sorprendente, he seleccionado un par de frameworks a la izquierda y te muestro cuál es su rendimiento promedio que Google ve en el sitio web. Y en el lado derecho, te estoy mostrando cuánto código estos frameworks están enviando al cliente. Y observa que los frameworks que mejor se desempeñan en términos de Lighthouse core también envían la menor cantidad de código. De nuevo, esto no debería ser sorprendente porque básicamente te dice que, hey, cuanto menos código envíes, más fácil será para el navegador interpretarlo, ejecutarlo y hacer el sitio web interactivo.

Ahora, el problema es que necesitamos enviar código. Necesitamos enviar código para hacer la aplicación interactiva, y por lo tanto, hacemos esto a través de este proceso llamado hidratación. Y la forma en que funciona la hidratación es que comienza con HTML, que esencialmente es una página en blanco primero. Y hablaremos sobre la renderización del lado del servidor en un segundo. El JavaScript se carga, el JavaScript luego se ejecuta, luego causa una renderización, y en este punto, realmente tienes un sitio web interactivo real. Y es en este punto donde puedes ir y hacer clic en él y realizar operaciones.

Ahora, el problema es que tenemos esta página en blanco al principio, y por lo tanto, la gente comenzó a hacer pre-renderización del lado del servidor. Y así, con la pre-renderización del lado del servidor, o SSR, o SSG, terminas con HTML, y el HTML ahora tiene una imagen que puedes ver, pero realmente no puedes interactuar con ella, ¿verdad? Y entonces hay una apariencia de ser más rápido porque la página realmente aparece más rápido para el usuario, y eso proporciona una mejor experiencia de usuario. Pero todavía tiene que descargar todo el JavaScript, todavía tiene que ejecutar toda la aplicación, y todavía tiene que renderizar la aplicación, excepto que ahora no llamamos a eso renderización. En cambio, lo llamamos reconciliación, porque estamos tratando de reutilizar tantos elementos DOM como sea posible dentro de la UI. Y por lo tanto, solo en este punto la aplicación se vuelve interactiva. Y observa lo que realmente está sucediendo, es que la interactividad es en realidad más lenta, si no hubieras dicho contenido al principio en absoluto. Y por lo tanto, es un poco de dicotomía que parecemos más rápidos, pero en realidad somos más lentos. Y la razón de eso es porque en realidad estamos enviando más información, estamos enviando duplicado cantidades de información. Si lo piensas, si tomas una cadena, como visualmente construida en tu pila tecnológica que ves en la imagen, esa cadena en realidad aparece dos veces. Una vez en HTML y una vez en JavaScript. Y por lo tanto, esta duplicación en realidad significa que tienes que enviar más cosas al cliente, el cliente tiene que procesar más cosas. Y el resultado final es que hay... que se tarda más tiempo en que la aplicación se despierte. Ahora, la hidratación, si lo piensas, lo que es, es que comienzas en un componente raíz. Y a medida que este nuevo componente raíz se procesa y se ejecuta, la hidratación aprende, el marco aprende sobre otros componentes, en este caso, estos tres. Y por lo tanto, va recursivamente y ejecuta estos componentes y aprende sobre más componentes. Y a medida que lo hace, aprende sobre los oyentes. Y son los oyentes los que realmente nos importan. Los oyentes, el estado y los límites de los componentes es la información que necesitamos para hacer la aplicación interactiva.

4. Arquitectura de Islas y Razonabilidad

Short description:

Los oyentes, el estado y los límites de los componentes son cruciales para hacer que la aplicación sea interactiva. Enfoques alternativos a la hidratación, como la Hidratación Parcial y los Componentes de Servidor de React, dividen la aplicación en islas, permitiendo un mejor rendimiento y experiencia de usuario. La razonabilidad, popularizada por marcos de trabajo como QUIC, proporciona un punto intermedio combinando hidratación y razonabilidad. La arquitectura de islas, ejemplificada por marcos de trabajo como Astro y Fresh, ofrece una forma de lograr la razonabilidad sin cambiar el marco de trabajo. Quick permite la arquitectura de islas para las aplicaciones de React, proporcionando tiempos de inicio más rápidos. La razonabilidad comienza con HTML, que contiene la información necesaria para el marco de trabajo, haciendo que la página sea inmediatamente interactiva.

Los oyentes, el estado y los límites de los componentes son la información que necesitamos para hacer que la aplicación sea interactiva. Y entonces, debido a que esto lleva mucho tiempo y toda la aplicación tiene que estar presente, la gente está buscando alternativas a la hidratación.

Y entonces hay diferentes variaciones de esto. Una se llama Hidratación Parcial, en cuyo caso conviertes todo en islas. Y entonces la idea es que reconoces que esta isla en particular no es interactiva y por lo tanto no hay necesidad de descargarla y ejecutarla en el cliente. Mientras que esta isla es súper pequeña y puede ser despertada tan rápidamente que tal vez puedes hacerlo solo en la interacción de clic, tal vez esta isla es un poco más grande. Y entonces tienes que hacerlo en ocioso o en visible para obtener el mejor rendimiento posible. Pero al dividir la aplicación en islas, te permite no abrumar al navegador al principio y lo que proporciona una mejor experiencia de usuario.

Otra forma de esto son los Componentes de Servidor de React, que si lo piensas, son algo así como islas excepto que en lugar de ser tratadas como aplicaciones independientes, en realidad son tratadas como una aplicación unificada, porque parte del VDOM se calcula en un servidor y simplemente se envía al cliente y por lo tanto el cliente no tiene que volver a ejecutar esa porción del componente. Y lo único que el cliente tiene que ejecutar son los componentes que son realmente interactivos. Entonces tenemos extremos, ¿verdad? En un extremo, tenemos la hidratación básica, que Angular y React y otros marcos de trabajo hacen. Y en el otro extremo, tenemos esta idea de razonabilidad. Hablaremos un poco más de ello y los marcos de trabajo como QUIC lo han popularizado, pero QUIC de ninguna manera es el primero. Google tiene un marco de trabajo llamado Wiz que ha estado haciendo razonabilidad durante los últimos 10 años. Y Marco tiene un marco de trabajo. Lo siento, eBay tiene un marco de trabajo llamado Marco que en la última versión 6, también proporciona razonabilidad para tus aplicaciones también. Y todo eso significa que las aplicaciones esencialmente pueden empezar más rápido. Pero hay un punto intermedio que es básicamente islas y las islas dicen, Oye, básicamente puedo seguir haciendo razonabilidad, lo que significa que no tengo que cambiar mi marco de trabajo. Tengo que seguir haciendo hidratación, lo que significa que no tengo que cambiar mi marco de trabajo y seguir haciendo lo que he hecho antes. Pero en lugar de hacer una hidratación en todo, como dije, podemos hacer trozos más pequeños. Ahora esto ha sido popularizado por marcos de trabajo como Astro y actualmente un marco de trabajo llamado Fresh. Pero lo que quiero mostrarte es que también puedes obtener una arquitectura de islas para tu aplicación React con Quick. Y eso es de lo que vamos a hablar en un segundo.

Ahora, la razonabilidad es un poco diferente a la hidratación en que razonablemente comienza con HTML. Obtienes una página, pero la página ya tiene toda la información necesaria para el marco de trabajo. Ahora, eso no significa que tenga todo el código de la aplicación. Sería demasiado grande para serializarlo en la página, pero tiene información sobre dónde están los oyentes y qué código necesita ser descargado cuando vas e interactúas con uno de estos oyentes. Y como resultado, la página es inmediatamente interactiva. Ahora, no sólo parece más rápido, en realidad es más rápido y empiezas a descargar inmediatamente el JavaScript que si el usuario va e interactúa, no habrá ningún retraso en la interacción.

5. Instalación de QUIC y Construcción de Componentes

Short description:

QUIC te permite reanudar la aplicación donde la dejaste, eliminando la necesidad de re-ejecución o reconciliación. Instala QUIC City y Quick React, luego construye un componente de Hola Mundo y un contador en React. La función QUICify convierte el componente en una isla, permitiendo la reanudabilidad sin coste.

Y notarás que la cantidad de JavaScript que descargas es mucho, mucho menor. Y eso se debe a que, al reanudar, no tienes que volver a ejecutar todos los componentes. La mayoría de estos componentes pueden ser eliminados porque en realidad son información duplicada. Así que con la reanudabilidad, no tienes el problema de la doble descarga que existe en la Hidratación. Y como resultado, no hay necesidad de re-ejecutar la aplicación o hacer ningún tipo de reconciliación. La aplicación simplemente continúa donde la dejaste.

Así que permíteme darte una demostración. Empecemos instalando QUIC. Así que haces npm create QUIC at latest. Esto contiene un meta-framework, al que llamamos QUIC City. Así que también instalemos QUIC City, instalemos las dependencias, git, y así sucesivamente, y ya estás listo para empezar. El segundo paso es instalar Quick React. Así que este es un envoltorio que permite a QUIC usar React components. Como puedes ver, podemos instalar QUIC y añadir una integración de React, pasar por todos los pasos, y configurar todo. Y ahora estamos listos para construir algo en QUIC.

Así que construyamos un Hola Mundo para ver cómo se ve un Hola Mundo. En el lado derecho, tengo un componente de React que puedes ver. Nota en la parte superior, hay un pragmat que dice JSX import source react. Esto le dice al compilador que hey, este es un código de React, asegúrate de tratar con JSX de una manera que a React le guste. Y creamos un componente básico usando la función greetings. Ahora lo que QUIC añade es que te permite tomar el componente greetings y ejecutar a través de una función QUICify para obtener una versión QUICify QUIC de este componente en particular. Ahora esto es un envoltorio runtime, esto no es una traducción, así que tienes, obtendrás el mismo comportamiento exacto que antes. No tienes que preocuparte por la compatibilidad o nada de eso. Pero en la práctica, lo que significa, es que convierte el componente en una isla. Así que como QUIC es reanudable, esencialmente puede empezar con cero coste, pero ahora tu componente greetings tiene un coste que bajo algunas condiciones, nosotros, tendrás que ejecutar y hidratar. En este caso particular, el greetings en realidad nunca se hidrata porque no hay señal para el, para QUIC, para decirle, hey, tiene que ser hidratado. Y si lo piensas, esto tiene mucho sentido porque en este caso, greetings es en efecto y por lo tanto no hay necesidad de hacer nada con él. Ahora hagamos algo más complicado. Construyamos un contador. Así que construyamos un contador en React y puedes ver, tienes un botón y puedes hacer clic en él, lo que cambia el estado y actualiza el recuento.

6. Hidratación y Comunicación entre Islas

Short description:

Creamos una isla de React dentro de una aplicación existente al 'quickificar' el contador. La hidratación es necesaria para hacer que el código sea interactivo, y puede ser activada por condiciones específicas como pasar el ratón sobre un botón. La comunicación entre islas es crucial, y lo demostramos con dos islas: un botón y una pantalla. El estado transita entre las islas, y Quick posee este estado. La hidratación perezosa permite que los componentes se hidraten en función de los cambios en las entradas o props. Diferentes métodos como pasar el ratón, cargar, estar inactivo, visible, hacer clic, señales y cambios de propiedad pueden despertar el sistema.

Y de nuevo, vamos a 'quickificar' el contador para obtener un componente y luego, ya sabes, incrustarlo dentro de una aplicación más grande. Así que creamos una isla de React dentro de una aplicación existente. Ahora si haces clic en ella, notarás que no pasa nada. Y eso es porque el código no está hidratado. Así que necesitas decirle al sistema, oye, ¿bajo qué condiciones tiene que ser hidratada esta isla en particular? Y la forma de hacerlo es a través de esta propiedad de 'eagerness'. Así que en este caso particular, tenemos el mismo código. Y ahora estamos diciendo, oye, sabes, cuando pasas el ratón sobre este botón en particular, lo que significa que es muy probable que estés a punto de hacer clic en él. Por cierto, hay otras formas de hacerlo. Adelante y hidrata el componente. Así que si miras lo que está pasando es que ahora hay React en marcha. Cuando pasas el ratón, puedes ver que las DevTools de React se han descargado y se han inicializado y hemos descargado el código necesario. Y como se ha inicializado, puedes ver que el contador de React se ha renderizado. Y ahora que se ha renderizado e hidratado, puedes interactuar con él y todo funciona exactamente como esperarías.

Ahora, una de las cosas importantes sobre las islas es que necesitas resolver los problemas de comunicación entre islas. Estas islas son efectivamente aplicaciones independientes de React y necesitan poder comunicarse entre sí. Así que lo que te voy a mostrar aquí es que tienes dos islas, una es un botón y la otra es una pantalla. En el caso del botón, vamos a 'quickificarlo' de nuevo, pasándolo por una función de 'quickify'. Y vamos a especificar 'eagerness hover', lo que significa que tan pronto como pase el ratón sobre el botón en particular, quiero que el botón se hidrate. En el caso de la pantalla, no estamos especificando ningún tipo de hidratación en absoluto. Lo que sucede en el lado del cliente es que necesitamos tener un estado que transite tanto el botón como la pantalla. En este estado, porque se posee de una manera que son dos islas separadas, realmente tiene que ser poseído por Quick. Así que Quick ahora tiene un estado, y este estado se pasa tanto a un botón, que se hidrata al pasar el ratón, pero también a la pantalla. Observa lo que sucede aquí. Cuando paso el ratón sobre el botón, puedes ver que las DevTools aparecen y el botón de React se está renderizando. Pero ahora cuando voy y hago clic en él, el acto real de hacer clic... Primero, solo hay un botón, y luego si vuelves y haces clic en él ahora, ahora puedes ver que, oye, la pantalla de React se ha hidratado y ejecutado también, y así que ahora tenemos esta situación de hidratación perezosa donde el botón se hidrata con avidez, pero la pantalla solo se hidrata cuando las entradas o las props de ella cambian. Y si lo piensas, esto es exactamente cómo funciona React debajo de él, pero estamos emulando exactamente lo mismo con señales e islas también.

Ahora, solo para señalar, sabes, pasar el ratón no es la única forma de despertar el sistema. Puedes hacerlo al cargar, estar inactivo, visible, hacer clic en nuestros parámetros, y cuando despiertas cosas, también puedes despertar cosas usando señales o cambios de propiedad, como hemos mostrado. Espero que lo hayas disfrutado, y espero que veas cómo puedes usar la tecnología existente de React para convertir la aplicación de React en islas y construir aplicaciones a gran escala con comunicación entre islas que proporciona QUIC.

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

Una Guía del Comportamiento de Renderizado de React
React Advanced 2022React Advanced 2022
25 min
Una Guía del Comportamiento de Renderizado de React
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Acelerando tu aplicación React con menos JavaScript
React Summit 2023React Summit 2023
32 min
Acelerando tu aplicación React con menos JavaScript
Top Content
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.
Concurrencia en React, Explicada
React Summit 2023React Summit 2023
23 min
Concurrencia en React, Explicada
Top Content
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.
How React Compiler Performs on Real Code
React Advanced 2024React Advanced 2024
31 min
How React Compiler Performs on Real Code
Top Content
I'm Nadia, a developer experienced in performance, re-renders, and React. The React team released the React compiler, which eliminates the need for memoization. The compiler optimizes code by automatically memoizing components, props, and hook dependencies. It shows promise in managing changing references and improving performance. Real app testing and synthetic examples have been used to evaluate its effectiveness. The impact on initial load performance is minimal, but further investigation is needed for interactions performance. The React query library simplifies data fetching and caching. The compiler has limitations and may not catch every re-render, especially with external libraries. Enabling the compiler can improve performance but manual memorization is still necessary for optimal results. There are risks of overreliance and messy code, but the compiler can be used file by file or folder by folder with thorough testing. Practice makes incredible cats. Thank you, Nadia!
Optimización de juegos HTML5: 10 años de aprendizaje
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Optimización de juegos HTML5: 10 años de aprendizaje
Top Content
PlayCanvas is an open-source game engine used by game developers worldwide. Optimization is crucial for HTML5 games, focusing on load times and frame rate. Texture and mesh optimization can significantly reduce download sizes. GLTF and GLB formats offer smaller file sizes and faster parsing times. Compressing game resources and using efficient file formats can improve load times. Framerate optimization and resolution scaling are important for better performance. Managing draw calls and using batching techniques can optimize performance. Browser DevTools, such as Chrome and Firefox, are useful for debugging and profiling. Detecting device performance and optimizing based on specific devices can improve game performance. Apple is making progress with WebGPU implementation. HTML5 games can be shipped to the App Store using Cordova.
El Futuro de las Herramientas de Rendimiento
JSNation 2022JSNation 2022
21 min
El Futuro de las Herramientas de Rendimiento
Top Content
Today's Talk discusses the future of performance tooling, focusing on user-centric, actionable, and contextual approaches. The introduction highlights Adi Osmani's expertise in performance tools and his passion for DevTools features. The Talk explores the integration of user flows into DevTools and Lighthouse, enabling performance measurement and optimization. It also showcases the import/export feature for user flows and the collaboration potential with Lighthouse. The Talk further delves into the use of flows with other tools like web page test and Cypress, offering cross-browser testing capabilities. The actionable aspect emphasizes the importance of metrics like Interaction to Next Paint and Total Blocking Time, as well as the improvements in Lighthouse and performance debugging tools. Lastly, the Talk emphasizes the iterative nature of performance improvement and the user-centric, actionable, and contextual future of performance tooling.

Workshops on related topic

Masterclass de Depuración de Rendimiento de React
React Summit 2023React Summit 2023
170 min
Masterclass de Depuración de Rendimiento de React
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Vería una interacción lenta, intentaría una optimización aleatoria, vería que no ayudaba, y seguiría intentando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Haría una grabación en Chrome DevTools o React Profiler, la examinaría, intentaría hacer clic en cosas aleatorias, y luego la cerraría frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos a analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, estaremos cubriendo el rendimiento de la interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Next.js 13: Estrategias de Obtención de Datos
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Estrategias de Obtención de Datos
Top Content
Workshop
Alice De Mauro
Alice De Mauro
- Introducción- Prerrequisitos para la masterclass- Estrategias de obtención: fundamentos- Estrategias de obtención – práctica: API de obtención, caché (estática VS dinámica), revalidar, suspense (obtención de datos en paralelo)- Prueba tu construcción y sírvela en Vercel- Futuro: Componentes de servidor VS Componentes de cliente- Huevo de pascua de la masterclass (no relacionado con el tema, destacando la accesibilidad)- Conclusión
Depuración del Rendimiento de React
React Advanced 2023React Advanced 2023
148 min
Depuración del Rendimiento de React
Workshop
Ivan Akulov
Ivan Akulov
Los primeros intentos de Ivan en la depuración de rendimiento fueron caóticos. Veía una interacción lenta, probaba una optimización aleatoria, veía que no ayudaba, y seguía probando otras optimizaciones hasta que encontraba la correcta (o se rendía).
En aquel entonces, Ivan no sabía cómo usar bien las herramientas de rendimiento. Hacía una grabación en Chrome DevTools o React Profiler, la examinaba, intentaba hacer clic en cosas al azar, y luego la cerraba frustrado unos minutos después. Ahora, Ivan sabe exactamente dónde y qué buscar. Y en esta masterclass, Ivan te enseñará eso también.
Así es como va a funcionar. Tomaremos una aplicación lenta → la depuraremos (usando herramientas como Chrome DevTools, React Profiler, y why-did-you-render) → identificaremos el cuello de botella → y luego repetiremos, varias veces más. No hablaremos de las soluciones (en el 90% de los casos, es simplemente el viejo y regular useMemo() o memo()). Pero hablaremos de todo lo que viene antes - y aprenderemos cómo analizar cualquier problema de rendimiento de React, paso a paso.
(Nota: Esta masterclass es más adecuada para ingenieros que ya están familiarizados con cómo funcionan useMemo() y memo() - pero quieren mejorar en el uso de las herramientas de rendimiento alrededor de React. Además, cubriremos el rendimiento de interacción, no la velocidad de carga, por lo que no escucharás una palabra sobre Lighthouse 🤐)
Construyendo aplicaciones web que iluminan Internet con QwikCity
JSNation 2023JSNation 2023
170 min
Construyendo aplicaciones web que iluminan Internet con QwikCity
WorkshopFree
Miško Hevery
Miško Hevery
Construir aplicaciones web instantáneas a gran escala ha sido elusivo. Los sitios del mundo real necesitan seguimiento, análisis y interfaces y interacciones de usuario complejas. Siempre comenzamos con las mejores intenciones pero terminamos con un sitio menos que ideal.
QwikCity es un nuevo meta-framework que te permite construir aplicaciones a gran escala con un rendimiento de inicio constante. Veremos cómo construir una aplicación QwikCity y qué la hace única. El masterclass te mostrará cómo configurar un proyecto QwikCity. Cómo funciona el enrutamiento con el diseño. La aplicación de demostración obtendrá datos y los presentará al usuario en un formulario editable. Y finalmente, cómo se puede utilizar la autenticación. Todas las partes básicas para cualquier aplicación a gran escala.
En el camino, también veremos qué hace que Qwik sea único y cómo la capacidad de reanudación permite un rendimiento de inicio constante sin importar la complejidad de la aplicación.
Masterclass de alto rendimiento Next.js
React Summit 2022React Summit 2022
50 min
Masterclass de alto rendimiento Next.js
Workshop
Michele Riva
Michele Riva
Next.js es un marco convincente que facilita muchas tareas al proporcionar muchas soluciones listas para usar. Pero tan pronto como nuestra aplicación necesita escalar, es esencial mantener un alto rendimiento sin comprometer el mantenimiento y los costos del servidor. En este masterclass, veremos cómo analizar el rendimiento de Next.js, el uso de recursos, cómo escalarlo y cómo tomar las decisiones correctas al escribir la arquitectura de la aplicación.
Maximizar el rendimiento de la aplicación optimizando las fuentes web
Vue.js London 2023Vue.js London 2023
49 min
Maximizar el rendimiento de la aplicación optimizando las fuentes web
WorkshopFree
Lazar Nikolov
Lazar Nikolov
Acabas de llegar a una página web y tratas de hacer clic en un elemento en particular, pero justo antes de hacerlo, se carga un anuncio encima y terminas haciendo clic en eso en su lugar.
Eso... eso es un cambio de diseño. Todos, tanto los desarrolladores como los usuarios, saben que los cambios de diseño son malos. Y cuanto más tarde ocurran, más interrupciones causarán a los usuarios. En este masterclass vamos a analizar cómo las fuentes web causan cambios de diseño y explorar algunas estrategias para cargar fuentes web sin causar grandes cambios de diseño.
Tabla de contenidos:¿Qué es CLS y cómo se calcula?¿Cómo las fuentes pueden causar CLS?Estrategias de carga de fuentes para minimizar CLSRecapitulación y conclusión