Por qué SSR es mejor que SSG

Jun 30, 2024

Por qué SSR es suficiente por sí solo

SSR (renderizado del lado del servidor) se refiere a renderizar páginas bajo demanda en tiempo de ejecución en el servidor, y luego enviarlas al frontend. SSG (generación de sitios estáticos) se refiere a precompilar archivos HTML y otros archivos estáticos, y enviarlos directamente al frontend cuando los usuarios los solicitan.

Con estas definiciones claras, es fácil entender que SSR puede incrustar lógica dinámica pero requiere un servidor en constante ejecución, mientras que SSG es más adecuado para contenido estático que puede colocarse en un CDN. El conocido framework NextJS soporta tanto SSR como SSG. Sin embargo, el más nuevo framework Remix ha abandonado completamente SSG, creyendo que hay suficientes beneficios en este enfoque. Según mi experiencia, con el soporte de CDN modernos, este enfoque tiene sentido.

CDNs modernos como Cloudflare y Vercel soportan entornos serverless, haciendo que el despliegue de aplicaciones NodeJS sea casi tan conveniente como el despliegue de archivos estáticos.
La principal ventaja de SSG es desplegar archivos estáticos directamente en CDNs para ahorrar recursos del servidor. Sin embargo, SSR también puede cachear fácilmente contenido en CDNs configurando los encabezados Cache-Control apropiados. Esto significa que el servidor SSR solo se ejecuta en la primera solicitud, haciéndolo casi indistinguible de los archivos estáticos.
No es necesario recompilar y redesplegar cada vez que se modifica contenido estático.
Una vez que se abandona el enfoque de NextJS de distinguir entre SSG y SSR, la carga mental se reduce significativamente. La configuración de caché depende completamente de estándares HTML como Cache-Control, sin necesidad de aprender un conjunto adicional de interfaces. La depuración de problemas de caché también se vuelve mucho más fácil - cuando el navegador cachea una solicitud que no debería cachear, solo necesitas revisar tu configuración de Response.

Un ejemplo

De hecho, el sitio web oficial de Remix es un excelente ejemplo. Su documentación se genera usando SSR. Mucha gente podría pensar que, dado que la documentación es solo texto estático, ¿no sería SSG lo mejor? El equipo de Remix explica su razonamiento.

Su documentación está almacenada en el repositorio de código fuente de Remix, no escrita directamente en el sitio web oficial. Este enfoque de mantener la documentación con el código fuente tiene varios beneficios:

Más referencial al leer código
Más fácil modificar la documentación al cambiar el código
Git rastrea automáticamente los cambios en la documentación, vinculándolos a las versiones del código fuente

El servidor del sitio web oficial lee desde el repositorio de código fuente de Remix y genera páginas de documentación a través de SSR. Este enfoque tiene varios beneficios:

No es necesario recompilar y redesplegar todo el sitio web cada vez que se modifica la documentación
Se puede acceder directamente a la documentación para cualquier versión de Remix desde el repositorio de código fuente, incluso la documentación más reciente de la rama dev. Esto permite que el sitio web oficial muestre documentación correspondiente a cualquier versión de Remix.

Como la documentación no son datos en tiempo real, han implementado algunas optimizaciones de caché:

Usando lru-cache para cachear resultados de documentación. La caché está en el lado del servidor, por lo que todos los clientes se benefician.
- Timeout establecido en 5 minutos
Configurando Cache-Control a stale-while-revalidate. Esto permite el cacheo en CDN:
```
return json(
  { doc },
  {
    headers: {
      "Cache-Control": "max-age=300, stale-while-revalidate=604800",
    },
  }
);
```
Esto significa que cuando se modifica la documentación, el sitio web oficial mostrará los cambios con un retraso máximo de 5 minutos (max-age=300).