Skip to content

Gli sviluppatori sono spesso di fronte a decisioni che influenzeranno l’intera architettura delle loro applicazioni. Una delle decisioni critiche che un dev deve prendere è dove implementare il rendering della sua applicazione. Questo aspetto può essere difficile da valutare dato che esistono diversi modi per creare un sito web.

Prima di iniziare vorrei assicurarmi che conoscessi le differenze tra codice HTML e DOM. In caso negativo ti consiglio di partire da questa guida.

SSR – Rendering lato server

Hai sviluppato un sito web con un framework in JavaScript, rendering lato client e Google fa fatica ad indicizzarlo? Il rendering budget è troppo basso e Google non esegue bene le tue pagine? Allora potresti valutare una soluzione di server side rendering – SSR.

  • SSR: Rendering lato server, ovvero renderizzare un’applicazione client-side in HTML direttamente sul web server.

Il rendering lato server è un processo che permette di generare l’HTML completo per una pagina sul server in risposta ad una richiesta di navigazione di un client. Ciò evita ulteriori round trip per il recupero e la creazione di modelli di dati sul client, poiché vengono gestiti prima che il browser ottenga una risposta.

Il rendering lato server generalmente produce ottimi valori di First Paint (FP) e First Contentful Paint (FCP).

  • FP: First Paint – la prima volta che un pixel diventa visibile all’utente.
  • FCP: First Contentful Paint – il momento in cui diventa visibile il contenuto richiesto (corpo dell’articolo, ecc.).

L’esecuzione e il rendering della pagina sul server consentono di evitare di inviare molti JavaScript al client, il che consente di ottenere un Time to Interactive (TTI) veloce.

  • TTI: Time To Interactive – l’ora in cui una pagina diventa interattiva (eventi collegati, ecc.).

Con il rendering lato server si invia in pratica solo testo e link al browser dell’utente. Questo approccio può funzionare bene per un ampio spettro di dispositivi e condizioni di rete. Il SSR rende rapida la navigazione, è poco probabile che gli utenti rimangano in attesa dell’elaborazione di JavaScript prima di poter utilizzare il sito.

Anche quando JS di terze parti non può essere evitato, l’utilizzo del SSR per ridurre i costi JS di terze parti può darti più “budget” per il resto. Tuttavia, questo approccio presenta uno svantaggio principale: la generazione di pagine sul server richiede tempo, che spesso può portare a un Time to First Byte (TTFB) più lento.

  • TTFB: Time to First Byte – visto come il tempo tra il clic di un collegamento e il primo bit di contenuto in arrivo.

Se il rendering lato server è sufficiente per la tua applicazione dipende in gran parte dal tipo di esperienza che stai creando. C’è un dibattito di lunga data sulle applicazioni corrette del SSR rispetto al rendering lato client, ma è importante ricordare che puoi scegliere di utilizzare il server side rendering per alcune pagine e non altre.

Alcuni siti hanno adottato con successo tecniche di rendering ibrido. Il server Netflix esegue il rendering delle sue pagine di destinazione relativamente statiche (che hanno poche interazioni), mentre preleva il JS per le pagine ad alta interazione, offrendo a queste pagine più pesanti rese dal client una maggiore possibilità di caricamento rapido.

Molti framework, librerie e architetture moderne rendono possibile il rendering della stessa applicazione sia sul client che sul server. Queste tecniche possono essere utilizzate per il rendering lato server, tuttavia è importante notare che le architetture in cui il rendering avviene sia sul server che sul client dipendono dal sistema utilizzato e hanno caratteristiche prestazionali e compromessi molto diversi.

  • Gli utenti di React possono usare renderToString () o soluzioni costruite su di esso come Next.js per il rendering del server.
  • Gli utenti di Vue possono consultare la guida al rendering del server di Vue o Nuxt.
  • Angular ha Universal.

Le soluzioni più popolari impiegano tuttavia una qualche forma di hydration, quindi sii consapevole dell’approccio in uso prima di selezionare uno strumento.

SR – Rendering statico

Il rendering statico offre buoni valori di First Paint, First Contentful Paint e Time To Interactive, supponendo che la quantità di JS sul lato client sia limitata. A differenza del rendering lato server – SSR, il rendering statico riesce anche a ottenere un Time To First Byte costantemente veloce, poiché non è necessario generare al volo l’HTML di una pagina. La pagina statica viene infatti generata prima.

Generalmente, il rendering statico significa produrre in anticipo un file HTML separato per ciascun URL. Con le risposte HTML generate in anticipo, i rendering statici possono essere distribuiti su più CDN per sfruttare la memorizzazione nella cache.

Le soluzioni per il rendering statico sono disponibili in tutte le forme e dimensioni. Strumenti come Gatsby sono progettati per far credere agli sviluppatori che la loro applicazione venga renderizzata in modo dinamico piuttosto che generata come fase di creazione. Tramite Gatsby.js, invece di aspettare di generare pagine quando richiesto, puoi pre-costruire pagine pronte per essere consegnate istantaneamente ai tuoi utenti.

