No quieres renderizar tu aplicación Next.js en el lado del servidor

Rate this content
Bookmark

Next.js es un framework fantástico; proporciona muchas características únicas que te ayudan a construir cualquier aplicación web sin esfuerzo. Pero cuando se trata de elegir la estrategia de renderizado adecuada para tus páginas, puedes enfrentar un problema; ¿cómo debo renderizarlas? ¿Debo generarlas estáticamente en tiempo de compilación? ¿Debo renderizarlas en el lado del servidor en tiempo de ejecución? Bueno, la respuesta es sorprendente. El renderizado en el lado del servidor rara vez es la mejor opción, y vamos a explorar por qué (¡y cómo resolver este problema!)

28 min
21 Jun, 2022

Video Summary and Transcription

Next.js es un framework que permite el renderizado en el lado del cliente y transiciones de página fáciles. El renderizado en el lado del servidor ofrece una aplicación más segura y una mejor optimización para motores de búsqueda, pero requiere un servidor. La generación de sitios estáticos proporciona un rendimiento y escalabilidad excepcionales, pero tiene limitaciones. La regeneración estática incremental resuelve el problema de reconstruir todo el sitio web. Elegir la estrategia de renderizado adecuada depende del escenario específico, y para sitios web de comercio electrónico, se recomienda la generación de sitios estáticos con regeneración estática incremental.

Available in English

1. Introducción a Next.js y sus beneficios

Short description:

¡Hola a todos! Soy Michele, un arquitecto de software senior en NearForm y autor de Real-World Next JS. NearForm es una empresa de servicios profesionales especializada en Node.js, React, Next.js, TypeScript y mantenimiento de paquetes de código abierto. Ahora, sumerjámonos en Next.js. Es un marco de trabajo maravilloso que permite el renderizado del lado del cliente, brindando una experiencia similar a una aplicación nativa con transiciones de página sencillas y carga diferida de componentes. Además, no requiere un servidor si no lo necesitas.

Hola a todos y bienvenidos a mi charla, No Quieres Servir un Renderizador Estático, Tu Próxima Aplicación de Next.js. Antes de comenzar, permítanme presentarme brevemente. Soy Michele. Trabajo como arquitecto de software senior en NearForm. Soy un experto en desarrollo de Google y un MVP de Microsoft. También soy el autor de Real-World Next JS, que es un libro que, como podrán imaginar, habla sobre Next.js. Así que si después de la charla les gustaría conversar sobre Next.js, no duden en contactarme. Me encantaría hablar con ustedes. Un par de palabras sobre NearForm. Somos una empresa de servicios profesionales especializada en Node.js, React, Next.js, TypeScript y lo que sea. Mantenemos muchos paquetes de código abierto que se descargan 1.2 mil millones de veces al mes en total. Así que si están buscando un trabajo remoto y están realmente comprometidos con el código abierto, no duden en contactarnos. Me encantaría presentarles a la empresa. Pero eso no es por lo que estamos aquí, así que hablemos de Next.js. En primer lugar, ¿qué es Next.js? ¿Por qué queremos usarlo? ¿Y por qué es tan maravilloso?

Cuando React comenzó a ser algo, básicamente solo teníamos renderizado del lado del cliente. Esa era la norma. Básicamente generamos un gran paquete y lo servimos a través de la red. Este paquete contendrá toda la aplicación y tan pronto como se transfiera al navegador, el navegador leerá el archivo, el archivo JavaScript, lo ejecutará y tendremos el DOM listo para ser navegado.

