No querrás renderizar en el servidor tu aplicación Next.js

Rate this content
Bookmark

Next.js es un marco de trabajo fantástico; ofrece muchas características únicas, ayudándote a construir cualquier aplicación web sin esfuerzo. Pero cuando se trata de elegir la estrategia de renderizado correcta para tus páginas, puedes enfrentarte a un problema; ¿cómo debería renderizarlas? ¿Debería generarlas estáticamente en el momento de la construcción? ¿Debería renderizarlas en el servidor en tiempo de ejecución? Bueno, la respuesta es sorprendente. La renderización en el servidor rara vez es la mejor opción, y vamos a explorar por qué (¡y cómo resolver este problema!)

Michele Riva
Michele Riva
28 min
21 Jun, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

Next.js es un marco que permite la renderización en el lado del cliente y transiciones de página fáciles. La renderización en el 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 renderización correcta depende del escenario específico, y para los 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 el autor de Real-World Next JS. NearForm es una empresa de servicios profesionales especializada en Node.js, React, Next.js, TypeScript y en el mantenimiento de paquetes de código abierto. Ahora, vamos a sumergirnos en Next.js. Es un maravilloso marco de trabajo que permite la renderización en el lado del cliente, proporcionando una experiencia similar a la de una aplicación nativa con transiciones de página fáciles y carga perezosa 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 Fijo, Tu Próxima Aplicación JS. Antes de empezar, permítanme presentarme brevemente. Soy Michele. Trabajo como arquitecto de software senior en NearForm. Soy un experto desarrollador de Google y un MVP de Microsoft. También soy el autor de Real-World Next JS, que es un libro que, como puedes adivinar, habla sobre Next.js. Así que si después de la charla te gustaría charlar y hablar sobre Next.js, no dudes en ponerte en contacto. Estaré encantado de hablar contigo. Un par de palabras sobre NearForm. Somos una empresa de servicios profesionales, y estamos especializados 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ás buscando un trabajo en el que puedas trabajar desde casa y estás realmente comprometido con el código abierto, no dudes en ponerte en contacto. Estaré encantado de presentarte a la empresa. Pero no estamos aquí por eso, 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 empezó a ser algo, básicamente solo teníamos la renderización en el lado del cliente. Así que 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.

Así que básicamente, el problema con este enfoque, pero veremos muchos problemas más adelante, es que esto es lo que vemos cuando descargamos el paquete por primera vez. Así que mientras se está descargando, mientras se está ejecutando, vemos un spinner. Después de varios segundos, veremos la página completa lista para ser navegada. Así que este enfoque tiene algunos contras y algunos pros. Así que veamos por qué podría ser una buena o una mala elección. Así que en primer lugar, te hace sentir tu aplicación, como si fuera una aplicación nativa, y eso es porque 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 un refresco de página. Ya tienes todos los componentes que necesitas que se cargan de forma perezosa directamente en el navegador. Así que por ejemplo, estás en la página de inicio, haces clic para leer un artículo, todo el DOM se refresca, pero la página no. Así que el DOM React intercambiará el contenido con el nuevo, y ejecutará los componentes perezosos que aún no se han ejecutado durante la primera carga. Otra gran cosa sobre la renderización en el lado del cliente es que no necesitas un servidor. Y si lo necesitas porque ya tienes uno y quieres servir tu aplicación en el lado del cliente

2. Pros y Contras de la Renderización del Lado del Servidor en React

Short description:

