#UnderTheHood páginas: pre rendering de páginas

Viendo el código fuente se sabe que se hace un pre-render, en aplicaciones construidas con create-react-app solo se puede ver una etiqueta en el body:

<div ="root></div>

(Firefox) Cmd + U, se abre la previsualización del código fuente y se puede ver que Nextjs renderiza todo nuestro contenido.

En realidad lo que esta haciendo Next en este caso no es SSR, sino Static rendering, la diferencia es que en SSR cada vez que llegue una nueva consulta Next va a ejecutar el codigo y va a devolver la vista renderizada en html, en cambio en Static rendering Next solo va a ejecutar el codigo UNA sola vez (eso sucede en el momento en que hacemos deploy) y a partir de aqui cada vez que llegue una consulta nueva siempre va a devolver la misma vista html que renderizo la primera vez, esto es mucho mas eficiente ya que el codigo solo se renderiza en el servidor una sola vez y al generar los archivos estaticos estos pueden ser alojados y distribuidos en un CDN lo que los hacen increiblemente rapidos

SSR aunque se desactive el JS desde el browser, sigue funcionando.

Una forma fácil de chequear si NextJS está haciendo SSR es yendo a DevTools -> Config -> Debugger(se encuentra hasta abajo de todo) -> habilitar Disable Javascript.
Si sigue renderizando el html es porque se encuentra renderizando desde el servidor. Pueden probarlo mejor en la route /product/loQueSea y se darán cuenta que el HTML lo renderiza pero el llamado al ID no

El SSR es el método en el cual el Servidor manda al cliente (navegador web) el código html listo para que se muestre en pantalla. Esto lo que significa es que el cliente no tiene que gastar computo y tiempo haciendo el proceso de renderizado, si no que ya viene hecho.

Ventajas

• Permite que la pagina muestre contenido de una manera mucho mas rápida
• Es bueno para el SEO

Desventajas

• Si el usuario quiere interacción inmediata, la pagina no lo va a poder procesar, ya que incluso aunque el html venga listo para mostrarse, aun así, el cliente tiene que preparar todo para que la pagina sea interactiva, lo cual también lleva sus milisegundos (dependiendo del dispositivo e internet)
• El proceso de descargar el js se hace cada vez que se recarga la pagina

.
En conclusión, el SSR es muy útil, ya que nos ayuda a que el usuario no abandone la pagina tan pronto e incluso aunque el SSR tenga sus desventajas, las ventajas son mayores.
.
Les dejo este articulo del creador de Electron y empleado en Walmart Labs en donde habla de como Walmart y Electron utilizan el SSR y como este ha ayudado a mejorar el engagement del e-commerce: https://medium.com/walmartglobaltech/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8

El SSR envia un html y css prerenderizado hacia el cliente, es decir, ejecuta el JavaScript que incrusta todos estos elementos en el DOM en el servidor y deja las tareas secundarias (como los eventos, fetch, etc) para que se ejecute en el lado del cliente. Por lo que si agregamos un botón a la página About que ejecute un Alert:

import React from 'react';

const About = () => {
  const handleClick = () => {
    alert('clicked!');
  }

  return (
    <>
      Esta es la pagina de about
      <button onClick={handleClick}>Click me!</button>
    </>
  );
}

export default About;

Y deshabilitamos el JavaScript en el navegador, el botón no realizará acción alguna, pero sí se renderizará.

de echo esta haciendo static site generation no server side, cuando compilasel proyecto lo marca como static, server side es otra configuracion

Este fue mi primer acercamiento a SSR, pero me ayudó mucho a ver y entender cómo trabaja la carga de archivos en el navegador 😄

Next.js Pre-Rendering

El pre-renderizado es una característica importante de Next.js que mejora el rendimiento y permite la optimización para motores de búsqueda (SEO) mediante la generación de páginas HTML por adelantado.

<br>

El pre-renderizado se refiere al proceso de generar archivos HTML estáticos para las páginas de tu aplicación antes de que sean servidas al cliente. Hay dos tipos de pre-renderizado en Next.js: pre-renderizado estático y renderizado del lado del servidor (SSR).

<br>

• Prerenderizado estático (Generación estática o “SSG”): El pre-renderizado estático genera páginas HTML en tiempo de compilación, lo que significa que las páginas se generan una vez durante el proceso de compilación y luego se sirven como archivos estáticos a los clientes. Este enfoque es adecuado para páginas que no requieren actualizaciones frecuentes de datos y que pueden almacenarse en caché para solicitudes posteriores más rápidas. Cuando un usuario solicita una página pre-renderizada, el servidor sirve el HTML estático directamente, sin ejecutar ningún código JavaScript en el lado del cliente.
  <br>
  El pre-renderizado estático es beneficioso para el rendimiento porque permite servir el contenido desde una CDN (Content Delivery Network) en lugar de generarlo en cada petición. Proporciona cargas de página iniciales rápidas y un buen SEO, ya que los motores de búsqueda pueden indexar fácilmente las páginas HTML estáticas. Next.js proporciona un método de obtención de datos, getStaticProps, que permite obtener datos en tiempo de compilación e incluirlos en la página pre-renderizada.