Altri software come Jekyll e Metalsmith sono in grado di generare file statici partendo da codice sorgente e forniscono un approccio più guidato dai modelli.

Uno degli svantaggi del rendering statico è che i singoli file HTML devono essere generati per ogni possibile URL del sito web. Questo processo può essere impegnativo o addirittura impossibile quando non puoi prevedere quali URL saranno richiamati, oppure per i siti con un gran numero di pagine uniche.

Gli utenti di React potrebbero avere familiarità con l’esportazione statica di Gatsby, Next.js o Navi. Tuttavia, è importante comprendere la differenza tra rendering statico e prerendering:

  • le pagine con rendering statico sono interattive senza la necessità di eseguire molti JS sul lato client,
  • mentre il prerendering migliora il First Paint e il First Contentful Paint di una SPA (Single Page Application, applicazione a singola pagina) su cui deve essere avviato il client affinché le pagine siano veramente interattive.

Per capire meglio le differenze tra il rendering statico o il prerendering, prova questo test: disabilita JavaScript e carica le pagine web create con un framework in JS.

  • Per le pagine con rendering statico, la maggior parte delle funzionalità continuerà a esistere senza JavaScript abilitato.
  • Per le pagine prerenderizzate, potrebbero esserci alcune funzionalità di base come i collegamenti, ma la maggior parte della pagina sarà vuota ed inerte.

Un altro test utile per capire è rallentare la rete utilizzando Chrome DevTools e osservare la quantità di JavaScript scaricata prima che una pagina diventi interattiva. Il prerendering richiede generalmente più JavaScript per essere interattivo e JavaScript tende a essere più complesso dell’approccio Progressive Enhancement utilizzato dal rendering statico.

Server Side Rendering vs Static Rendering

Il rendering lato server non è sempre la soluzione perfetta: la sua natura dinamica può comportare costi generali di calcolo significativi. Molte soluzioni di SSR non si caricano in anticipo, possono ritardare il TTFB o raddoppiare i dati inviati.

In React, renderToString() può essere lento in quanto sincrono e a thread singolo. Rendere efficiente il rendering del server può comportare la ricerca o la creazione di una soluzione per la memorizzazione nella cache dei componenti, la gestione del consumo di memoria, l’applicazione di tecniche di memoization e molte altre problematiche. In genere stai elaborando la stessa applicazione più volte, una volta sul client e una volta sul server. Solo perché il rendering lato server può far apparire qualcosa prima, non significa ha reso efficiente il processo.

Il rendering del server produce HTML su richiesta per ciascun URL, ma può essere più lento della semplice pubblicazione di contenuto con rendering statico. Se è possibile aggiungere ulteriori legwork, il rendering del server + la memorizzazione nella cache HTML può ridurre notevolmente i tempi di rendering del server.

L’aspetto positivo del rendering server è la capacità di estrarre più dati “live” e rispondere a una serie più completa di richieste di quanto sia possibile con il rendering statico. Le pagine che richiedono personalizzazione sono un esempio concreto del tipo di richiesta che non funzionerebbe bene con il rendering statico.

Il rendering lato server è un aspetto che potrebbe interessare anche lo sviluppo di una PWA. È preferibile utilizzare la memorizzazione delle pagine intere nella cache del service worker o semplicemente memorizzare i singoli contenuti del server?

CSR – Rendering lato client

Client Side Rendering (CSR) significa rendering delle pagine direttamente nel browser utilizzando JavaScript. Tutta la logica, il recupero dei dati, il templating e il routing sono gestiti sul client anziché sul server.

Il rendering lato client può essere difficile da ottenere e mantenere veloce per i dispositivi mobili. Può avvicinarsi alle prestazioni del puro rendering lato server se fa un lavoro minimo, mantenendo un budget JavaScript limitato ed utilizzando il minor numero di RTT possibile.

Il ritardo di andata e ritorno (RTD) o il tempo di andata e ritorno (RTT) è il tempo necessario per l’invio di un segnale più il tempo necessario per ricevere un riconoscimento di quel segnale.

Script e dati critici possono essere consegnati prima usando il HTTP/2 Server Push oppure il tag rel preload, che attiva il parser in anticipo. HTTP/2 Server Push consente di inviare le risorse del sito all’utente prima ancora che vengano richieste. È un modo elegante per ottenere i vantaggi in termini di prestazioni delle pratiche di ottimizzazione HTTP/1, come ad esempio l’integrazione inline, ma senza gli svantaggi che ne derivano.

Vale la pena valutare modelli come PRPL per garantire che le navigazioni iniziali e successive siano istantanee. PRPL è un acronimo che descrive un modello utilizzato per caricare e rendere interattive le pagine web:

  • Invia (o precarica) le risorse più importanti.
  • Renderizzare il percorso iniziale il più presto possibile.
  • Pre-cache delle risorse rimanenti.
  • lazy Load di risorse non critiche.