Entonces, básicamente, el problema con este enfoque, pero veremos muchos problemas más adelante, es que esto es lo que vemos cuando descargamos por primera vez el paquete. Mientras se descarga, mientras se ejecuta, vemos un spinner. Después de varios segundos, veremos la página completa lista para ser navegada. Así que este enfoque tiene sus pros y sus contras. Veamos por qué podría ser una buena o mala elección. En primer lugar, te hace sentir que tu aplicación es como una aplicación nativa, y eso se debe a que las transiciones de página son realmente fáciles de manejar y no tienes que refrescar la página cada vez. Cada vez que haces clic en un botón, por ejemplo, y vas a otra página, no necesitas refrescar la página. Ya tienes todos los componentes que necesitas que se cargan de forma diferida directamente en el navegador. Por ejemplo, estás en la página de inicio, haces clic para leer un artículo, todo el DOM se actualiza, pero la página no. Entonces, React intercambiará el contenido con el nuevo y ejecutará los componentes diferidos que aún no se han ejecutado durante la carga inicial. Otra gran ventaja del renderizado del lado del cliente es que no necesitas un servidor. Y si lo necesitas porque ya tienes uno y quieres servir tu aplicación del lado del cliente

2. Pros and Cons of Server-side Rendering in React

Short description:

Y no hay carga de trabajo del servidor, lo cual es bastante bueno porque es muy fácil de escalar. Pero si no tienes un servidor, eso también es bueno, simplemente puedes poner tus archivos, activos estáticos, en un CDN en S3 en AWS, por ejemplo, o usar páginas de Cloudflare, o lo que sea. Y simplemente puedes alojar una aplicación completa directamente desde algo que no necesita un servidor en absoluto. Si bien esto es bueno para muchas cosas, también tiene algunos problemas, por ejemplo, con la optimización de motores de búsqueda. React no es particularmente bueno para la optimización de motores de búsqueda, especialmente en mercados fuera de Europa y América. Además, React tiene un tiempo de carga inicial lento. El renderizado del lado del servidor ofrece un enfoque diferente, proporcionando una aplicación más segura, compatibilidad para usuarios sin JavaScript y una mejor optimización de motores de búsqueda. Sin embargo, requiere un servidor y conlleva mayores costos de mantenimiento.

desde un servidor, no requiere mucha potencia. Y no hay carga de trabajo del servidor, lo cual es bastante bueno porque es muy fácil de escalar. Pero si no tienes un servidor, eso también es bueno, simplemente puedes poner tus archivos, activos estáticos, en un CDN en S3 en AWS, por ejemplo, o usar páginas de Cloudflare, o lo que sea. Y simplemente puedes alojar una aplicación completa directamente desde algo que no necesita un servidor en absoluto. Si bien esto es bueno para muchas cosas, también tiene algunos problemas, por ejemplo, con la optimización de motores de búsqueda. Todos sabemos que React no es particularmente bueno para la optimización de motores de búsqueda, lo cual es cierto. Pero realmente depende del mercado que te interese. Por ejemplo, si te interesan los mercados europeo y americano, sabemos que Google es el motor de búsqueda número uno y Google hoy en día es capaz de indexar contenido de React. Pero puede haber otros motores de búsqueda que sean más populares en otros continentes, como Asia, por ejemplo, o África, que no leen páginas generadas por React. Entonces, si realmente te importan esos continentes y mercados, definitivamente deberías buscar algo diferente para construir tu aplicación.

Otro inconveniente es que React es realmente malo para el tiempo de carga inicial de la página, como vimos. Entonces, la primera vez que descargas un paquete, tienes que esperar varios segundos para poder navegarlo. Por eso comenzamos a ver el renderizado del lado del servidor como una forma diferente de abordar el renderizado de React específicamente. Con el renderizado del lado del servidor, esto es lo que obtienes tan pronto como solicitas una página. Puede llevar un par de segundos, porque el servidor aún necesita renderizar la aplicación en el lado del servidor, pero eventualmente te enviará la página completa lista para navegar.