Y no hay carga de trabajo en el servidor, lo cual es bastante bueno porque es realmente fácil de escalar. Pero si no tienes un servidor, eso sigue siendo bueno, puedes simplemente poner tus archivos, activos estáticos, en un CDN en S3 en AWS, por ejemplo, o usando 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. Aunque 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 de la página lento. La renderización del lado del servidor ofrece un enfoque diferente, proporcionando una aplicación más segura, compatibilidad para usuarios que no usan 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 mucho poder. Y no hay carga de trabajo en el servidor, lo cual es bastante bueno porque es realmente fácil de escalar. Pero si no tienes un servidor, eso sigue siendo bueno, puedes simplemente poner tus archivos, activos estáticos, en un CDN en S3 en AWS, por ejemplo, o usando 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. Aunque 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 importe. Por ejemplo, si te importa el mercado 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 son más populares en otros continentes, como Asia, por ejemplo, o África, que no leen páginas generadas por React. Así que 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. Así que la primera vez que descargas un paquete, simplemente tienes que esperar varios segundos para poder navegar por él. Por eso empezamos a ver la renderización del lado del servidor como una forma diferente de abordar la renderización de React específicamente. Con la renderización del lado del servidor, esto es lo que obtienes tan pronto como solicitas una página. Puede tardar un par de segundos, porque el servidor todavía necesita renderizar la aplicación en el lado del servidor, pero eventualmente te enviará la página completa lista para navegar.

Así que este enfoque también tiene algunos pros y contras. Veamos cuáles son. Un pro, la aplicación podría ser un poco más segura. Eso es porque 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 hombre en el medio, por ejemplo. Además, terminas teniendo sitios web más compatibles. Si no tienes JavaScript habilitado, todavía verás el primer renderizado de tu aplicación. La optimización de motores de búsqueda se mejora gracias a la renderización del lado del servidor, porque básicamente terminas teniendo un producto que es el mismo 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. Así, dependiendo del usuario que esté actualmente conectado, 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. Así, habrá una mayor carga de trabajo en el servidor,

3. Generación de Sitios Estáticos y Renderización Híbrida

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 renderización del lado del servidor. Sin embargo, tiene limitaciones como la ausencia de contenido dinámico en el lado del servidor y la necesidad de reconstruir y redistribuir toda la aplicación para los cambios. React ofrece renderización híbrida, permitiendo diferentes estrategias de renderización para diferentes páginas y partes de la aplicación. La renderización del lado del cliente requiere esperar a que se ejecute el paquete de JavaScript.

mayores costos de mantenimiento, porque tendrás que mantener un servidor. Y esto es costoso. Entonces, tienes que scale el servidor horizontalmente, por ejemplo, si quieres agregar más servidores para servir tu aplicación, porque necesitas scale, o necesitas agregar más potencia al servidor que ya tienes si quieres scale verticalmente. Eso depende, por supuesto, de cómo quieras scale tus aplicaciones. Entonces, hay una tercera opción que vamos a explorar, que se llama generación de sitios estáticos. Entonces, al igual que server side rendering, esto es lo que obtienes cuando solicitas una página generada por un sitio estático. Entonces, básicamente tan pronto como haces una solicitud, no necesitas renderizarla del 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 pros y contras, por supuesto, una ventaja es que es súper fácil de scale, y eso es porque de nuevo, no necesitas un servidor. Ya tienes activos estáticos, los pones 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 lleva a rendimientos excepcionales, 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á hecha, solo tienes que transferirla. Es realmente seguro porque no tienes un servidor, así que no hay forma de atacar al servidor directamente, así que eso es otra cosa a tener en consideración. Por supuesto, de nuevo, tiene algunas contras. Veámoslos. Entonces, no se permite contenido dinámico en el lado del servidor, porque no tienes un servidor, así 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 la renderización del 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 renderización del lado del cliente, lo siento con la generación de sitios estáticos, pero eventualmente tendrás que esperar a que el cliente entienda 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, tendrás que recargar y reconstruir y redistribuir 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 cosa agradable acerca de React es que no tienes que comprometerte, no tienes que elegir una estrategia de renderización para todo el sitio web. Pero puedes hacer eso de manera granular en la página, cuando básicamente renderizas la página individual. Esto se llama renderización híbrida. Entonces, básicamente podrías decir, está bien, la página de inicio de este sitio web será una página generada estáticamente. Si estás en un blog, la página de publicación puede ser generada dinámicamente con la renderización del 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 evaluar el contenido. Veamos en detalle a qué me refiero con esperar. Entonces, por ejemplo, esto es renderización del lado del cliente, ¿verdad? Hacemos una solicitud y tan pronto como hacemos la solicitud, el servidor o el CDN nos enviará una página vacía. Tan pronto como el paquete de JavaScript que contiene la aplicación React se ejecuta, comenzaremos a ver la aplicación montándose en el navegador. Entonces, como puedes ver, el servidor será realmente rápido en enviar una respuesta,

