CSR, SSR, SSG, ISR: come scegliere il giusto paradigma di rendering

I moderni framework Web offrono molte opzioni su come distribuire un sito o un'app dal server al client. Puoi generare codice HTML su entrambi i lati o eseguire il pre-rendering per la distribuzione ad alta velocità tramite una rete di distribuzione dei contenuti.

Decidere come strutturare un sito o un'app si basa su alcuni fattori diversi. Devi essere consapevole di come i visitatori accederanno al tuo sito o alla tua app. Dovresti capire se la velocità di caricamento è più importante per il caricamento iniziale o per la navigazione successiva. Considera anche la frequenza con cui aggiornerai il sito.

Tieni a mente tutti questi fattori per soppesare i pro ei contro di ogni paradigma di rendering.

Rendering di siti Web in più modi

Il rendering di un sito Web si riferisce al processo mediante il quale un sito Web viene visualizzato in un browser Web. Esistono molti modi diversi per affrontare il processo di conversione dei dati grezzi in HTML formattato sullo schermo di un utente.

Ogni metodo ha i suoi pro e contro e conoscere i vantaggi e gli svantaggi di ciascuno può aiutarti a scegliere quello giusto per il tuo sito.

CSR: il browser si fa carico

CSR sta per Client Side Rendering. Quando esegui il rendering di un'app o di un sito lato client, il server passa poco o nessun codice HTML tranne una piccola parte di codice boilerplate. La pagina richiede quindi tutti i dati di cui ha bisogno dal server, dopo l'evento di caricamento della pagina, tramite richieste AJAX.

Quando un'app o una pagina esegue il rendering lato client, il server passa uno script al client che genererà l'HTML sul browser del client. Ciò consente applicazioni a pagina singola che non aggiornano il browser quando interagisci con esse.

Le app CSR sono spesso veloci da caricare durante la navigazione, ma inizialmente potrebbero essere lente da caricare. La velocità dipenderà in gran parte dal framework scelto per eseguire il rendering e dal numero di librerie e componenti aggiuntivi aggiuntivi utilizzati. Maggior parte popolari framework JavaScript moderni includere un'opzione per la CSR.

Le pagine e le app con rendering completamente lato client soffrono dell'impossibilità di accedere direttamente a una determinata pagina utilizzando un URL. Quando un'app con rendering lato client viene avviata per la prima volta, indipendentemente dall'URL immesso, passerà allo stesso punto di partenza.

SSR: Rendering su un server centrale

SSR sta per Server Side Rendering. Questa è una forma molto più tradizionale di rendering di pagine Web in cui i siti generano HTML in base a modelli e inviano al client una combinazione di HTML, fogli di stile e script. La maggioranza di i framework web di back-end più popolari rientrano in questa categoria.

Le app e i siti con rendering lato server tendono ad avere caricamenti iniziali più rapidi, ma ogni navigazione successiva richiederà un aggiornamento completo. Ciò significa che non solo impiegheranno più tempo, ma gli sviluppatori che lavorano con SSR dovranno tenere conto della gestione delle sessioni.

Il più grande vantaggio dei siti e delle app generati da SSR è la coerenza della navigazione del percorso. Un utente che immette un determinato percorso verrà indirizzato direttamente alla pagina richiesta. Alcuni framework gestiscono i reindirizzamenti degli utenti da una pagina all'altra all'interno dell'app, ma gli utenti potrebbero non essere in grado di accedere alla pagina che desiderano inizialmente.

Molti framework moderni offrono soluzioni miste che iniziano servendo al client una pagina con rendering del server. Una volta che la pagina è stata caricata, si verifica un evento noto come idratazione in cui gli eventi di script lato client sono collegati ai controlli della pagina. Da qui in poi, il client gestisce qualsiasi navigazione.

Una dinamica mista offre agli utenti la possibilità di accedere direttamente a qualsiasi pagina in un'app, pur ricevendo la velocità e l'uniformità di un'applicazione a pagina singola. Next.js offre molteplici paradigmi di rendering, così come Nuxt.js e Sveltekit.

SSG: Rendering ridotto al minimo

SSG, o Static Site Generation, aggira la necessità di generare HTML sul lato client o server. Invece, i siti e le app in stile SSG precompilano ogni pagina di cui potrebbero aver bisogno e inviano i risultati a un CDN per una consegna rapida.

Questo è un metodo estremamente efficace per servire le pagine web in modo estremamente rapido. I risultati vengono normalmente compilati in semplici bundle contenenti tutto l'HTML ei fogli di stile necessari per una singola pagina. Questi pacchetti sono mantenuti il ​​più compatti possibile per garantire che l'utente li riceva il più rapidamente possibile.

I siti SSG tendono a offrire velocità di caricamento eccezionalmente rapide, nonostante richiedano un aggiornamento per ogni navigazione. Il principale svantaggio di un sito statico, tuttavia, è la mancanza di flessibilità. Sistemi altamente dinamici come app di social media o complesse piattaforme di e-commerce richiederanno molte più modifiche di quelle che un SSG può facilmente gestire.

Molti siti statici richiederanno anche una maggiore quantità di sovraccarico da modificare poiché ogni nuova modifica dovrà essere compilata in modo indipendente. Ciò rende il rendering in stile SSG una scelta sbagliata per i siti che cambiano rapidamente, come una vetrina digitale con inventario in rapida evoluzione o app di social media.

ISR: un po' di tutto

Facilmente il tipo di rendering più complesso, ma anche il più vantaggioso, ISR è l'acronimo di Incremental Static Regeneration. ISR combina la velocità e la scalabilità dei siti generati staticamente con la reattività delle app in stile SSR e CSR.

Quando viene richiesta una pagina in una pagina o in un'app in stile ISR, il server verificherà innanzitutto se è presente una versione memorizzata nella cache non scaduta della pagina. Se c'è, il server servirà immediatamente la pagina memorizzata nella cache.

Se non esiste una versione memorizzata nella cache della pagina o è trascorso abbastanza tempo dalla sua generazione, il server genererà una nuova versione. Questa nuova versione verrà passata al client e memorizzata nella cache per un uso futuro.

Questo tipo di rendering è più complesso da configurare, ma automatizza la maggior parte dei problemi riscontrati normalmente dai siti SSG. Ciò consente alle app di offrire sia la velocità che l'affidabilità di un'app generata staticamente, eliminando al contempo il sovraccarico aggiuntivo.

Diversi framework moderni offrono già l'opzione del rendering in stile ISR. Molti altri hanno il supporto per la generazione incrementale in fase di sviluppo. La maggior parte dei principali framework supporterà presto il rendering ISR se non lo fanno già.

Quale tipo di rendering è il migliore?

Esistono diversi modi per eseguire il rendering di un sito Web o di un'app. Ciascuno di questi quattro tipi di rendering ha più varianti. Nessun tipo di rendering è ideale per tutti i progetti e il tipo che scegli dipenderà da ciò che è più importante nel tuo sito o nella tua app.

Quando si sceglie un paradigma di rendering per il proprio progetto, è importante considerare la velocità, il modo in cui il pubblico utilizzerà il progetto e la frequenza con cui il sito cambierà. Questi saranno i principi primari che ti aiuteranno a decidere il modo migliore per strutturare il tuo sito o la tua app.