El Impacto en el Rendimiento del JavaScript Generado

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

¿Cuándo fue la última vez que miraste dentro de la carpeta dist para inspeccionar el JavaScript generado por tu framework o bundler?


La realidad del desarrollo moderno de JavaScript con su dependencia de bundlers, frameworks y compiladores es que el JavaScript que escribes no es el mismo que se ejecuta en tu navegador. Herramientas como TypeScript y compiladores como Babel te permiten soportar una variedad de navegadores antiguos, entornos y tiempos de ejecución mientras escribes código moderno y mantenible, pero puede ser difícil saber qué está pasando en ese bundle final. Es crucial entender y optimizar el JavaScript generado durante tu proceso de construcción para maximizar el rendimiento.


Únete a Abhijeet Prasad, mantenedor de los SDKs de JavaScript de monitoreo de errores y rendimiento de código abierto de Sentry, mientras explica las implicaciones de rendimiento y tamaño de bundle del JavaScript generado y las técnicas que puedes usar para optimizarlo. Él explicará las sutilezas de la transpilación, tree-shaking, minificación y estrategias de carga para que puedas entender cómo ofrecer mejores experiencias a tus usuarios.

This talk has been presented at JSNation US 2024, check out the latest edition of this JavaScript Conference.

Abhijeet Prasad
Abhijeet Prasad
17 min
21 Nov, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla de hoy discutió el impacto en el rendimiento del JavaScript generado y la importancia del tamaño del bundle en relación con la velocidad de carga de la página y la experiencia del usuario. Se destacó el uso de un proceso de construcción, minificación y evitar polyfills innecesarios como estrategias para reducir el tamaño del bundle. Se discutieron consideraciones de diseño de API, como evitar búsquedas de objetos profundamente anidadas y usar funciones y objetos en lugar de clases, en relación con la minificación. Se explicaron los conceptos de down-compilation y transpilación, con un enfoque en los desafíos y beneficios que presentan. La charla también enfatizó la necesidad de evitar el uso de enums de TypeScript y en su lugar usar constantes de cadena, así como la importancia de comprimir el código y rastrear los cambios en el tamaño del bundle. Se recomendaron analizadores de bundle para visualizar el contenido del bundle y las conexiones de los componentes.

1. Performance Impact of JavaScript

Short description:

Hoy, vamos a hablar sobre el impacto en el rendimiento del JavaScript generado. El SDK de JavaScript proporcionado por Sentry a menudo se considera demasiado grande, lo que genera preocupaciones sobre el tamaño del paquete. El tamaño del paquete afecta directamente la velocidad de carga de la página y la experiencia del usuario. Para reducir el tamaño del paquete, los desarrolladores analizan el código que escriben y utilizan, considerando bibliotecas alternativas más pequeñas, carga diferida o eliminando JavaScript por completo.

♪ Hola a todos. Bienvenidos. Hoy, vamos a hablar sobre el impacto en el rendimiento del JavaScript generado. Mi nombre es Abhijit. Actualmente trabajo en Sentry, manteniendo nuestros SDKs de JavaScript de código abierto con licencia MIT. Y estos son algunos de los SDKs más utilizados en el mundo, y tenemos un poco de experiencia sobre cómo las personas están construyendo aplicaciones y usando JavaScript.

Una de las cosas más importantes que la gente nos menciona todo el tiempo es que el SDK de JavaScript que les damos, especialmente el de nuestro navegador front-end, es simplemente demasiado grande. Y lo que quiero decir con grande es por el tamaño del paquete. Es tan grande que dudan en cargarlo en su aplicación. Así que, ahora, esta es realmente una preocupación válida y algo que estamos buscando solucionar todo el tiempo, pero es importante pensar, bien, ¿por qué la gente sigue viniendo a nosotros por esto? Esto es realmente porque el tamaño del paquete es bastante importante.

