Rendering lato server

Il rendering lato server è un approccio in cui il server genera il markup completo di una pagina e lo invia al browser, anziché inviare un documento minimo che JavaScript poi popola. Il browser può visualizzare contenuti significativi non appena riceve la risposta, senza dover attendere il download, l'analisi, l'esecuzione e il recupero dei dati da un pacchetto di dati.

Risolve i punti deboli specifici e ben documentati del rendering puramente lato client. I contenuti vengono visualizzati molto più rapidamente, soprattutto su dispositivi e connessioni più lenti, dove l'esecuzione di JavaScript è dispendiosa. I motori di ricerca e altri sistemi di acquisizione automatica ricevono i contenuti direttamente, senza dipendere da una fase di rendering che potrebbe essere ritardata o incompleta. Le anteprime per la condivisione sui social funzionano senza necessità di gestione particolare. Inoltre, l'esperienza utente si degrada in modo più fluido quando JavaScript non viene caricato o eseguito correttamente, evenienza che si verifica più spesso di quanto la maggior parte dei team immagini.

L'idratazione è il costo che accompagna questo processo ed è spesso sottovalutata. Dopo che il markup renderizzato dal server viene visualizzato, il framework lato client deve associare i gestori di eventi e ricostruire il suo stato interno per rendere la pagina interattiva. Durante questo periodo la pagina appare pronta ma non risponde, il che produce un errore caratteristico quando un visitatore clicca su un elemento visibile e non succede nulla. Su pagine di grandi dimensioni e dispositivi più lenti, questo intervallo di tempo può essere considerevole.

Sono emersi diversi approcci per ridurre tale costo. L'idratazione parziale e selettiva rendono interattive solo le parti interattive di una pagina, anziché l'intera pagina. Lo streaming invia il markup progressivamente, in modo che il contenuto appaia prima che l'intera pagina sia stata generata. Le architetture a isole trattano i componenti interattivi come unità isolate all'interno di un markup altrimenti statico. Ciascuno di questi approcci riduce la quantità di lavoro lato client richiesto dopo il rendering iniziale.

La generazione di siti statici è l'alternativa da considerare per prima per i contenuti che non cambiano a ogni richiesta. Le pagine vengono renderizzate in fase di compilazione e servite come file, il che è più veloce del rendering a ogni richiesta, più economico da gestire, più resiliente e più facile da memorizzare nella cache periferica. Laddove il contenuto cambia ma non a ogni visitatore, le strategie di rigenerazione incrementale ricostruiscono le pagine interessate secondo una pianificazione o su richiesta, ottenendo la maggior parte dei vantaggi senza una ricostruzione completa.

Le implicazioni operative differiscono dall'hosting statico in modi che richiedono una pianificazione. Il rendering per ogni richiesta consuma risorse del server in proporzione al traffico, il che introduce considerazioni di scalabilità e costi che i file statici non hanno. La memorizzazione nella cache diventa importante e la memorizzazione nella cache di pagine che contengono contenuti personalizzati richiede un'attenta separazione tra ciò che varia per utente e ciò che non lo fa. Gli errori del server ora influiscono sul rendering della pagina e non solo sul caricamento dei dati.

In pratica, la strategia di recupero dei dati determina gran parte dei vantaggi. Il rendering lato server è utile solo se i dati necessari alla pagina sono disponibili rapidamente, e un rendering lato server che attende diversi servizi interni lenti può essere più lento a trasmettere il primo byte rispetto a un rendering lato client che mostra immediatamente una shell. Laddove le dipendenze sono lente, lo streaming delle parti pronte mentre il resto viene elaborato preserva il vantaggio.

La decisione dovrebbe basarsi sul contenuto e sul pubblico di riferimento, piuttosto che sulle mode del momento. Le pagine ricche di contenuti, che devono posizionarsi bene nei risultati di ricerca e caricarsi velocemente anche con connessioni lente, ne traggono un notevole vantaggio. Le applicazioni altamente interattive, protette da autenticazione, dove la visibilità nei risultati di ricerca è irrilevante e gli utenti hanno già caricato l'applicazione, ne traggono molto meno beneficio e la complessità potrebbe non essere giustificata. Molti prodotti utilizzano saggiamente approcci diversi per sezioni diverse.

Poiché la scelta influisce simultaneamente su infrastruttura, distribuzione e prestazioni di ricerca, si tratta di una decisione architetturale piuttosto che di una preferenza front-end. In pratica viene valutata all'interno prestazioni web lavorare contro i dati di campo misurati, implementati tramite sviluppo del prodottoe le implicazioni della ricerca vengono valutate con servizi di marketing, poiché il comportamento di indicizzazione è spesso l'argomento più forte a favore del cambiamento.