4. Regeneración Estática Incremental y Caché

Short description:

Con la renderización del 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 para 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 cambia nada, se servirá la versión en caché de la página.

pero tendremos que esperar. Entonces, a medida que pasa el tiempo, tenemos que esperar a que se cargue la página. Con la renderización del lado del servidor, es un poco diferente. Pedimos al servidor una página específica. Esperamos milisegundos, esperamos, o segundos dependiendo de cuán buenos seamos escribiendo React o cuán lentas sean las APIs 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 la combinación perfecta. Tan pronto como hacemos una solicitud, obtenemos una respuesta completa. Por eso me gusta hablar sobre la regeneración estática incremental porque básicamente resuelve un gran problema que tenemos con la generación de sitios estáticos. Entonces, no queremos reconstruir todo el sitio web cada vez que hacemos un cambio, porque esto es bueno, lo que estamos viendo ahora en la diapositiva, es bueno. Pero por ejemplo, si cambio de opinión y empiezo a amar a los setters irlandeses, por ejemplo, tendré que reconstruir todo el sitio web. Pero afortunadamente, con la regeneración estática incremental, eso no es el caso. Entonces, veamos cómo funciona. Básicamente, esta es nuestra página ahora. Esta es la página de inicio de mi sitio web, porque amo a los setters ingleses. Y digamos que tenemos un valor en nuestros 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. Entonces, publico la página. Después de un minuto, un usuario llega al sitio web y verá esa página. Después de tres minutos, otro usuario llega al sitio web y verá exactamente la misma página. Lo mismo, por supuesto, para el tercer usuario que mira nuestro sitio web después de cinco minutos. Recuerda, esto es perezoso. Entonces, si ningún usuario volverá a ver la página a partir de ahora, Next.js no recargará la aplicación en sí. 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. Entonces, eso es básicamente lo que está sucediendo. Regeneramos la página y el próximo usuario después de cinco minutos verá una página totalmente nueva con un nuevo color de fondo 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 de nuevo, a partir de ahora después de cinco minutos si otro usuario llega al sitio web tendremos que revalidar la página. Entonces, básicamente si no cambia nada veremos renderizar la página del lado del servidor. Pero pondremos algunos encabezados de caché para que sea posible que nuestra caché sirva una versión en caché de la página. Si no cambia nada, seguiremos viendo la misma página.

5. Evitando la Renderización del Lado del Servidor y Jugando Inteligente

Short description:

La renderización del lado del servidor de React no es eficiente todavía. JSX requiere mucho esfuerzo del lado del servidor, lo que ralentiza el servidor y requiere escalado. Pasar a serverless resuelve el problema de escalado, pero tiene un costo. Por ejemplo, el uso de Google Cloud Functions puede costar miles de dólares al mes. Compute Engine es más barato pero todavía tiene problemas de renderización del lado del servidor. Para superar esto, es importante jugar inteligente y considerar el escenario específico.

