¿Qué es el server-side rendering y cómo afecta el rendimiento web?
El Server-Side Rendering (SSR) es un proceso en el que el servidor genera todas las páginas web para cada solicitud del usuario. Cada vez que un usuario se conecta, el servidor procesa la solicitud y obtiene la información de una API. Esto significa que por cada nueva conexión, se realiza un llamado a las API que estamos utilizando. Si dos usuarios se conectan, se hacen dos solicitudes; si son cien conexiones, se realizan cien solicitudes. Este modelo plantea un desafío potencial de escalabilidad y eficiencia en proyectos donde la información no cambia tan frecuentemente, como una lista de animes más populares.
¿Cuándo utilizar static site generation?
El Static Site Generation (SSG) se presenta como una alternativa eficiente al SSR cuando la información de un sitio no cambia frecuentemente. En lugar de regenerar las páginas con cada solicitud, el SSG procesa todo una sola vez durante la etapa de construcción del proyecto, almacenando el contenido en el servidor para luego distribuir la misma respuesta a todas las conexiones. Esto reduce la carga del servidor y las solicitudes a la API.
¿Cómo implementar static site generation en tu proyecto?
Pasar de SSR a SSG en un proyecto implica ciertos cambios clave en la estructura y el flujo del proceso. A continuación, algunos pasos básicos para implementar SSG:
Identificar el contenido estático: Determina qué partes de tu sitio no requieren ser actualizadas constantemente.
Generar el contenido durante la construcción: Utiliza herramientas para obtener el contenido API durante la build del proyecto y almacénalo estáticamente.
Configurar el servidor para contenidos estáticos: Modifica el servidor para que sirva la versión pre-renderizada del HTML, CSS y JavaScript.
Refinando el SSG con herramientas y librerías
En el ejemplo del curso, se hace uso de la librería HyperScript para ayudar en la generación del HTML estático. Además, el script export.js facilita la creación del archivo index.html con todos los componentes renderizados. El uso de JavaScript junto con las APIs nos permite estructurar nuestro sitio bajo el popular enfoque JAMStack, que privilegia los rendimientos y la escala.
// Ejemplo básico de cómo usar JavaScript para generar HTML estático// Se reutiliza la función render previamente utilizada en SSRconst render =require('./render');constcreateStaticSite=()=>{const htmlContent =render();// Obtener el contenido completo con rendersaveToFile('index.html', htmlContent);// Guardar el HTML generado en un archivo};constsaveToFile=(filename, content)=>{// Función para escribir el contenido en un archivo fs.writeFileSync(filename, content);};createStaticSite();// Ejecutar la creación del sitio estático
Beneficios del static site generation
El SSG trae consigo numerosos beneficios, especialmente en términos de rendimiento:
Eficiencia en cargas: Las páginas estáticas cargan más rápido ya que no dependen de cálculos dinámicos con cada solicitud del usuario.
Apoyo de servidores universales: Los sitios generados estáticamente pueden subirse a cualquier servidor convencional, ya que solo necesitan soportar HTML, CSS y JavaScript.
Seguridad mejorada: Menos solicitudes al servidor significa menos exposición a vulnerabilidades directas o ataques potenciales.
Estos beneficios facilitan que los desarrolladores creen sitios altamente optimizados, aunque no todas las aplicaciones son adecuadas para el SSG. Entornos como dashboards de datos en tiempo real o analíticas dependen de información dinámica actualizada constantemente y no son candidatos ideales para prerenderización.
Desafíos finales y consideración de optimización
Aunque el static site generation puede llevar una página al máximo nivel de optimización, siempre debe evaluarse la naturaleza y las necesidades del proyecto. Los desarrolladores deben analizar qué partes del sitio pueden beneficiarse de esta metodología y cuáles requieren permanecer dinámicas. Además, en futuras clases, se estudiarán aspectos como la implementación de cachés y redes de entrega de contenido (CDN) para mejorar aún más la eficiencia y rendimiento del sitio.
J -> Javascript = interacción del sitio web
A -> Api's = interfaz de aplicaciones para consultar información que ya es abstraida y ha realizado un proceso en un servidor
M -> Markup = plantilla construida en tiempo de compilación
Al final se comenta que la forma como se implementa SSG en esta clase no es la mejor para usar en producción,
¿por qué esto es así? Creo que me quedó esa duda
Ensenia al servido que en el tiempo de construccion del proyecto, traiga todo el contenido de la API's de una vez, lo guarda y esa unica respuesta generada se la envia a todas las conexiones
Lo podemos subir a cualquier servidor en Internet
No aplica para metricas y datos que se necesitan visualizar en tiempo real
Segun veo pre-renderizas el contenido, y esta bien. Pero cuando payload de la respuesta de la API cambia, como haces para actualizar el contenido para mostrar el nuevo contenido?
esta forma de hacer las cosas , es cuando miramos que el contenido no va a cambiar constantemente , de lo contrario , no estaria bien aplicarlo , pero cada vez que se le quiera enviar una nueva actualizacion al cliente , pues se hace el proceso de compilación de nuevo para generar los nuevos datos y el servidor nuevamente los tendra y eso enviara , y asi sucesivamente , pero por eso hay que saber cuando es conveniente y cuando no.
Sí, y esa es una de sus mayores ventajas operativas. Al final del proceso de generación estática, lo único que obtienes es una carpeta llena de archivos HTML, CSS y JavaScript puros.
No necesitas configurar entornos complejos de Node.js, contenedores de Docker o servidores de bases de datos para mantener la página en línea. Cualquier servidor web básico, desde un simple Apache o Nginx, hasta servicios de hosting gratuitos y plataformas modernas enfocadas en el despliegue estático, pueden servir estos archivos sin problema. Esto reduce drásticamente los costos de infraestructura y minimiza las vulnerabilidades de seguridad, ya que no hay un servidor de aplicaciones activo que los atacantes puedan vulnerar. Simplemente subes tus archivos y tu sitio estará disponible a nivel mundial.
El término JAMstack significa JavaScript, APIs y Markup. Encaja perfectamente porque es la arquitectura exacta que aplicas al generar sitios estáticos.
En lugar de depender de un servidor tradicional que construye la página en cada petición, separas las responsabilidades. Utilizas APIs para gestionar los datos (como un CMS headless o servicios de terceros), usas JavaScript durante el proceso de construcción para consumir esas APIs, y finalmente generas el Markup (HTML preconstruido). El resultado es un ecosistema donde el frontend está completamente desacoplado del backend. Esto te permite escalar de forma masiva y económica, ya que solo estás sirviendo archivos estáticos que pueden distribuirse globalmente a través de una red de entrega de contenido (CDN), logrando velocidades de carga inigualables.