Entonces, tiene una correlación directa con la rapidez con la que se carga una página. Y, por lo tanto, también está directamente correlacionado con la experiencia del usuario. Así que, quieres tener sitios web que tengan menos indicadores de carga, que carguen más rápido, que se sientan más ágiles. Todo eso afecta directamente cómo un usuario percibe y usa tu sitio. Y así, gestionar el tamaño de tu paquete, tener menos JavaScript cargado es realmente importante. Ahora, sabemos que, bien, esto es algo que la gente quiere reducir. Entonces, ¿cómo reduce típicamente la gente su tamaño de paquete? Bueno, generalmente, echas un vistazo al código que escribes y usas. Esto significa que estás analizando lo que estás agregando a tu aplicación y estás determinando si es importante o no.

2. Generated JavaScript and Minification

Short description:

En las aplicaciones modernas de JavaScript, el usuario ejecuta JavaScript generado. Necesitas entender el JavaScript generado para mejorar el tamaño de tu paquete. Usar un proceso de construcción es útil para tree shaking, transpilar e inyectar lógica en tiempo de construcción. La minificación hace que los activos de JavaScript sean más pequeños al eliminar tokens innecesarios y acortar nombres.

Entonces, típicamente, esto será como usar bibliotecas alternativas más pequeñas. Por ejemplo, cambiar de React a Preact, carga diferida de tu JavaScript para que solo cargues exactamente lo que necesitas. Y cada vez que uses un componente u otra lógica, lo cargas de manera diferida. O eliminas JavaScript por completo e intentas eliminar su uso de tu aplicación. El escenario más común para esto es, por ejemplo, pasar de renderizar tu aplicación del lado del cliente a renderizarla del lado del servidor. Pero un tema importante aquí es que estas son todas estrategias para el código que escribes. Pero el código que escribes no es realmente el código que se ejecuta en el navegador, ¿verdad?

En las aplicaciones modernas de JavaScript, esto es completamente diferente. En las aplicaciones modernas de JavaScript, el usuario ejecuta JavaScript generado. Esto significa que necesitas mirar y entender el JavaScript generado para mejorar el tamaño de tu paquete, no solo el JavaScript que escribiste. Ahora, ¿qué quiero decir con JavaScript generado? Lo he mencionado un par de veces ahora mientras hemos hablado juntos. Me refiero a través de un proceso de construcción. Hemos hablado juntos. Me refiero a través de un proceso de construcción. Para la mayoría de las pilas modernas de JavaScript, ya sea que estés renderizando del lado del cliente o del lado del servidor con un framework como Next.js, Nuxt o SvelteKit, tomas algún JavaScript y TypeScript de entrada, lo pasas a un empaquetador como Veet, Webpack, Rollup, y obtienes algo de JavaScript al final. Usar un proceso de construcción es realmente útil. Puedes hacer tree shaking de JavaScript no utilizado, transpilar de TypeScript a JavaScript, soportar navegadores más antiguos inyectando polyfills o compilando hacia abajo APIs de navegadores más antiguos, y puedes inyectar lógica en tiempo de construcción, lo cual es súper útil para sitios construidos estáticamente. Prácticamente todo el mundo usa un proceso de construcción en este punto. Probablemente estés usando Veet o Webpack o una de esas cosas bajo el capó ahora. Así que con eso en mente, todos están usando un proceso de construcción. Puedes ir sin construcción, pero todos los que ejecutan aplicaciones grandes y enormes están ejecutando procesos de construcción. Y así hay muchas mejoras que podemos tomar con cómo las construcciones generan JavaScript. Aquí tenemos cinco áreas principales de mejora. Minificación, compilación hacia abajo, transpilar, compresión y tree shaking. Vamos a omitir el tree shaking esta vez, pero lo tocaré brevemente al final. Así que primero es la minificación, que es un proceso de hacer que tus activos de JavaScript sean lo más pequeños posible, típicamente eliminando tokens innecesarios y acortando nombres de variables o funciones. Así que puedes ver aquí un ejemplo. A la izquierda, pasamos de una función de JavaScript que tiene un objeto dentro de ella, y la minificamos, eliminando comentarios, espacios en blanco, acortando nombres siempre que sea posible. Lo complicado con la minificación y donde entra la parte de optimización es que no todo puede ser minificado o acortado. No puedes minificar palabras clave reservadas como typeof, function, return. No puedes minificar claves de objetos porque son necesarias para hacer búsquedas en nuestro objeto.