Entonces, este enfoque también tiene sus pros y sus contras. Veámoslos. Una ventaja es que la aplicación podría ser un poco más segura. Eso se debe a que podrías tener cookies del lado del servidor, por ejemplo, para la autenticación, y no tienes que compartir esas cookies con el cliente, lo que hace que tu aplicación sea más segura. Puedes ocultar algunas solicitudes de servidor a servidor sin exponerlas en el cliente. Eso limita la posibilidad de un ataque de intermediario, por ejemplo. Además, terminas teniendo sitios web más compatibles. Si no tienes JavaScript habilitado, aún verás la primera renderización de tu aplicación. La optimización de motores de búsqueda se mejora gracias al renderizado del lado del servidor, porque básicamente terminas teniendo un producto que es igual al que podrías tener con Ruby on Rails, JavaScript Boot, Laravel, o lo que sea. El contenido puede ser altamente dinámico y puedes tener ese tipo de dinamismo directamente en el servidor. Entonces, dependiendo del usuario que esté conectado actualmente, por ejemplo, podrías decidir renderizar cosas diferentes directamente en el servidor. Por supuesto, también tiene algunos problemas. Por ejemplo, se requiere un servidor. Cada solicitud se renderiza en el servidor y se transmite a los navegadores una vez renderizada. Por lo tanto, habrá una mayor carga de trabajo en el servidor.

3. Static Site Generation and Hybrid Rendering

Short description:

La generación de sitios estáticos es una tercera opción que permite una fácil escalabilidad y un rendimiento excepcional. Sirve archivos estáticos directamente al navegador, lo que lo hace seguro y elimina la necesidad de renderizado en el lado del servidor. Sin embargo, tiene limitaciones como la falta de contenido dinámico en el lado del servidor y la necesidad de reconstruir y volver a implementar toda la aplicación para realizar cambios. React ofrece un renderizado híbrido, lo que permite diferentes estrategias de renderizado para diferentes páginas y partes de la aplicación. El renderizado en el lado del cliente requiere esperar a que se ejecute el paquete de JavaScript.

Esto conlleva costos de mantenimiento más altos, ya que tendrás que mantener un servidor. Y esto es costoso. Entonces, debes escalar el servidor horizontalmente, por ejemplo, si deseas agregar más servidores para servir tu aplicación, porque necesitas escalar, o necesitas agregar más potencia al servidor que ya tienes si deseas escalar verticalmente. Eso depende, por supuesto, de cómo quieras escalar tus aplicaciones. Entonces, hay una tercera opción que vamos a explorar, que es llamada generación de sitios estáticos. Al igual que el renderizado en el lado del servidor, esto es lo que obtienes cuando solicitas una página generada de forma estática. Básicamente, tan pronto como haces una solicitud, no necesitas renderizarla en el lado del servidor, porque ya la renderizaste durante el tiempo de construcción. Entonces, servirás tu aplicación como archivos estáticos directamente al navegador. Este enfoque tiene ventajas y desventajas, una ventaja es que es muy fácil de escalar, y eso se debe nuevamente a que no necesitas un servidor. Ya tienes activos estáticos, los colocas en un CDN, en S3, en donde quieras, en un bucket, y simplemente los sirves como activos estáticos, porque no necesitas renderizar la página cada vez que recibes una solicitud. Entonces, eso conduce a un rendimiento excepcional, porque la página está lista, no necesitas renderizarla ni en el lado del cliente ni en el lado del servidor. Entonces, la página está lista, solo tienes que transferirla. Es realmente seguro porque no tienes un servidor, por lo que no hay forma de atacar directamente al servidor, así que eso es otra cosa a tener en cuenta. Por supuesto, nuevamente, tiene algunas desventajas. Veámoslas. Entonces, no se permite contenido dinámico en el lado del servidor, porque no tienes un servidor, por lo que no puedes renderizar cosas específicas para un usuario específico en el servidor, porque no tienes un servidor en absoluto. Se basa en el renderizado en el lado del cliente para todas las partes dinámicas de tu aplicación. Entonces, por ejemplo, si estás en Instagram y estás desplazándote por el feed, podrías generar la página del feed con la generación de lado estático, lo siento, con la generación de lado estático, pero eventualmente deberás esperar a que el cliente comprenda quién es el usuario que ha iniciado sesión y luego renderizar el contenido que es específico para ellos. Y otra cosa, que es realmente molesta, diría yo, es que si necesitas cambiar algo, por ejemplo, un error tipográfico en la página de inicio, deberás volver a cargar, reconstruir y volver a implementar toda la aplicación. Eso se puede solucionar con la regeneración estática incremental, pero lo veremos en detalle más adelante. Entonces, una buena característica de React es que no tienes que comprometerte, no tienes que elegir una estrategia de renderizado para todo el sitio web. Pero puedes hacerlo de manera granular en la página, cuando básicamente renderizas la página individual. Esto se llama renderizado híbrido. Entonces, básicamente podrías decir, okay, la página de inicio para este sitio web será una página generada estáticamente. Si estás en un blog, la página de la publicación puede generarse dinámicamente con el renderizado en el lado del servidor, por ejemplo. Eso es genial. Y algunas partes de la aplicación pueden ser renderizadas solo en el lado del cliente. Entonces puedes elegir cuánto tiempo básicamente el usuario tiene que esperar antes de acceder al contenido. Veamos en detalle a qué me refiero con esperar. Entonces, por ejemplo, esto es el renderizado en el lado del cliente, ¿verdad? Hacemos una solicitud y tan pronto como hacemos la solicitud, el servidor o el CDN nos enviarán una página vacía. Tan pronto como se ejecute el paquete de JavaScript que contiene la aplicación de React, comenzaremos a ver cómo se monta la aplicación en el navegador. Entonces, como puedes ver, el servidor será muy rápido en enviar una respuesta,

