Next.js: Reshaping Arquitectura de Aplicaciones Web para la Excelencia en Rendimiento

Hola, mi nombre es Myrna Sochnaeser y soy una desarrolladora principal full-stack en L'Oreal Tech Accelerator. Tech Accelerator es un departamento interno dedicado a impulsar la innovación digital en L'Oreal. Diseñamos aplicaciones para ayudar al personal de L'Oreal a ser más productivo. Hoy veremos cómo remodelamos nuestra arquitectura de aplicaciones web para lograr una excelencia en el rendimiento y por qué decidimos utilizar Next.js. En L'Oreal, hay algunos factores que nos permiten determinar si tenemos una buena aplicación, como el rendimiento, la accesibilidad, la seguridad, etc. Pero hoy nos centraremos en el rendimiento, que indirectamente también nos permite mejorar nuestra experiencia de usuario. En Tech Accelerator, tenemos una arquitectura en la que todas nuestras aplicaciones dependen. Nuestro navegador intentará obtener los datos o la información que necesita desde el CDN. Si no tiene éxito, los obtendrá de las dos aplicaciones alojadas en App Engine. Nuestro backend, que contiene todos nuestros puntos finales, está alojado en CloudRAM y los datos están alojados en Cloud SQL. Intentaremos reemplazar las dos aplicaciones alojadas en App Engine con Next.js y tener solo una aplicación. Refresquemos nuestra memoria mientras revisamos las diferentes formas de renderización que podemos hacer con Next.js. Next.js es un marco de trabajo que nos permite crear una aplicación web donde partes de nuestro código pueden renderizarse tanto en el servidor como en el cliente. Por eso hablamos de renderización en el lado del cliente o pre-renderizado en el servidor. Incluso el pre-renderizado en el servidor se divide en muchos tipos, como la renderización en el lado del servidor o la generación estática o otros. Al principio teníamos una aplicación de una sola página donde necesitábamos descargar un archivo HTML y un archivo JS grande para todas las aplicaciones. El archivo HTML estaba casi vacío y el archivo bundled contenía toda la información necesaria. Pero con Next.js, tendremos un archivo index.html en el archivo chunk o bundled.js por página. Y estos archivos solo contendrán lo necesario para renderizar esta página específica en la que nos encontramos. ¿Cómo funciona la renderización en el lado del cliente? Después de construir nuestro frontend, obtendremos dos archivos, el index.html y el bundled.js que se almacenaron en el CDN. Una vez que intentemos acceder a nuestra aplicación, el navegador obtendrá el index.html del CDN y luego descargaremos, el navegador descargará el archivo JS y lo ejecutará. Y una vez que se complete la ejecución, la página web será visible para el usuario. Pero aún necesitaremos obtener los datos del servidor para ajustar los componentes con los datos correctos y eliminar el estado de carga. Entonces, en resumen, tendremos una página en blanco hasta que descarguemos y ejecutemos el bundled.js y la página de carga hasta que obtengamos los datos que necesitamos. Con la renderización en el lado del cliente, reducimos la carga del servidor, ya que el servidor solo necesita proporcionar el HTML inicial y el archivo JavaScript, y también simplificamos la lógica del backend, ya que el servidor actuará principalmente como una API de datos, lo que lleva a un código de backend más limpio y simple. Pero, por otro lado, tenemos una carga inicial de página más lenta, ya que el navegador necesita descargar y ejecutar el JavaScript antes de renderizar la página o mostrar cualquier cosa.

En cuanto a la renderización en el lado del servidor, el navegador obtendrá el archivo HTML del servidor. El archivo HTML se llenará con los datos correctos. Podemos ver directamente los componentes llenos con los datos correctos en el navegador, pero no estarán hidratados. La interacción con los botones y los enlaces