Bueno, pero dicho esto, ¿por qué querría evitar la renderización del lado del servidor? Así que es mi opinión que la renderización del lado del servidor de React no es realmente eficiente todavía. Eso no es culpa de Next.js. Esto 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 renderización del lado del servidor. Así que cada solicitud individual requiere mucho esfuerzo del lado del servidor lo que ralentiza el servidor, por lo que necesitas scale it, por lo que necesitas añadir más potencia de cálculo, más servidores para mantenerse al día con la creciente demanda de las páginas de tu aplicación. Así que podría ser fácil para un arquitecto en un cierto punto decir, sí, ve a serverless. Ya sabes que no tienes ese problema si te vas a serverless. Básicamente despliegas tu aplicación Next.js en AWS, Lambda, Google Cloud Functions, Azure Functions, lo que sea, y no necesitas scale. Eso es correcto pero ¿a qué costo? No es barato. Así que veamos un pequeño ejemplo en Google Cloud Platform. Digamos que este es el precio de Google Cloud Functions. Así que digamos que para los primeros dos millones de invocaciones por mes no pagamos nada. Más allá de dos millones pagamos 40 centavos cada millón de invocaciones. Suena barato ¿verdad? Bueno, veremos más adelante cuánto costará. Como puedes ver también pagas tiempo de computación cada 100 milisegundos. No tengo idea de cómo pronunciar esos números pequeños así que perdóname. Redes. También pagas por las redes. Así que el primer gigabyte de tráfico de transferencia es gratis luego pagas 12 centavos por gigabyte. Suena barato ¿verdad? Así que digamos que tenemos una aplicación que maneja 100 solicitudes de renderización del lado del servidor concurrent por segundo lo que lleva 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 un gran número de solicitudes verdad? El tiempo de ejecución promedio, digamos que es 300 milisegundos. Podemos usar la opción de RAM más barata que es 128 megabytes y necesitaremos alrededor de 100 kilobytes de ancho de banda por ejecución y está bien y necesitaremos más pero digamos para mantenerlo simple 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 se scale por supuesto se scale pero si obtienes más solicitudes el precio se hará más y más alto así que no es realmente sostenible para aplicaciones a gran escala. Si vuelves por ejemplo a Compute Engine con dos CPUs virtuales ocho gigabytes de rams pagarás como cincuenta y dos dólares al mes que es mucho más barato pero todavía tendrás el problema de la renderización del lado del servidor porque tendrás que scale it así que eventualmente querrás volver a serverless pero costará mucho así que querrás volver de nuevo a Compute Engine por ejemplo pero no scale o se volverá realmente costoso. Entonces, ¿cómo salimos de esa mala situación? Así que mi sugerencia sería jugar inteligente dependiendo del escenario. Así que empecemos con un ejemplo escenario. Digamos que queremos construir una aplicación de red social como Instagram o lo que sea así que quiero jugar 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 hemos discutido esto veamos si estabas prestando atención. Así que digamos que tenemos que construir una característica de página de feed para nuestra aplicación por ejemplo en Instagram cuando desplazas la página de feed la página de inicio de Instagram así que el contenido es realmente dinámico y es personalizado para cada usuario no necesita SEO y eso es porque el usuario está conectado así que el feed es realmente específico para los usuarios sirve un montón de activos estáticos y es

6. Elección de Estrategias de Renderización y Seguridad

Short description:

¿Qué elegirías para eso? ¿Elegirías la renderización del lado del servidor? ¿Elegirías la renderización del 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 la renderización del lado del cliente para mostrar contenido dinámico? En mi opinión, la respuesta correcta es la generación de sitios estáticos con la renderización del lado del cliente. Eso es porque no necesitas la renderización del 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 la renderización del lado del servidor sin ninguna caché.

básicamente una gran página común para cada usuario. ¿Qué elegirías para eso? ¿Elegirías la renderización del lado del servidor? ¿Elegirías la renderización del 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 la renderización del lado del cliente para mostrar contenido dinámico? Pensemos en ello.