4. Incremental Static Regeneration and Caching

Short description:

Con el renderizado en el lado del servidor, solicitamos al servidor una página específica, esperamos a que se renderice correctamente y luego la transmitimos al cliente. La regeneración estática incremental resuelve el problema de reconstruir todo el sitio web por cada cambio. Al establecer un valor de revalidación de cinco minutos, la página se regenera para cada nueva solicitud después de ese tiempo. Si no hay cambios, se servirá la versión en caché de la página.

pero tendremos que esperar. A medida que pasa el tiempo, tenemos que esperar a que se cargue la página. Con el renderizado en el lado del servidor, es un poco diferente. Solicitamos al servidor una página específica. Esperamos milisegundos, con suerte, o segundos dependiendo de lo buenos que seamos escribiendo React o qué tan lentas sean las API detrás de nuestras aplicaciones. Y luego, cuando la página se renderiza correctamente en el servidor, la transmitimos al cliente. La generación de sitios estáticos parece ser la combinación perfecta. Tan pronto como hacemos una solicitud, obtenemos una respuesta completa. Por eso me gusta hablar de la regeneración estática incremental porque básicamente resuelve un gran problema que tenemos con la generación de sitios estáticos. No queremos reconstruir todo el sitio web cada vez que hacemos un cambio, porque esto es bueno, lo que estamos viendo en la diapositiva es bueno. Pero por ejemplo, si cambio de opinión y comienzo a amar a los setters irlandeses, por ejemplo, tendré que reconstruir todo el sitio web. Pero afortunadamente, con la regeneración estática incremental, ese no es el caso. Veamos cómo funciona. Básicamente, esta es nuestra página en este momento. Esta es la página de inicio de mi sitio web, porque amo a los setters ingleses. Y digamos que tenemos un valor en nuestro getStaticProps que se llama revalidate, establecido en cinco minutos. Entonces, cada cinco minutos, tenemos que revalidar esa página, lo que significa que tenemos que reconstruirla. Publico la página. Después de un minuto, un usuario viene al sitio web y verá esa página. Después de tres minutos, otro usuario viene al sitio web y verá la misma página exacta. Lo mismo, por supuesto, para el tercer usuario que ve nuestro sitio web después de cinco minutos. Recuerda, esto es perezoso. Entonces, si ningún usuario ve la página nuevamente a partir de ahora, Next.js no volverá a cargar la aplicación en sí misma. No volverá a renderizar, diría yo, la página de inicio en ese caso. Pero decimos que cada cinco minutos, cuando llega una nueva solicitud, tenemos que regenerar la página. Eso es lo que está sucediendo básicamente. Regeneramos la página y el siguiente usuario después de cinco minutos verá una página totalmente nueva con un nuevo fondo de color con un setter irlandés en lugar de uno inglés, y eso es lo que sucederá después de cuatro minutos para otro usuario y después de cinco minutos para otro usuario. Y nuevamente, a partir de ahora después de cinco minutos, si otro usuario viene al sitio web, necesitaremos revalidar la página. Entonces, básicamente si no hay cambios, veremos la página renderizada en el lado del servidor. Pero pondremos algunas cabeceras de caché para que nuestro caché pueda servir una versión en caché de la página. Si no hay cambios, seguiremos viendo la misma página.

