Rendering lato client, lato server e ge­ne­ra­zio­ne di siti statici a confronto

Ogni volta che si accede a un sito web, il browser deve rendere quella pagina in modo che sia pre­sen­ta­ta in modo ac­cat­ti­van­te e offra il grado di in­te­rat­ti­vi­tà de­si­de­ra­to. Tuttavia, a seconda dell’approccio di pro­gram­ma­zio­ne del progetto web, gli script dinamici e il codice statico possono essere elaborati in modi molto diversi. Vediamo da vicino i tre approcci più im­por­tan­ti: rendering lato server, rendering lato client e ge­ne­ra­zio­ne di siti statici.

Il rendering o scripting lato server (in inglese co­no­sciu­to come “server-side rendering” o “server-side scripting”) è una tecnica uti­liz­za­ta nello sviluppo di siti web con elementi dinamici e ap­pli­ca­zio­ni web. Si basa sull’uso di script che vengono eseguiti dal server web ser­ven­do­si di linguaggi di script adeguati quando si richiede il contenuto cor­ri­spon­den­te con il browser. Tutte le istru­zio­ni HTML, CSS e Ja­va­Script sono caricate com­ple­ta­men­te con la richiesta iniziale.

Tipici linguaggi di pro­gram­ma­zio­ne per il rendering lato server sono i seguenti:

• Java
• Ruby
• ASP.NET
• Perl
• PHP
• Python
• Node.js o Ja­va­Script

La grande forza di SSR risiede nel fatto che le pagine web sono pre­ca­ri­ca­te dal server. Dal punto di vista dell’utente, una richiesta viene elaborata quasi im­me­dia­ta­men­te e la pagina ri­chia­ma­ta viene perciò vi­sua­liz­za­ta molto ra­pi­da­men­te. Questo approccio per ot­ti­miz­za­re la velocità di ca­ri­ca­men­to è par­ti­co­lar­men­te adatto ai siti web statici. Il ca­ri­ca­men­to veloce della pagina ha anche un effetto positivo sulla va­lu­ta­zio­ne da parte dei motori di ricerca, perché i crawler possono rilevare le pagine più fa­cil­men­te o più ra­pi­da­men­te grazie al rendering lato server.

Lo scripting lato server richiede che il server fornisca pagine HTML pre­ca­ri­ca­te a ogni richiesta. In par­ti­co­la­re, se un client invia con­ti­nua­men­te ulteriori richieste al server web per fornire all’utente nuove in­for­ma­zio­ni mo­di­fi­ca­te, le capacità del server ri­sul­te­ran­no so­vrac­ca­ri­ca­te. Il rendering lato server (SSR) non è quindi adatto per i siti web che hanno un alto numero di richieste o che ri­chie­do­no un gran numero di in­te­ra­zio­ni utente. Nei progetti di questo tipo, il tempo di risposta del server web an­nul­le­reb­be il vantaggio del ca­ri­ca­men­to ot­ti­miz­za­to della pagina.

Il lin­guag­gio di scripting lato client più im­por­tan­te è Ja­va­Script.

Il rendering lato client (CSR) è un approccio utile so­prat­tut­to per i progetti web con molte in­te­ra­zio­ni utente. Se il processo di ca­ri­ca­men­to iniziale del sito web è re­la­ti­va­men­te lungo, il suc­ces­si­vo rendering delle pagine suc­ces­si­ve è più veloce. L’espe­rien­za utente è si­gni­fi­ca­ti­va­men­te migliore che con il rendering lato server, poiché non tutti gli script e i contenuti devono essere caricati com­ple­ta­men­te in una volta sola quando l’utente richiama una nuova pagina.

Poiché gli script vengono eseguiti nel browser dell’utente, questi ha la pos­si­bi­li­tà di vi­sua­liz­za­re il codice sorgente, a dif­fe­ren­za di quanto accade con gli script lato server.

Gli script lato client pre­sen­ta­no due problemi cruciali: in primo luogo, è più difficile per i motori di ricerca rilevare e in­di­ciz­za­re le pagine. I crawler di Google sono in grado di farlo, ma le con­di­zio­ni SEO non sono ottimali in questo caso, so­prat­tut­to perché molti altri motori di ricerca spesso non riescono affatto a in­di­ciz­za­re le pagine ren­de­riz­za­te lato client.

D’altra parte, lo scripting lato client richiede che Ja­va­Script sia sup­por­ta­to dal browser. So­li­ta­men­te è sempre così, ma poiché anche i pop-up e gli strumenti di trac­cia­men­to si basano sulla tecnica CSR e gli script lato client in­fluen­za­no il tempo di ca­ri­ca­men­to, ci sono varie esten­sio­ni del browser che bloccano gli script.

Tra i ge­ne­ra­to­ri di siti statici più popolari rientrano i seguenti:

• Jekyll
• Hugo
• Next
• Gatsby
• Gridsome
• Nuxt
• Hexo
• Eleventy
• Jigsaw
• Vuepress

La ge­ne­ra­zio­ne di siti statici mostra i suoi punti di forza so­prat­tut­to nei progetti che hanno molti contenuti che non cambiano re­go­lar­men­te. Degli esempi tipici sono un sito personale o un blog, che pre­sen­ta­no ti­pi­ca­men­te pochi contenuti dinamici e be­ne­fi­cia­no no­te­vol­men­te della massima velocità ri­sul­tan­te dal pre­ren­de­ring (cioè dal pre­ca­ri­ca­men­to della pagina) da parte di un ge­ne­ra­to­re di siti statici. Inoltre, i progetti SSG sono meno soggetti ad attacchi, poiché il po­ten­zia­le di rischio è limitato al singolo clic quando il client vi­sua­liz­za la pagina.

Il pre­ren­de­ring nel contesto di SSG non ha solo vantaggi: l’approccio si rivela estre­ma­men­te im­pra­ti­ca­bi­le quando un progetto web è soggetto a cam­bia­men­ti regolari, sia di natura tecnica che in termini di contenuto. A ogni modifica, le pagine statiche del progetto web devono essere “pre­ca­ri­ca­te” di nuovo. Più esteso è il progetto, più tempo richiede questo processo di co­stru­zio­ne, ed è per questo che la ge­ne­ra­zio­ne di siti statici non è adatta a siti web con un gran numero di pagine statiche.

Il rendering lato server assicura un ca­ri­ca­men­to delle pagine ec­cel­len­te, che però comporta un carico elevato sul server web. Il rendering lato client va nella direzione opposta e al­leg­ge­ri­sce il carico del server rendendo prima una gran parte della pagina nel browser, a patto che l’utente non abbia bloccato Ja­va­Script. La ge­ne­ra­zio­ne di siti statici risparmia sia il server che il client e, grazie all’approccio di pre­ren­de­ring, assicura una consegna veloce del contenuto, a con­di­zio­ne che non si tratti di contenuti in­te­rat­ti­vi e in continuo cam­bia­men­to.

Tutte e tre queste strategie per il rendering dei progetti web hanno i loro pro e contro. Valutate at­ten­ta­men­te quali ca­rat­te­ri­sti­che si adattano meglio al vostro progetto per trovare l’approccio migliore per la vostra ap­pli­ca­zio­ne web.