La única forma de comer un elefante: Code Splitting con Server Side Rendering

Rate this content
Bookmark

El code splitting es una forma de optimizar el rendimiento de nuestra aplicación al enviar menos código a los usuarios finales. La forma más común de code splitting es utilizar importaciones dinámicas después de una interacción del usuario. En nuestro caso, vamos a hablar sobre cómo cargar condicionalmente solo las partes de la aplicación que necesitamos durante el server side rendering. Vamos a discutir los problemas y las soluciones, para que puedas probarlo en tu propio proyecto.

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

FAQ

SSR significa Server Side Rendering, el cual es importante porque permite que el contenido de un sitio web se renderice en el servidor antes de ser enviado al navegador. Esto mejora el SEO y la velocidad de la primera carga, ya que los rastreadores pueden leer el contenido directamente desde el servidor.

Inicialmente, todo el contenido HTML se servía como cadenas de texto desde los servidores. Con el tiempo, el manejo de JavaScript se volvió complejo, especialmente con herramientas como jQuery y Handlebars, lo que llevó a la creación de aplicaciones de una sola página (SPAs) que movían la renderización al lado del cliente para mejorar la interactividad.

Las SPAs incrementaron el uso de JavaScript, lo que llevó a paquetes más grandes y problemas de rendimiento en la carga inicial. Además, como los rastreadores no pueden leer JavaScript fácilmente, el SEO se convirtió en un problema significativo.

Se reintrodujo el SSR (Server Side Rendering) utilizando el mismo JavaScript de las SPAs, pero renderizado como una cadena en el servidor. Esto permitió que los rastreadores leyeran el contenido, mejorando así el SEO sin desechar el JavaScript existente.

Se implementó la división de código mediante importaciones dinámicas, permitiendo que el contenido no estuviera en un único paquete, sino que se cargara dinámicamente según se necesitara. Esto ayudó a reducir el tamaño del paquete inicial y mejorar el rendimiento de la carga.

Los componentes cargables en React permiten definir fácilmente qué componentes se deben cargar dinámicamente y manejar su renderización tanto en el servidor como en el cliente. Esto optimiza el rendimiento y la carga de recursos, manteniendo la división de código eficiente.

Lena Zhukova
Lena Zhukova
9 min
17 Jun, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
La charla aborda los desafíos de manejar la manipulación del DOM con JavaScript y los problemas de rendimiento que surgen al usar SPAs. Explora la solución del server-side rendering (SSR) para abordar las preocupaciones de SEO, pero señala que el tamaño del paquete sigue siendo un problema. Se introduce el code splitting como una forma de cargar contenido dinámicamente, pero presenta desafíos para el SSR. El orador sugiere una solución utilizando vanilla.js que resuelve el problema sin problemas de escalabilidad.

1. SSR Code Splitting and Vanilla.js

Short description:

Hola, mi nombre es Lena y hoy estoy aquí para hablarles sobre la única forma de comer un elefante. Todo comenzó en un momento en el que no existía React. Las páginas HTML se servían como cadenas de texto, pero JavaScript dificultaba la manipulación del DOM. Los héroes de JavaScript introdujeron las SPAs, pero el aumento de JavaScript resultó en un peor rendimiento. Para resolver el problema de SEO, se implementó el SSR, pero el tamaño del paquete seguía siendo un problema. Se introdujo la división de código para cargar contenido de forma dinámica, pero presentaba desafíos para el renderizado en el lado del servidor. La solución vanilla.js resuelve el problema sin problemas de escalabilidad.

Probablemente puedas recordarlo poco a poco, y tengo un aviso importante que hacer. No, recuerdo que es una conferencia de React, pero contaré mi breve historia sobre la división de código de SSR y por qué necesitas usarlos juntos principalmente con vanilla JS.

Todo comenzó en un momento en el que no existía React. Algunos recuerdan esos tiempos y otros ni siquiera pueden creer que hubo un tiempo en el que no existía React. Pero en ese momento, todas las páginas HTML se servían como cadenas de texto. No lo creerías. Pero todo el contenido era una cadena servida desde los servidores, y se veía algo así. Uno escribía todo el contenido HTML y había muchos, tantos como filas tenías, y en realidad todos estaban contentos en ese momento. Era bastante sencillo en realidad, hasta que, ya no lo era. Y probablemente puedas adivinar la razón. Era por culpa de JavaScript.