Así que en mi opinión, la respuesta correcta es la generación de sitios estáticos con la renderización del lado del cliente. Eso es porque no necesitas la renderización del 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. Sólo cambia el contenido. Así que el contenido puede ser cargado de forma perezosa en el cliente. Además, si piensas en una scale de Instagram, esto es demasiado grande para muchos de nosotros, pero realmente no quieres hacer la renderización del lado del servidor de tantas solicitudes. Se está volviendo realmente costoso. Así que vamos con una página de publicación única. Así que 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 de motores de búsqueda optimization porque así es como llegamos 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 única. ¿Qué usarías? Así que las respuestas son las mismas que la respuesta anterior pero en mi opinión este es un buen caso para la renderización del lado del servidor con caché. Déjame explicarte por qué. Estaremos haciendo la renderización del lado del servidor por primera vez y estaremos sirviendo una respuesta de caché cada vez que un nuevo usuario pida la misma publicación. Después, digamos, una hora, treinta minutos, un día, nosotros purgaremos la caché y la volveremos a renderizar, imitando cómo funciona la regeneración estática incremental. Si... está bien, veremos más adelante, con otro ejemplo, cuál podría ser una buena alternativa a eso. Pero por el momento, mantengamos nuestros pensamientos en SSR y caché. Vale, la última. La página de configuración de la cuenta necesita alta security. No necesita optimización de motores de búsqueda optimization y está protegida bajo authentication. Sabemos con seguridad que esta no es la página más visitada de cada cuenta, ¿verdad? Así que podría ser un buen caso, en mi opinión, para la renderización del lado del servidor sin ninguna caché. No queremos caché, de lo contrario el riesgo es que yo haga login y cuando otro usuario haga login verán mi cuenta. Esto no es lo que queremos, ya sabes. Pero también tenemos cookies del lado del servidor

7. Estrategias de Renderización para E-commerce

Short description:

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

que son más seguros que las cookies del lado del cliente. Así que ese es un buen caso para la renderización del lado del servidor y podemos permitírnoslo porque no hay muchas solicitudes a esa página en particular. Así que vamos con otro ejemplo. Digamos que queremos construir un e-commerce. Entonces, la página de inicio, es realmente importante para cada e-commerce, ¿verdad? Necesitamos altos rendimientos, una increíble búsqueda de optimización de motores optimization, y el contenido cambia de vez en cuando. No muy frecuentemente, pero digamos un par de veces por semana, ¿vale? ¿Qué elegirías? Te daré un par de segundos. Mi opinión es optar por la generación de sitios estáticos y la regeneración estática incremental sin un largo tiempo de revalidación. Así que básicamente renderizas estáticamente la página, el rendimiento será increíble, y revalidarás la página después, no sé, un día, dos días, una semana. Realmente depende. Tú puedes elegir. Así que vamos con una página de producto individual. Digamos que en nuestro e-commerce, tenemos 250 productos, necesitamos un increíble SEO para cada producto, necesitamos un increíble SEO, grandes rendimientos, algunos datos dinámicos data, por ejemplo, cantidad en stock, no sé, por ejemplo, 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 la renderización del lado del cliente. Y eso es porque la página del producto realmente no cambia mucho. De lo contrario, podríamos haber elegido la regeneración estática incremental, pero realmente no cambia mucho. Y la cantidad en stock puede ser controlada 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. Regeneración Estática Incremental con Fallback

Short description:

Para grandes plataformas de e-commerce o blogs con mil millones de páginas, no es factible renderizar todas las páginas en tiempo de construcción. En su lugar, podemos usar la regeneración estática incremental con un fallback. Esto nos permite construir las publicaciones más populares en tiempo de construcción y diferir la renderización del resto al tiempo de solicitud. Las cabeceras de caché y la revalidación mejoran el rendimiento.