Il principale svantaggio del rendering lato client è che la quantità di JavaScript richiesta tende a crescere man mano che un’applicazione cresce. Ciò diventa particolarmente difficile con l’aggiunta di nuove librerie JavaScript, polyfill e codice di terze parti, che competono per la potenza di elaborazione e spesso devono essere elaborati prima di poter visualizzare il contenuto di una pagina.

Le esperienze sviluppate con CSR che si basano su grandi bundle JavaScript dovrebbero prendere in considerazione la suddivisione del codice ed essere sicuri di caricare JavaScript in lazy-load: “carica solo ciò di cui hai bisogno, quando ne hai bisogno”. Per esperienze utente con poca o nessuna interattività, il rendering del server può rappresentare una soluzione più scalabile a questi problemi.

Per le persone che creano un’applicazione a pagina singola, identificare le parti principali dell’interfaccia utente condivise dalla maggior parte delle pagine significa che è possibile applicare la tecnica di memorizzazione nella cache dell’applicazione Shell. In combinazione con i service workers questo può migliorare notevolmente le prestazioni percepite durante le visite ripetute.

Considerazioni SEO

Nella seguente infografica ufficiale di Google vengono riassunte le cinque modalità di rendering più valide e per ciascuna di essere sono elencati i dettagli, i PRO ed i CONTRO.

SSR, CSR - soluzioni di rendering per siti web in JavaScript?
Fonte: https://developers.google.com/web/updates/images/2019/02/rendering-on-the-web/infographic.png

Per la SEO c’è un sistema migliore dell’altro? Essenzialmente il sistema migliore è quello che riesce a fornire a Googlebot il maggior numero di pagine nel minor tempo.

Quale sistema riesce a darti il minor TTLB? Quale sistema agevola la scansione ottenendo tempi di risposta rapida? La soluzione uguale per tutti non esiste, dipende dal tuo CMS o framework che stai utilizzando, dipende dalle prestazioni del server e dalla tipologia di sito web.

  • TTLB: Time To Last Byte, ovvero il tempo intercorso dalla richiesta di una risorsa al momento in cui il client riceve l’ultimo byte. In pratica questo valore rappresenta il tempo impiegato dal client per ricevere TUTTO il contenuto della risposta.

I developer spesso tengono conto dell’impatto della SEO quando scelgono una strategia per il rendering sul web. Il SSR viene scelto nella maggior parte dei casi per offrire un’esperienza “completa” che i crawler possono interpretare con facilità.

Ricordati che affidarsi troppo a JS non è ancora consigliato. Infatti, i crawler dei motori di ricerca possono comprendere JavaScript, ma spesso ci sono limitazioni che vale la pena conoscere nel modo in cui vengono letti ed indicizzati. Il rendering lato client può funzionare ma spesso non senza ulteriori test e leg-work.

Recentemente il rendering dinamico è diventato un’opzione che vale la pena considerare se la tua architettura è fortemente guidata da JavaScript lato client.

In caso di dubbio, lo strumento Mobile Friendly Test è prezioso per testare che l’approccio scelto sia corretto anche per Google. Mostra un’anteprima visiva di come ogni pagina appare al crawler di Google, il contenuto HTML serializzato trovato (dopo l’esecuzione di JavaScript) e qualsiasi errore riscontrato durante il rendering.

Quando si decide un approccio al rendering, dovresti misurare e comprendere quali sono i colli di bottiglia. Quando possibile va benissimo distribuire principalmente HTML con JS minimo per un’esperienza interattiva.

Articoli correlati

Autore

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Ultimi articoli aggiornati

Richiedi un preventivo SEO e Google Ads

Porta il tuo sito web al livello successivo con l’esperienza di EVE Milano. La nostra agenzia di Search Marketing ha ricevuto oltre 1144 richieste di preventivo, un segnale chiaro della fiducia che imprenditori e manager, come te, ripongono nella nostra specializzazione tecnica e verticale nella SEO e PPC. Se la tua organizzazione cerca competenze specifiche per emergere nei risultati di Google, noi siamo pronti a fornire quel valore aggiunto. Richiedi un preventivo ora e scopri la differenza tra noi e gli altri.
Richiedi un preventivo

Vuoi rimanere aggiornato su tutte le novità SEO e Google Ads?

Iscriviti alla nostra newsletter!

Informativa sui cookies

Noi e terze parti selezionate utilizziamo cookie o tecnologie simili per finalità tecniche e, con il tuo consenso, anche per le finalità di esperienza e misurazione come specificato nella cookie policy. Puoi liberamente prestare, rifiutare o revocare il tuo consenso, in qualsiasi momento, accedendo al pannello delle preferenze. Il rifiuto del consenso può rendere non disponibili le relative funzioni. Usa il pulsante “Accetta” per acconsentire. Usa il pulsante “Rifiuta” per continuare senza accettare.