<br>

• Renderizado del lado del servidor (SSR): El renderizado del lado del servidor genera páginas HTML en cada solicitud. Cuando un usuario visita una página, el servidor ejecuta el código JavaScript necesario para renderizar la página en el servidor y envía el HTML generado al cliente. Este enfoque es útil para páginas que requieren datos en tiempo real o dinámicos que pueden cambiar con cada petición.
  <br>
  SSR es útil cuando se tienen páginas con contenido que se actualiza con frecuencia o depende de datos específicos del usuario. Next.js proporciona un método de obtención de datos, getServerSideProps, que permite obtener datos en cada petición e incluirlos en la página renderizada en el servidor.
  <br>
  Tanto el pre-renderizado estático como el renderizado del lado del servidor tienen sus casos de uso, y Next.js te permite elegir el método de renderizado apropiado para cada página en función de tus necesidades. Por defecto, Next.js utiliza el pre-renderizado estático (SSG) para las páginas, pero puedes optar por el renderizado del lado del servidor (SSR) cuando sea necesario.
  <br>
  Cabe mencionar que Next.js también admite el renderizado del lado del cliente (CSR) para componentes o partes de tu aplicación que requieran interactividad o actualizaciones en tiempo real.

Hay varias maneras de revisar si el contenido viene prerenderizado del servidor. Podriamos hacer un curl a la dirección del servidor y luego examinar si el contenido que se muestra ya viene completo o si hay llamadas de javascript que completan el código html faltante.

curl localhost:3000 > archivo.html

Lo que me lleva a la segunda manera que es abriendo devtools y mirando la pestaña de network para ver examinar las peticiones web que se hacen posteriores al archivo principal.

Pre-rendering -> Next.js crea el HTML por cada pagina lo cual resulta mejor para el SEO. Adicionalmente hay que saber que existen dos métodos de Pre-rendering
1. Static Generation (Recomendado por Next.js) -> El HTML es generado en build time y es reutilizable para cada petición
2. Server-side Rendering: El HTML es generado en cada petición

El SSR (server side rendering), todo viene prerenderizado desde el servidor y permite que la web sea indexable por los motores de busqueda (google).

El pre rendering es impresionante, que genial.

Pre-renderizado
Next.js procesa previamente cada página. Esto significa que Next.js genera HTML para cada página por adelantado, en lugar de que JavaScript del lado del cliente lo haga todo. La renderización previa puede resultar en un mejor rendimiento y SEO.

Cada HTML generado está asociado con el código JavaScript mínimo necesario para esa página. Cuando el navegador carga una página, su código JavaScript se ejecuta y hace que la página sea totalmente interactiva. (Este proceso se llama hidratación ).

• Generación estática (recomendada): el HTML se genera en el momento de la compilación y se reutilizará en cada solicitud.

• Representación del lado del servidor : el HTML se genera en cada solicitud .

https://nextjs.org/docs/basic-features/pages

que genial este curso!

#UnderTheHood páginas: pre rendering de páginas

Next JS hace Server Side Rendering.

Nos damos cuenta de esto haciendo click derecho y Ver código fuente de la página, en donde tenemos esto:

<div id="__next">
  <div>
    <h1>Hola Platzi desde Next JS</h1>
    <p>Esto es Hot Realoading y Fast Refresh</p>
  </div>
</div>

Esto nos ayuda con el SEO.

Genial muy util para las apps muy grandes

curl http://localhost:3000 > tesSSR.html 

Revisa el archivo resultante, si esta hidratado entonces esta haciendo server side render.

Mal, esas páginas todas apiladas.

Para verficar si tiene SSR, simplemente agrego la palabra window para cargar algo desde el navegador, lo cual me lanza este maravillo mensaje de error:

Habemus SSR en next por defecto que maravillosooo

A falta de botón de like en los videos, lo dejo en un comentario

porque sale en la consola los logs, por eso es server side rendering

Comparto la documentacion respecto a este tema
https://nextjs.org/docs/basic-features/pages#pre-rendering

Hola, una consulta. En estos ejemplos, en realidad se hizo SSR?? Me surge la duda, porque en la terminal todos los pages tienen el símbolo del círculo vacío que es de STATIC.

Desabilitar JS en el browser heheh

Para ver el render del servidor click derecho, Ver código fuente

Next es un amor y super amigable

en la carpeta .next se puede ver la carpeta server y static, tambien los manifiestos.json

Hasta este punto Next.JS y este profe me estan pareciendo un 10/10. Continuando con el curso