¿Cuáles son las desventajas del renderizado del lado del servidor (SSR)?

Las principales desventajas del SSR:

• Aumento de la carga en el servidor: Cada solicitud del cliente requiere renderizar completamente la página en el servidor, lo que consume más recursos (CPU, memoria) en comparación con servir archivos estáticos o SPA.
• Complejidad en el desarrollo: Es necesario tener en cuenta la isomorfía del código (trabajo en el servidor y en el cliente), gestionar el estado entre solicitudes, manejar datos asíncronos. La depuración puede ser más difícil.
• Tiempo de inactividad en caso de errores del servidor: Si el servidor principal que realiza el renderizado falla, el sitio puede volverse inaccesible, a diferencia de SPA, donde el cliente puede seguir trabajando con recursos en caché o páginas de fallback.
• Tiempo hasta la interactividad (TTI) más largo: Aunque el primer contenido aparece más rápido (FCP), el usuario no puede interactuar con la aplicación hasta que todo el JavaScript (hidración) se cargue y ejecute en el cliente. En SPA, la interactividad puede aparecer antes en partes ya cargadas de la página.
• Complejidad en el almacenamiento en caché: Es más difícil cachear HTML generado dinámicamente que recursos estáticos. Se requieren estrategias de caché más sofisticadas en el lado del servidor.
• Mayor tiempo de primer byte (TTFB): El servidor necesita tiempo para procesar la solicitud, obtener datos, renderizar HTML y enviar el primer byte de vuelta al cliente.
• Pueden surgir problemas con el código isomórfico: Algunas API del cliente (por ejemplo, window, document) no están disponibles en el servidor, lo que requiere escribir código condicional o usar bibliotecas especiales.

// Ejemplo de renderizado condicional en el servidor
if (typeof window === 'undefined') {
  // Código que solo se ejecuta en el servidor
  console.log('Renderizado en el servidor');
} else {
  // Código que solo se ejecuta en el cliente
  console.log('Renderizado en el cliente');
}