3. Minification Strategies

Short description:

El diseño de la API es importante para la minificación. Los métodos de clase no pueden ser minificados, incluso si se consideran privados. Evita búsquedas de objetos profundamente anidadas. Usa config para modificar basado en regex. Usa funciones y objetos en lugar de clases. Los arrays son incluso mejores que los objetos para la minificación. Los hooks de React ilustran esto bien.

De lo contrario, no puedes hacer búsquedas. Y no puedes minificar métodos de clase porque tienes que llamar a los métodos por su nombre. Y así, si los acortas, ya no funcionan. Esto realmente significa que el diseño de la API importa mucho, y cómo diseñas tus programas para que puedan ser minificados más fácilmente puede afectar mucho el tamaño de tu paquete.

Aquí hay un ejemplo de los métodos de clase. A la izquierda hay una clase API de ejemplo, algo que solíamos usar en el Sentry SDK, pero lo des-Sentryfiqué mucho. Y a la derecha aquí hay una versión minificada. Lo embellecí para que mantuviéramos el espacio en blanco para que sea más fácil de leer. Y puedes ver que en la versión minificada, muchos de los nombres aún se mantienen porque todos estos métodos de clase no pueden ser minificados. Son parte de la API pública de esta clase API. Incluso cosas que consideramos privadas como encoded auth aún no se minimizan debido a cómo funciona JavaScript.

Entonces, ¿cuáles son algunas estrategias para que podamos escribir código más amigable con la minificación? Bueno, en primer lugar, intenta evitar búsquedas de objetos profundamente anidadas y patrones de constructor. A la izquierda aquí, puedes ver que tenemos esta búsqueda complicada en event.exception.values.type. Y queremos asegurarnos de que todo exista correctamente así que hacemos esta operación booleana. Pero todos estos valores, exception.values.type, y por supuesto el SentryError aquí, son completamente inminificables. Y así terminamos con mucha información redundante en nuestro paquete. Dado que ya estamos usando un try catch, podemos simplemente acortar esto a una sola línea. Y si encontramos un error de tipo, irá al bloque catch en su lugar.

Otra forma de escribir código más amigable con la minificación es usar config para modificar basado en regex. Entonces, por ejemplo, si volvemos al ejemplo de los métodos de clase aquí, si decimos, oye, todo lo que comience con el guion bajo debería ser minificado, ahora podemos minificar encoded auth y todos sus usos aquí. La mayoría de los empaquetadores tienen config que te permiten configurar modificaciones personalizadas basadas en alguna expresión regular. Por último, y aquí es donde entra el componente de diseño de la API, puedes usar funciones y objetos en lugar de clases. Y esto significa que las clases, por supuesto, tienen toda su API pública y cada método, método público, no puede ser minificado. Pero si usas funciones y objetos, los nombres de las funciones pueden ser minificados porque son simplemente métodos de nivel superior y todo lo que les importa es dónde se llaman y con qué se llaman. Incluso mejor que los objetos, porque, de nuevo, las claves de los objetos no pueden ser minificadas, es realmente usar arrays. Así que si tienes alguna estructura de datos interna que sabes que se usa comúnmente, entonces quizás hacer un array en lugar de un objeto. Los hooks de React realmente hacen esto muy bien. Cosas como useState y useReducer devuelven un array. Así que estos argumentos de array estructurados pueden ser realmente minificados por un empaquetador. Un gran ejemplo de comparar bibliotecas amigables con la minificación es Zod versus ValleyBot.