La aplicación no funcionará hasta que obtengamos y descarguemos el archivo JS desde el CDN. Podemos ver que el bloque de página en blanco se reduce y podemos ver directamente algo en la aplicación web. Por lo tanto, con SSR, tenemos una carga de página inicial más rápida y un mejor rendimiento para usuarios en dispositivos de baja gama o con una conexión a internet lenta, ya que la mayor parte del proceso de renderizado es manejado por el servidor. Pero, por otro lado, aumentamos la carga del servidor, especialmente al lidiar con un gran número de solicitudes simultáneas, lo que afecta los tiempos de respuesta del servidor. Y reducimos la interactividad, ya que pueden ser necesarias solicitudes adicionales para actualizar el contenido de la página. Por lo tanto, SSR es perfecto para sitios web de contenido. La generación de sitios estáticos es similar al renderizado en el lado del servidor, pero con una pequeña diferencia: tanto el index.html como el bundle.js se crean durante la construcción de la aplicación y se almacenan en el CDN. Por lo tanto, mostramos una página interactiva muy rápido. Debes utilizar la generación de sitios estáticos con Next.js cuando desees proporcionar cargas de página más rápidas y cargar páginas con contenido pesado o contenido que nunca cambiará, es decir, estático. Por ejemplo, para blogs, documentación, portafolios, etc. Dicho esto, te daré un poco de contexto sobre la aplicación que queremos mejorar en términos de rendimiento. La aplicación es una aplicación de una sola página y tenemos tres tipos de páginas. Tenemos la página de inicio que es la misma para todos los usuarios y es estática, una página para visualizar los datos y una página para crear datos basados en una configuración preestablecida y un algoritmo de API. La aplicación es utilizada por 40 usuarios en seis países diferentes y tenemos un poco más de seis gigabytes de datos. En esta aplicación, el usuario tiene aproximadamente dos segundos de pantalla en blanco. Esto se debe a que para que la aplicación web sea visible y funcional, el navegador necesita descargar el archivo JS y ejecutar React. Pero como el archivo JS es grande, la descarga y ejecución del archivo lleva un poco de tiempo. Una vez que el usuario comienza a ver algo en la aplicación web, es el estado de carga durante un cierto período de tiempo dependiendo de la página que esté viendo. Esto se debe a que necesitamos esperar a que el navegador llame a los puntos finales y obtenga los datos que queremos mostrar. La solución para nosotros fue Next.js. Next.js simplifica el proceso de dividir el archivo index.html y el archivo bundle.js en varios archivos por página, proporcionando una división automática del código. Este enfoque ayuda a mejorar el estado de carga inicial de las páginas web, proporcionando una experiencia de usuario más rápida y eficiente. Aquí, por ejemplo, podemos ver algunos números que obtuvimos en nuestro libro. Para la página de inicio, teníamos una pantalla en blanco de dos segundos y ahora, con la generación de sitios estáticos que agregamos, modificamos nuestra página de inicio para utilizar este tipo de renderizado, tenemos una visualización instantánea en la aplicación web. Para la página de visualización de datos, agregamos renderizado en el lado del servidor y antes, con una aplicación de una sola página, teníamos un estado de carga de cinco segundos donde veíamos la página pero se estaba cargando los datos. Ahora, como estamos haciendo toda la implementación y obteniendo los datos en el lado del servidor, en menos de un segundo mostraremos los datos. En cuanto a la creación de una nueva página de datos, todavía está en progreso. Aún no trabajamos en eso, pero vamos a utilizar el renderizado en el lado del cliente, ya que habrá muchas interacciones entre los usuarios y la aplicación web. En conclusión, con Next.js podemos mejorar el rendimiento de nuestras aplicaciones, ya que tenemos una división automática del código y diferentes tipos de renderizado que podemos aplicar en las diferentes páginas. Pero si no utilizamos el renderizado de la manera correcta, podríamos disminuir el rendimiento de las aplicaciones. Así que debemos pensar más en cómo hacer los renderizados. Eso es todo, ¡gracias!