Se volvió demasiado tedioso manejar todo el JavaScript, toda la manipulación del DOM con jQuery, ya sabes, con herramientas de renderizado como EGS, handlebars y muchas más en todos los lenguajes de servidor, y también las solicitudes al servidor hicieron sufrir a las personas, y apenas puedo decirte quién sufrió más, si los usuarios o los desarrolladores, con todo su JavaScript, jQuery y handlebars. Entonces, llegaron los héroes de JavaScript y decidieron tener SPAs, aplicaciones de una sola página, y y se imaginaban renderizando todo el contenido en el lado del cliente y decidieron que el navegador podía manejar la navegación sin volver al servidor y pensaron, pensaron que era genial, y también decidieron que podían hacer enrutamiento en el lado del cliente, no porque fuera fácil, sino porque era difícil. Pero pudieron hacerlo. Y el HTML se volvió muy pequeño y superficial y ya no se renderizaba nada en el servidor. Todo se renderizaba en el lado del cliente con uno de los frameworks de JavaScript. Y ahí había más JavaScript, más herramientas para construirlo en un solo paquete y más problemas de JavaScript para resolver, más conferencias de JavaScript para hablar sobre estos problemas y nacieron nuevos monstruos. En realidad, más JavaScript resultó en paquetes más grandes, lo que resultó en un peor rendimiento, en la primera renderización, y en todo lo demás, y los usuarios comenzaron a sufrir y también los negocios comenzaron a sufrir porque el SEO era un problema. Los rastreadores no pueden leer JavaScript, necesitan cadenas de texto. Así que los héroes de JavaScript volvieron de nuevo y decidieron recuperar el SSR, pero esta vez conservaron el mismo JavaScript que habían escrito, porque era tan hermoso como para desecharlo y decidieron que la solución era renderizar este JavaScript que tenían como una cadena en el servidor y tener una función de JavaScript que devolviera una cadena. Así que esa fue una buena solución para el SSR y resolvió el problema de SEO. Pero no resolvió el problema del tamaño del paquete, ¿verdad? Así que estaban usando el mismo JavaScript tanto en el lado del cliente como en el lado del servidor. Entonces, los héroes de JavaScript decidieron que necesitaban idear una solución para la división de código. Y lo hicieron. Implementaron estas importaciones dinámicas. Aquí puedes ver que hay un problema con este código. No porque no esté en React, sino porque es asíncrono. Y sí resuelve el problema de un paquete grande de JavaScript. Puedes ver que ahora el contenido no está en un solo paquete, sino que se carga de forma dinámica. Pero las importaciones dinámicas son para el lado del cliente y no se pueden renderizar en el lado del servidor porque el servidor necesita hacerlo de forma sincrónica. Así que cuando tu contenido depende de la ruta, es decir, cuando necesitas este contenido de inmediato para que el cliente lo vea, puedes tener división de código tanto en el lado del servidor como en el lado del cliente. El único problema que necesitas resolver es decidir en qué entorno te encuentras y cargarlo de forma sincrónica cuando no estás en el entorno del lado del cliente y cargarlo de forma sincrónica cuando sí lo estás. Así que esta es la solución vanilla.js para este problema y aunque me gusta mucho vanilla.js, todos sabemos que no es escalable. Resuelve el problema, pero no es escalable. Pero afortunadamente tenemos React y una solución de biblioteca para ello, y tenemos componentes cargables y es tan fácil con los componentes cargables como lo escribí en vanilla.js Todo lo que necesitas hacer es proporcionarle a esta biblioteca información sobre todos los fragmentos que tienes y pedirle que renderice tu contenido como una cadena en el lado del servidor y luego Loadable decidirá como por arte de magia en qué entorno te encuentras y renderizará tu contenido tanto en el lado del servidor como en el lado del cliente y con división de código, por lo que no servirás paquetes grandes a tus clientes y vivieron felices para siempre SSR codes se casó con SSR y la división de código se casó con React y los componentes cargables y nuestros usuarios están felices y nuestros héroes de GS están listos para conquistar nuevos monstruos. Gracias

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

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.
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.
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.
Solucionando Problemas de Rendimiento en React
React Advanced 2023React Advanced 2023
22 min
Solucionando Problemas de Rendimiento en React
Top Content
This Talk discusses various strategies to improve React performance, including lazy loading iframes, analyzing and optimizing bundles, fixing barrel exports and tree shaking, removing dead code, and caching expensive computations. The speaker shares their experience in identifying and addressing performance issues in a real-world application. They also highlight the importance of regularly auditing webpack and bundle analyzers, using tools like Knip to find unused code, and contributing improvements to open source libraries.

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 WorkshopFree
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 🤐)
Desarrollando Blogs Dinámicos con SvelteKit & Storyblok: Una Masterclass Práctica
JSNation 2023JSNation 2023
174 min
Desarrollando Blogs Dinámicos con SvelteKit & Storyblok: Una Masterclass Práctica
Top Content
Featured WorkshopFree
Alba Silvente Fuentes
Roberto Butti
2 authors
Esta masterclass de SvelteKit explora la integración de servicios de terceros, como Storyblok, en un proyecto SvelteKit. Los participantes aprenderán cómo crear un proyecto SvelteKit, aprovechar los componentes de Svelte y conectarse a APIs externas. La masterclass cubre conceptos importantes incluyendo SSR, CSR, generación de sitios estáticos y despliegue de la aplicación usando adaptadores. Al final de la masterclass, los asistentes tendrán una sólida comprensión de la construcción de aplicaciones SvelteKit con integraciones de API y estarán preparados para el despliegue.
Construyendo aplicaciones web que iluminan Internet con QwikCity
JSNation 2023JSNation 2023
170 min
Construyendo aplicaciones web que iluminan Internet con QwikCity
Featured 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.
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
WorkshopFree
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 🤐)
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.