4. Down-Compilation and Transpilation

Short description:

Zod y ValleyBot ofrecen diferentes enfoques para el diseño de API. La down-compilation es convertir el código fuente a una versión más compatible hacia atrás. Puede resultar en paquetes de JavaScript más grandes. El encadenamiento opcional puede requerir down-compilation para navegadores más antiguos. Considera usar condiciones Booleanas en su lugar. Revisa la generación de tu JavaScript para patrones que se down-compilen mal. Evita polyfills innecesarios actualizando tu lista de navegadores y usando empaquetadores modernos. La transpilation convierte el código fuente entre lenguajes.

Entonces Zod es una biblioteca de validación de esquemas muy popular. ValleyBot es una especie de competidor para esto. Y puedes ver realmente los dos enfoques diferentes en el diseño de API. Para Zod, tienes este patrón de constructor donde puedes notar aquí que string, email, y endsWith están encadenados desde este zexport, y estos métodos encadenados no pueden ser minificados. Y así terminas con todos estos en tu paquete. Y si estás usando Zod mucho y está distribuido por todas partes, entonces eso se acumula con el tiempo. Mientras tanto, para ValleyBot, estas son solo funciones de nivel superior exportadas. Y por lo tanto, todas estas funciones, string, email, y endsWith en el ejemplo de ValleyBot serán minificadas. Requiere este tipo de cambio de diseño de API de nivel superior, pero de repente tienes una biblioteca mucho más amigable con la minificación, y con el tamaño del paquete.

A continuación, pensemos en la down-compilation. La down-compilation es un proceso de conversión de código fuente a una versión más compatible hacia atrás de ese código fuente. Desafortunadamente, el JavaScript más compatible hacia atrás puede ser más grande. Digamos que necesitas apuntar a IE11. Y así estás emitiendo JavaScript compatible con ES5. Esto significa que en realidad no hay clases porque ES5 aún no tenía clases. Esa es una característica de ES6. Y así podrías tener que polyfillearlas o down-compilarlas para tener JavaScript alternativo. Un gran ejemplo de esto es el encadenamiento opcional. Así que en la parte muy izquierda aquí, puedes ver la característica de encadenamiento opcional, que te permite hacer búsquedas profundamente anidadas en objetos. Pero si apuntas a algo más antiguo que ES2020, que es cuando salió el encadenamiento opcional, y quieres soportar más navegadores que eso, terminarás down-compilando tu JavaScript y tu encadenamiento opcional a algo que se ve así. Esto es súper costoso. Y puedes imaginar si usas mucho el encadenamiento opcional, especialmente si esto fuera una gran declaración anidada, tendrías un montón de condicionales aquí. En su lugar, especialmente si usas TypeScript, probablemente puedas simplemente reemplazar esto con una simple afirmación booleana, que es lo que hacemos en nuestro código base del Sentry SDK. De hecho, hacemos lint contra el uso de encadenamiento opcional y obligamos a todos a usar condiciones booleanas en su lugar. Así que lo más importante para esto es realmente mirar cómo se está generando tu JavaScript y asegurarte de que nada se vea extraño, nada se vea mal, y desautorizar patrones que no se down-compilan bien porque necesitas soportar más navegadores. Para los polyfills, porque a veces mucha gente simplemente comienza a inyectarlos innecesariamente, solo echa un vistazo y ve lo que estás empaquetando y actualiza tu lista de navegadores o usa empaquetadores modernos. Por favor, no uses más Webpack 4.

A continuación, tenemos la transpilation. Este es el proceso de convertir código fuente de un lenguaje a otro. Solíamos tener muchos de estos, CoffeeScript, BuckleScript, ReasonML, cosas así.

5. TypeScript Enums and Compression

Short description:

Los enums de TypeScript son costosos y deben evitarse. Usa constantes de cadena en su lugar. Comprime tu código para ahorrar. Prueba los cambios en archivos comprimidos con gzip. Rastrea el tamaño de tu paquete con CodeCub bundle size.

Pero hoy en día, esto prácticamente significa TypeScript y JavaScript para el desarrollador promedio de front-end. Por lo que vale, el transpiler de TypeScript es bastante bueno. Pero una cosa a tener en cuenta es que los enums de TypeScript son bastante costosos, y recomiendo no usarlos. A la izquierda, tenemos un enum. Parece bastante simple, pero a la derecha, podemos ver lo que esto genera. Y esto se debe a que los enums permiten búsquedas inversas. Esto es realmente costoso, y a menudo, los valores del enum no pueden ser minificados en absoluto, tampoco. Y así hay un doble problema allí. Es mucho más fácil simplemente no usarlos, usar constantes de cadena y hacer enums de esa manera. Las cadenas también tienen el beneficio de comprimirse muy bien.

La compresión es lo último de lo que podemos hablar aquí. El navegador descomprime automáticamente los activos JavaScript comprimidos, también CSS y otras fuentes, que están comprimidos con gzip, Brotli o deflate. Y por lo tanto, siempre deberías, junto con minificar tu código, comprimirlo para grandes ahorros mientras los usuarios tienen que cargar tus recursos a través de la red. Lo que termina sucediendo es, sin embargo, que las cadenas repetidas o el código se comprimen muy bien porque la similitud aumentada ayuda con los algoritmos de gzip y Brotli. Así que, por ejemplo aquí, si tuviéramos que cambiar este enum a constantes de cadena repetidas, eso realmente mejoraría su capacidad de gzip. gzip y los otros algoritmos de compresión, sin embargo, pueden ser un poco una caja negra. Es confuso. Y así, la mayor recomendación aquí es, mientras examinas tu paquete y tratas de arreglar tus polyfills, tu down compilation, y tus estrategias de minificación, prueba tus cambios contra lo que esté comprimido con gzip. Y si aún no lo estás haciendo, por favor comprime tu JavaScript antes de enviarlo a tus usuarios.

Así que cubrimos mucho terreno, pero hay mucho más que ver. Realmente la mejor manera de comenzar a explorar y comenzar a investigar es leer más JavaScript generado. Familiarízate con la lectura de código minificado y ve lo que realmente se emite desde tus procesos de construcción. A veces, si echas un vistazo, puedes encontrar algunas victorias rápidas realmente geniales. En general, sin embargo, por favor comienza a rastrear el tamaño de tu paquete. He estado en muchas conferencias diferentes hasta ahora y siempre hago esta pregunta. ¿Cuántos de ustedes están rastreando el tamaño de su paquete? Y la respuesta es decepcionantemente baja. Recomiendo usar CodeCub bundle size. Puedes rastrearlo a lo largo del tiempo. También te dará un comentario en el PR. Pero soy un poco parcial porque ayudé a construirlo.

6. Bundle Size Tracking and Visualization

Short description:

Usa la acción de size limit para rastrear los cambios en el tamaño del bundle. Los analizadores de bundles como Webpack y Rollup pueden ayudar a visualizar el contenido del bundle y las conexiones entre componentes.

Una gran alternativa es la acción de size limit. Esto es lo que usamos en el Sentry SDK. Dejará un comentario en el PR en GitHub que básicamente dice, oh, este era el tamaño del bundle anterior y este es el nuevo tamaño del bundle y esto es lo que ha cambiado. Si quieres profundizar y simplemente no quieres solo leer el JavaScript generado, entonces te recomiendo que uses analizadores de bundles para tus bundlers. Hay uno de Webpack, el de Rollup, que también funciona para Vite. Estas son formas realmente geniales de ver visualmente cómo tus bundles, qué hay en tu bundle y las conexiones entre diferentes componentes.

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