entrega. Una cosa a mencionar, y quería mencionar esto anteriormente cuando hablaba sobre la red social, pero vale la pena mencionarlo ahora, es que si tenemos un muy grande e-commerce o una plataforma de blogs, por ejemplo, donde tenemos mil millones de páginas para ser renderizadas, por supuesto no podemos renderizar mil millones de páginas en tiempo de construcción. Tomaría para siempre. Así que podríamos optar por ir con la regeneración estática incremental con un fallback. Hay un valor de fallback en la configuración de regeneración estática incremental, de modo que podemos decir, construiré, en tiempo de construcción, las cien publicaciones o artículos más populares en mi e-commerce, lo que sea, y diferiré la fase de renderización para todas las demás publicaciones o artículos en tiempo de solicitud con regeneración estática incremental. Así que básicamente generaré 100 publicaciones que son las que se buscan más y las demás serán renderizadas en tiempo de solicitud y tendremos algunas agradables cabeceras de caché gracias a la regeneración estática incremental y la revalidación por supuesto. Bueno, la última, página de configuración de cuenta, alta seguridad, no necesita optimización de motores de búsqueda optimization y está protegida bajo authentication. ¿Qué elegirías? Bueno, quería saber si estabas prestando atención esto es lo mismo que el de la red social. Ya discutimos esto así que déjame seguir adelante 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 construcción y renderizar los datos dinámicos data en el lado del cliente. Y eso es porque las partes dinámicas de nuestra aplicación no son significativas para la optimización de motores de búsqueda optimization, por lo que no las necesitamos. Así que es inútil para nosotros usar la renderización del lado del servidor en ese caso. Lección aprendida número dos, el contenido es estático y SEO es importante, podemos generar la página en tiempo de construcció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. Bueno, 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 usar la renderización del lado del servidor y poner la web detrás de un caché o podríamos usar de nuevo, la regeneración estática incremental con un fallback de modo que generamos en tiempo de construcción todos los artículos en una plataforma de blogs, por ejemplo, que tenemos en la database y tan pronto como yo cree un nuevo artículo no necesito reconstruir todo el sitio web. Tan pronto como las solicitudes lleguen a el sitio web NetZs dirá bien tengo el fallback configurado a verdadero así que preguntaré al servidor si el artículo ahora existe. Si existe pero no lo he generado en tiempo de construcción lo generaré ahora y lo pondré detrás, detrás de la capa de caché usando cabeceras de caché. En cualquier caso, quieres evitar la renderización del lado del servidor a toda costa y eso es porque es realmente costoso. Es realmente caro de gestionar y también realmente costoso en términos de 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 para cómo evolucionó en lugar de por qué nació y Next.js es un increíble framework y nos permite decidir si tenemos que usar generación de sitios estáticos, regeneración estática incremental, server side rendering, renderización del lado del cliente y lo que sea. Así que por eso sigo apostando por Next.js aunque evito la renderización del lado del servidor a toda costa. Así que de nuevo, esta charla ha sido adaptada 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 ahí 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 veros a todos en persona 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

A Guide to React Rendering Behavior
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
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
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.
Routing in React 18 and Beyond
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 Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
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
The Future of Performance Tooling
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.
Optimizing HTML5 Games: 10 Years of Learnings
JS GameDev Summit 2022JS GameDev Summit 2022
33 min
Optimizing HTML5 Games: 10 Years of Learnings
Top Content
The open source PlayCanvas game engine is built specifically for the browser, incorporating 10 years of learnings about optimization. In this talk, you will discover the secret sauce that enables PlayCanvas to generate games with lightning fast load times and rock solid frame rates.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
Ivan Akulov
Ivan Akulov
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 🤐)
Building WebApps That Light Up the Internet with QwikCity
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Miško Hevery
Miško Hevery
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.
Build a Headless WordPress App with Next.js and WPGraphQL
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
WorkshopFree
Kellen Mace
Kellen Mace
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.
Next.js 13: Data Fetching Strategies
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
Top Content
WorkshopFree
Alice De Mauro
Alice De Mauro
- 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 Performance Debugging
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan Akulov
Ivan Akulov
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 🤐)
Create a Visually Editable Next.js Website Using React Bricks, With Blog and E-commerce
React Summit 2023React Summit 2023
139 min
Create a Visually Editable Next.js Website Using React Bricks, With Blog and E-commerce
WorkshopFree
Matteo Frana
Matteo Frana
- 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