5. Avoiding Server-side Rendering and Playing Smart

Short description:

El renderizado en el lado del servidor de React aún no es eficiente. JSX requiere mucho esfuerzo en el lado del servidor, ralentizando el servidor y requiriendo escalabilidad. Ir sin servidor resuelve el problema de escalabilidad, pero tiene un costo. Por ejemplo, usar Google Cloud Functions puede costar miles de dólares al mes. Compute Engine es más barato pero aún tiene problemas de renderizado en el lado del servidor. Para superar esto, es importante jugar de manera inteligente y considerar el escenario específico.

De acuerdo, pero dicho esto, ¿por qué querría evitar el renderizado en el lado del servidor? En mi opinión, el renderizado en el lado del servidor de React aún no es realmente eficiente. Esto no es culpa de Next.js. No es culpa de nadie, sino de JSX. JSX no es realmente eficiente como un lenguaje de marcado o no sé cómo llamarlo, pero no es realmente eficiente cuando se trata de renderizado en el lado del servidor. Cada solicitud requiere mucho esfuerzo en el lado del servidor, lo que ralentiza el servidor, por lo que es necesario escalarlo y agregar más potencia de cómputo y más servidores para satisfacer la creciente demanda de las páginas de su aplicación. Puede ser fácil para un arquitecto en cierto punto decir, sí, ve sin servidor. Sabes que no tienes ese problema si vas sin servidor. Básicamente, implementas tu aplicación de Next.js en AWS Lambda, Google Cloud Functions, Azure Functions, lo que sea, y no necesitas escalar. Eso es correcto, pero ¿a qué costo? No es barato. Veamos un pequeño ejemplo en Google Cloud Platform. Digamos que este es el precio de Google Cloud Functions. Entonces, digamos que para los primeros dos millones de invocaciones por mes no pagamos nada. Más allá de los dos millones, pagamos 40 centavos por cada millón de invocaciones. Suena barato, ¿verdad? Bueno, veremos más adelante cuánto costará. Como puedes ver, también pagas el tiempo de computación cada 100 milisegundos. No tengo idea de cómo pronunciar esos números pequeños, así que perdóname. También pagas por la red. El primer gigabyte de transferencia de tráfico es gratuito, luego pagas 12 centavos por gigabyte. Suena barato, ¿verdad? Entonces, digamos que tenemos una aplicación que maneja 100 solicitudes de renderizado en el lado del servidor concurrentes por segundo, lo que equivale a 259 millones y 200,000 solicitudes por mes. ¡Es increíblemente difícil para mí, como italiano, decir números en inglés! Lo siento mucho, pero es una gran cantidad de solicitudes, ¿verdad? El tiempo de ejecución promedio, digamos que es de 300 milisegundos. Podemos usar la opción de RAM más barata, que es de 128 megabytes, y necesitaremos alrededor de 100 kilobytes de ancho de banda por ejecución y, bueno, necesitaremos más, pero digamos, para simplificar, que esto es lo que estaremos transfiriendo. ¿Cuánto costaría? Sí, usando Google Cloud Functions, por ejemplo, costará tres mil dólares al mes, pero escalará, por supuesto, pero si obtienes más solicitudes, el precio será cada vez más alto, por lo que no es realmente sostenible para aplicaciones a gran escala. Si volvemos, por ejemplo, a Compute Engine con dos CPUs virtuales y ocho gigabytes de RAM, pagarás alrededor de cincuenta y dos dólares al mes, lo cual es mucho más barato, pero aún tendrás el problema del renderizado en el lado del servidor porque necesitarás escalarlo, por lo que eventualmente querrás volver a ir sin servidor, pero eso costará mucho, así que querrás volver nuevamente a Compute Engine, por ejemplo, pero no escalará o se volverá realmente costoso. Entonces, ¿cómo salimos de esa mala situación? Mi sugerencia sería jugar de manera inteligente según el escenario. Comencemos con un ejemplo de escenario. Digamos que queremos construir una aplicación de red social, como Instagram o cualquier otra, así que quiero hacer un pequeño juego de preguntas contigo. Te daré un par de segundos para pensar en una respuesta, así que esta es la primera pregunta. Ya discutimos esto, veamos si estabas prestando atención. Digamos que tenemos que construir una función de página de feed para nuestra aplicación, por ejemplo, en Instagram, al desplazarse por la página de feed, la página de inicio de Instagram, el contenido es realmente dinámico y personalizado para cada usuario, no necesita SEO y eso se debe a que el usuario ha iniciado sesión, por lo que el feed es realmente específico para los usuarios, sirve una gran cantidad de activos estáticos y es

