SPA: server-side rendering, ne hai davvero bisogno?
Parliamo di SPA e server-side rendering: da sempre in secondo piano nel mondo dello sviluppo frontend, ma con buone prospettive per il futuro.
In risposta a una chiamata HTTP, prima dell’arrivo di pagine web dinamiche generate in Javascript, veniva servito HTML statico, processato da linguaggi server-side come PHP, Python, Ruby, etc.
In 20tab sviluppiamo applicazioni web in Python con Django, che ben si adatta alla parte backend come a quella frontend, lavorando sia come Product Team as a Service che come Team tecnico in outsourcing in base alle esigenze e alle caratteristiche del progetto e del team del cliente. (Puoi approfondire i nostri servizi qui!)
Negli ultimi anni però, grazie alla tecnologia Ajax e all’affermarsi di nuovi strumenti per lo sviluppo frontend, le pagine web sono diventate sempre più complesse, favorendo la nascita di applicazioni che non hanno bisogno di ricaricarsi ad ogni richiesta: le Single Page Application, spesso abbreviate in SPA.
Cosa è una SPA?
Una SPA è un sito web con cui l’utente può interagire dinamicamente, modificando la pagina in cui si trova senza dover chiedere al server l’intero render di una nuova pagina. Questo approccio permette all’utente un’esperienza di navigazione simile a quella delle applicazioni desktop: da qui il nome applicazione web.
Sotto, un elenco delle librerie e dei framework più usati per lo sviluppo di una SPA.
- React (120k stars, 21k forks, 1200 contributors)
- Vue (44,5k stars, 11,5 forks, 800 contributors)
- Angular (125k stars, 18k forks, 253 contributors)
Numero di siti Internet sviluppati
Percentuali d’uso tra gli sviluppatori Javascript
Fonti
https://www.lambdatest.com/blog/top-javascript-frameworks-for-2019/
https://2018.stateofjs.com/front-end-frameworks/overview/
Pro e contro di una SPA
Benefici
- È più veloce e performante di un sito web tradizionale, perché durante la navigazione molte risorse vengono caricate soltanto una volta.
- È facile fare debug, perché con i browser moderni è possibile monitorarne le operazioni di rete, esaminare i nodi del DOM e i dati a essi associati.
- In ottica di uno sviluppo orientato verso i microservizi, gli sviluppatori possono utilizzare, ad esempio, la codebase del backend per sviluppare anche applicazioni mobile e altri prodotti associati.
- Può sfruttare la cache dei client in maniera efficiente, tanto da poter funzionare anche offline.
Svantaggi
- Se non viene ottimizzata, il primo caricamento della pagina può essere lento con connessioni come quella 3G, soprattutto in applicazioni molto complesse.
- Può essere meno sicuro dei siti tradizionali. A causa di un insufficiente controllo degli input, ad esempio, un attaccante potrebbe sfruttare vulnerabilità come quella del cross-site scripting (XSS).
- Non è semplice eseguire delle ottimizzazioni SEO.
Come viene servita la prima pagina?
Questo è un esempio di come un’applicazione web viene servita al client:
La pagina contiene nell’<head> i tag essenziali.
Nel <body>, invece, spesso è presente un nodo senza contenuto a cui viene associato un ID. Il file generato da una SPA (bundle.js) crea il contenuto della pagina in maniera dinamica, sfruttando proprio quest’ultimo elemento.
Questo, però, potrebbe essere un problema se uno dei punti di forza della nostra applicazione deve essere la parte di indicizzazione sui motori di ricerca. Analizziamo in particolare Google.
Crawlers di Google
Quando i crawler di Google eseguono la scansione di un sito, rimandano l’esecuzione di Javascript in un secondo momento, quando tutte le risorse della pagina sono disponibili.
Questo porta a due fasi di indicizzazione:
Fonte Google webmasters - https://youtu.be/rKgF0rf009c
Javascript viene eseguito solamente durante il secondo ciclo di crawling, per vedere i contenuti che dipendono da esso. Se il contenuto della tua applicazione cambia molto frequentemente, o semplicemente è molto complessa, potresti voler assicurarti che i tuoi contenuti siano disponibili già durante la prima fase di indicizzazione.
TIP - Qui un link utile per poter controllare come il motore di ricerca processa un’applicazione web prima di indicizzarla: https://search.google.com/test/mobile-friendly
Recentemente, Google, ha anche annunciato l’aggiornamento di Chromium, il motore di render con cui i crawlers eseguono la scansione dei siti web.
"Today, we are happy to announce that Googlebot now runs the latest Chromium rendering engine (74 at the time of this post) when rendering pages for Search.” - 7 Maggio 2019
Link all’articolo: https://webmasters.googleblog.com/2019/05/the-new-evergreen-googlebot.html
Approccio ibrido
Prima di analizzare il server-side rendering, vediamo brevemente un esempio che può essere definito ibrido.
Per fare in modo che le pagine della nostra applicazione possano essere condivise sui social - che non eseguono come Google il secondo ciclo di render - spesso si usano dei sistemi di template (come Handlebars, Twig, etc...) per servire i meta della pagina lato server.
In azienda abbiamo usato questo tipo di approccio per alcuni progetti, uno in particolare: Pasupi - Food delivery finder, un motore di ricerca di ristoranti e locali che consegnano a domicilio.
L’isolamento tra backend (Python/Django) e frontend (React) ci ha facilitato anche lo sviluppo dell’applicazione, compatibile per android e iOS, che è stata realizzata con React Native e le API del backend.
Server-side rendering di una SPA
Il server-side rendering, chiamato anche SSR, è la capacità di un'applicazione javascript di eseguire il render della pagina lato server, piuttosto che nel browser dell’utente.
Benefici
- Il primo caricamento della pagina è più veloce.
- Essenziale per il SEO. Google indicizza bene anche le SPA client-side, ma ci sono motori di ricerca che potrebbero non farlo.
- Anteprima durante la condivisione di una pagina sui social. (Durante la condivisione, i social leggono solamente i meta-tag, ma non eseguono Javascript. Se usi React con React-helmet l’indicizzazione su Google potrebbe funzionare, sui social no!).
Svantaggi
- È un tipo di architettura tra le più difficili che uno sviluppatore frontend possa realizzare.
- La complessità dello sviluppo aumenta esponenzialmente in base alla complessità dell’applicazione da realizzare.
- L’integrazione di tutte le librerie esterne come styled-components o redux cambia radicalmente con SSR.
Tools per fare SSR
Conclusioni
Il costo di sviluppo e mantenimento di un’applicazione isomorfa (SPA + SSR) può essere davvero elevato e non sempre ci dà i risultati sperati.
A ciò si aggiunge che, nel mondo dello sviluppo frontend, il server-side rendering è sempre stato messo in secondo piano, non ricevendo mai la giusta spinta da parte delle compagnie che si occupano dello sviluppo di librerie o di framework.
Per quanto riguarda la parte SEO, i motori di ricerca sono sempre più aggiornati e vanno nella direzione delle single page application.
Vi lascio con un tweet di Dan Abramov, uno degli sviluppatori del team di React, che ci lascia ben sperare sul futuro supporto del server-side rendering.
