Quali sono gli svantaggi del rendering lato server (SSR)?

Principali svantaggi del SSR:

• Aumento del carico sul server: Ogni richiesta del client richiede il rendering completo della pagina sul server, che consuma più risorse (CPU, memoria) rispetto alla consegna di file statici o SPA.
• Complessità nello sviluppo: È necessario considerare l'isomorfismo del codice (lavoro sul server e sul client), la gestione dello stato tra le richieste, la gestione di dati asincroni. Il debug può essere più difficile.
• Tempo di inattività in caso di errori del server: Se il server principale di rendering si guasta, il sito può diventare inaccessibile, a differenza di SPA, dove il client può continuare a lavorare con risorse in cache o pagine di fallback.
• Tempo fino all'interattività (TTI) più lungo: Sebbene il primo contenuto appaia più rapidamente (FCP), l'utente non può interagire con l'applicazione finché tutto il JavaScript (idratazione) non viene caricato ed eseguito sul client. In SPA, l'interattività può comparire prima su parti già caricate della pagina.
• Complessità nella cache: È più difficile cacheare HTML generato dinamicamente rispetto a risorse statiche. Sono necessarie strategie di cache più sofisticate lato server.
• Tempo di primo byte (TTFB) più alto: Il server necessita di tempo per elaborare la richiesta, ottenere dati, rendere HTML e inviare il primo byte al client.
• Possono sorgere problemi con il codice isomorfico: Alcune API client (ad esempio, window, document) non sono disponibili sul server, il che richiede di scrivere codice condizionale o usare librerie speciali.

// Esempio di rendering condizionale sul server
if (typeof window === 'undefined') {
  // Codice che viene eseguito solo sul server
  console.log('Rendering sul server');
} else {
  // Codice che viene eseguito solo sul client
  console.log('Rendering sul client');
}