6. Choosing Rendering Strategies and Security

Short description:

¿Qué elegirías para eso? ¿Elegirías el renderizado en el lado del servidor? ¿Elegirías el renderizado en el lado del servidor con una capa de caché? ¿Elegirías la generación de sitios estáticos y la regeneración estática incremental? ¿O elegirías la generación de sitios estáticos y el renderizado en el lado del cliente para mostrar contenido dinámico? En mi opinión, la respuesta correcta es la generación de sitios estáticos con renderizado en el lado del cliente. Eso se debe a que no necesitas el renderizado en el lado del servidor. Así que vamos con una página de publicación única. Sirve grandes activos estáticos, fotos, videos, y hay una sola página para cada publicación. La página de configuración de la cuenta necesita alta seguridad y es un buen caso para el renderizado en el lado del servidor sin ninguna caché.

básicamente una gran página común para cada usuario. ¿Qué elegirías para eso? ¿Elegirías el renderizado en el lado del servidor? ¿Elegirías el renderizado en el lado del servidor con una capa de caché? ¿Elegirías la generación de sitios estáticos y la regeneración estática incremental? ¿O elegirías la generación de sitios estáticos y el renderizado en el lado del cliente para mostrar contenido dinámico? Pensemos en ello.

Entonces, en mi opinión, la respuesta correcta es la generación de sitios estáticos con renderizado en el lado del cliente. Eso se debe a que no necesitas el renderizado en el lado del servidor. Sabemos que será diferente para cada usuario, pero la página es la misma. El encabezado será el mismo. El pie de página será el mismo. Solo cambia el contenido. Por lo tanto, el contenido se puede cargar de forma perezosa en el cliente. Además, si pensamos en una escala como Instagram, esto es demasiado grande para muchos de nosotros, pero realmente no quieres hacer el renderizado en el lado del servidor para tantas solicitudes. Se vuelve muy costoso. Así que vamos con una página de publicación única. Entonces vemos una bonita foto. Hacemos clic en el título y vemos la publicación completa con la descripción y los comentarios y lo que sea. Así que hay una gran cantidad de páginas. Necesitará una buena optimización para motores de búsqueda porque así es como ingresamos a Google con las publicaciones individuales, no con una página de inicio. Sirve grandes activos estáticos, fotos, videos, y hay una sola página para cada publicación individual. ¿Qué usarías? Entonces las respuestas son las mismas que la respuesta anterior, pero en mi opinión, este es un buen caso para el renderizado en el lado del servidor con caché. Permíteme explicarte por qué. Haremos el renderizado en el lado del servidor por primera vez y serviremos una respuesta en caché cada vez que un nuevo usuario solicite la misma publicación. Después, digamos, una hora, treinta minutos, un día, purgaremos la caché y la volveremos a renderizar, imitando cómo funciona la regeneración estática incremental. Si... bueno, más adelante veremos, con otro ejemplo, cuál podría ser una buena alternativa a eso. Pero por el momento, mantengamos nuestros pensamientos en el SSR y la caché. Vale, último caso. La página de configuración de la cuenta necesita alta seguridad. No necesita optimización para motores de búsqueda y está protegida por autenticación. Sabemos con certeza que esta no es la página más visitada de cada cuenta, ¿verdad? Ese podría ser un buen caso, en mi opinión, para el renderizado en el lado del servidor sin ninguna caché. No queremos caché, de lo contrario, el riesgo es que haga inicio de sesión y cuando otro usuario inicie sesión, verán mi cuenta. Eso no es lo que queremos, ¿sabes? Pero también tenemos cookies en el lado del servidor

