arrow for title

SPA: server-side rendering, ne hai davvero bisogno?

12 Set, 2019 Sviluppo
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.

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.

Numero di siti Internet sviluppati

siti sviluppati

Percentuali d’uso tra gli sviluppatori Javascript

uso degli sviluppatori

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

Svantaggi

Come viene servita la prima pagina?

Questo è un esempio di come un’applicazione web viene servita al client:

codiceLa 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:

schema crawlingFonte 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.

codiceIn 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

Svantaggi

Tools per fare SSR

toolsConclusioni

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.

tweet dan abramov
 

Carmelo Catalfamo

Blog

Potrebbe interessarti anche:

contattaci

Hai una buona idea ma non sai che pesci prendere?

Parlaci del tuo progetto