7. Rendering Strategies for E-commerce

Short description:

Para un sitio web de comercio electrónico con una página de inicio que requiere un alto rendimiento, optimización para motores de búsqueda y actualizaciones ocasionales de contenido, se recomienda la generación de sitios estáticos con regeneración estática incremental. Este enfoque permite el renderizado estático de la página con un excelente rendimiento y valida la página después de un tiempo especificado. Para las páginas individuales de productos, la generación de sitios estáticos con renderizado en el lado del cliente es adecuada, ya que el contenido es relativamente estático y se puede controlar en el lado del cliente mediante llamadas a la API.

Las cookies en el lado del servidor, que son más seguras que las cookies en el lado del cliente. Por lo tanto, este es un buen caso para el renderizado en el lado del servidor y podemos permitírnoslo porque no hay muchas solicitudes específicas a esa página. Así que vamos con otro ejemplo. Digamos que queremos construir un sitio de comercio electrónico. Entonces, la página de inicio es realmente importante para cada sitio de comercio electrónico, ¿verdad? Necesitamos un alto rendimiento, una optimización impresionante para motores de búsqueda y el contenido cambia de vez en cuando. No muy frecuentemente, pero digamos un par de veces por semana, ¿de acuerdo? Entonces, ¿qué elegirías? Te daré un par de segundos. En mi opinión, es mejor optar por la generación de sitios estáticos y la regeneración estática incremental sin un tiempo de revalidación largo. De esta manera, básicamente renderizas la página de forma estática, el rendimiento será impresionante y revalidarás la página después de, no sé, un día, dos días, una semana. Realmente depende. Puedes elegir. Así que vamos con una página de producto individual. Digamos que en nuestro sitio de comercio electrónico tenemos 250 productos, necesitamos una optimización impresionante para SEO para cada producto, un rendimiento excelente, algunos datos dinámicos, por ejemplo, la cantidad de stock, no sé, por ejemplo, el tiempo de entrega, dependiendo de dónde vengas o a dónde enviar la mercancía, etc. ¿Qué elegirías? Yo elegiría la generación de sitios estáticos y el renderizado en el lado del cliente. Y eso se debe a que la página de producto no cambia mucho. De lo contrario, podríamos haber elegido la regeneración estática incremental, pero no cambia mucho. Y la cantidad de stock se puede controlar en el lado del cliente a través de llamadas a la API, por ejemplo. Y lo mismo se puede hacer con APIs externas para

8. Incremental Static Regeneration with Fallback

Short description:

Para plataformas de comercio electrónico o blogs grandes con mil millones de páginas, no es factible renderizar todas las páginas en tiempo de compilación. En su lugar, podemos utilizar la regeneración estática incremental con un fallback. Esto nos permite construir los artículos más populares en tiempo de compilación y posponer el renderizado del resto hasta el momento de la solicitud. Las cabeceras de caché y la revalidación mejoran el rendimiento.

Entrega a domicilio. Una cosa que mencionar, y quería mencionar esto anteriormente cuando hablaba de la red social, pero vale la pena mencionarlo ahora, es que si tenemos un e-commerce muy grande o una plataforma de blogs, por ejemplo, donde tenemos mil millones de páginas para renderizar, por supuesto que no podemos renderizar mil millones de páginas en tiempo de compilación. Tomaría una eternidad. Así que podríamos optar por la regeneración estática incremental con un fallback. Hay un valor de fallback en la configuración de la regeneración estática incremental, para que podamos decir, construiré, en tiempo de compilación, los cien artículos más populares en mi e-commerce, lo que sea, y pospondré la fase de renderizado para todos los demás artículos en el momento de la solicitud con la regeneración estática incremental. Así que básicamente generaré 100 artículos que son los que se buscan más y los otros se renderizarán en el momento de la solicitud y tendremos algunas cabeceras de caché agradables gracias a la regeneración estática incremental y la revalidación, por supuesto. Bueno, así que el último, la página de configuración de la cuenta, alta seguridad, no necesita optimización para motores de búsqueda y está protegida por autenticación. ¿Qué elegirías? Bueno, quería saber si estabas prestando atención, esto es lo mismo que la red social. Ya discutimos esto, así que déjame continuar porque estoy a punto de terminar mi tiempo. Así que lección aprendida número uno, el contenido es dinámico y depende del usuario en ese caso, podemos generar una página estática en tiempo de compilación y renderizar los datos dinámicos en el lado del cliente. Y eso se debe a que las partes dinámicas de nuestra aplicación no son significativas para la optimización de motores de búsqueda, así que no las necesitamos. Por lo tanto, es inútil para nosotros utilizar el renderizado en el lado del servidor en ese caso. Lección aprendida número dos, el contenido es estático y el SEO es importante, podemos generar la página en tiempo de compilación y adoptar la regeneración estática incremental cuando sea necesario. Lección número tres, el contenido es estático pero la página se crea dinámicamente. De acuerdo, si el contenido es estático pero la página se crea dinámicamente, por ejemplo, estamos en un blog, publico un nuevo artículo, no quiero reconstruir todo el sitio web, ya sabes, en ese caso podríamos utilizar el renderizado en el lado del servidor y poner el sitio web detrás de una caché o podríamos utilizar nuevamente la regeneración estática incremental con un fallback para que generemos en tiempo de compilación todos los artículos en una plataforma de blogs, por ejemplo, que tenemos en la base de datos y tan pronto como cree un nuevo artículo no necesito reconstruir todo el sitio web. Tan pronto como las solicitudes lleguen al sitio web, Next.js dirá, está bien, tengo el fallback configurado como verdadero, así que preguntaré al servidor si el artículo ahora existe. Si existe pero no lo he generado en tiempo de compilación, lo generaré ahora y lo pondré detrás de la capa de caché utilizando cabeceras de caché. En cualquier caso, quieres evitar el renderizado en el lado del servidor a toda costa y eso se debe a que es realmente costoso. Es realmente caro de gestionar y también muy costoso en cuanto a dinero porque tienes que gestionar una infraestructura, tienes que gestionar el mantenimiento de tus servidores y lo que sea. Así que es hora de usar Next.js por cómo ha evolucionado en lugar de por qué nació y Next.js es un marco increíble y nos permite decidir si tenemos que utilizar la generación de sitios estáticos, la regeneración estática incremental, el renderizado en el lado del servidor, el renderizado en el lado del cliente y lo que sea. Así que por eso sigo apostando por Next.js a pesar de que evito el renderizado en el lado del servidor a toda costa. Una vez más, esta charla se ha adaptado de un capítulo de Real World Next.js en caso de que estés interesado, no dudes en ponerte en contacto. Muchas gracias por estar aquí y seguir la charla. Te dejaré un par de contactos en caso de que quieras ponerte en contacto. Vivo en Twitter, así que si quieres ponerte en contacto, ese es el mejor lugar donde puedes encontrarme. Gracias de nuevo. Espero verte a todos en persona muy pronto. Gracias, ¡adiós!

Check out more articles and videos

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

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Top Content
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit 2023React Summit 2023
139 min
Create a Visually Editable Next.js Website Using React Bricks, With Blog and E-commerce
WorkshopFree
- React Bricks: why we built it, what it is and how it works- Create a free account- Create a new project with Next.js and Tailwind- Explore the directory structure- Anatomy of a Brick- Create a new Brick (Text-Image)- Add a title and description with RichText visual editing- Add an Image with visual editing- Add Sidebar controls to edit props (padding and image side)- Nesting Bricks using the Repeater component- Create an Image gallery brick- Publish on Netlify or Vercel- Page Types and Custom fields- Access Page meta values- Internationalization- How to reuse content across pages: Stories and Embeds- How to create an E-commerce with Products’ data from an external database and landing pages created visually in React Bricks- Advanced enterprise features: flexible permissions, locked structure, custom visual components