Angular Universal in pratica – Come costruire app SEO Friendly a pagina singola con Angular

Si è parlato molto di Angular negli ultimi mesi e di come usarlo per costruire applicazioni client, ma una delle sue più importanti innovazioni sta effettivamente avvenendo sul server.

Questa è una tecnologia che potrebbe aiutare ad abilitare un tipo completamente nuovo di applicazioni web: Angular Universal. Scopriamone di più! Esaminiamo i seguenti argomenti:

  • Svantaggi delle app a pagina singola
  • Perché allora non usiamo app a pagina singola ovunque?
  • Comprendere le implicazioni SEO di un’app a pagina singola
  • Cos’è Angular Universal, cosa permette?
  • Il rendering lato server in realtà non è solo il rendering sul server
  • Una demo di un’app a pagina singola renderizzata lato server in azione
  • Pre-rendering al momento della costruzione – caricare le app pre-renderizzate su Amazon S3
  • La caratteristica killer di Angular Universal: Dependency Injection
  • Conclusioni

Questo post è un’introduzione ad Angular Universal. Per una guida più dettagliata su come usarlo in pratica, date un’occhiata a questo post:

Angular Universal: a Complete Practical Guide

Advantages of Single Page Applications

Le applicazioni a pagina singola esistono da un po’, e frameworks come Angular, React o Ember sono probabilmente le librerie Javascript che ricevono più attenzione nel mondo Javascript.

I vantaggi delle SPA sono in realtà solo una cosa

I vantaggi delle app a pagina singola sono potenzialmente molti:

  • quando l’utente naviga sulla pagina, solo parti di essa vengono sostituite, rendendo l’esperienza più fluida
  • dopo il primo caricamento della pagina, solo i dati vanno sul filo quando l’utente naviga nell’app: JSON viene consegnato al browser e applicato ai modelli HTML direttamente al browser
  • questo porta a migliori prestazioni e apre la possibilità per quei servizi di backend di essere usati per altre cose, dato che restituiscono solo dati

Possiamo ridurre tutto questo a una sola cosa:

Single Page Apps possono fornire una User Experience molto migliore!

E la user experience è fondamentale nel mondo pubblico di Internet. Ci sono numerosi studi che provano al di là di ogni dubbio che il drop off delle pagine e l’abbandono degli utenti aumentano molto rapidamente con il ritardo della pagina.

Se una pagina impiega 200ms in più per caricarsi, questo avrà un potenziale alto impatto sul business e sulle vendite (vedi questa ricerca di Google). Questo è ancora più vero sui dispositivi mobili dove le app tendono ad essere più lente.

Perché allora non usare le SPA ovunque?

Viste queste statistiche e il fatto che le SPA danno un’esperienza utente molto migliorata, perché non tutti usano app a pagina singola per tutto?

Sono in giro da anni, e qualsiasi sito web con un sistema di navigazione potrebbe beneficiare dall’essere costruito in questo modo.

Comprendere le implicazioni SEO di un’app a pagina singola

C’è una ragione principale per cui le app a pagina singola non sono usate ovunque finora (con due cause separate):

Le app a pagina singola non funzionano bene sui motori di ricerca

Le due ragioni sono:

Il motore di ricerca deve “indovinare” quando la pagina è completa

Quando una pagina singola viene recuperata, un motore di ricerca vedrà solo pochissimo HTML. Solo quando il framework MVC entra in azione, la pagina viene effettivamente resa completa utilizzando i dati ottenuti dal server.

Il problema è che il motore di ricerca deve indovinare quando il framework Javascript finisce di rendere la pagina, quindi c’è il rischio di indicizzare contenuti incompleti.

La seconda ragione per cui le SPA non funzionano bene con i motori di ricerca è:

I link profondi SPA sono difficili da indicizzare

A causa della mancanza di supporto della cronologia HTML5 nei browser, le app a pagina singola basano i loro URL di navigazione in ancore HTML bookmark (URL con #, come /home#section1). Questi non sono facilmente indicizzati come pagine separate dai motori di ricerca, ci sono modi per farlo, ma è un dolore e ci saranno sempre difficoltà nell’indicizzare correttamente questo rispetto all’uso del semplice HTML.

La conclusione potrebbe essere che non ha senso avere il sito più facilmente navigabile se il modo in cui è costruito impedisce di avere un buon SEO.

Ora la buona notizia

La buona notizia è che nessuna di queste due ragioni è più precisa al 100%! Google ha iniziato a indicizzare meglio le app a pagina singola.

E la recente deprecazione di IE9 significa che la cronologia HTML5 è disponibile quasi ovunque, rendendo l’uso di URL di ancoraggio non più necessario per le SPA, possiamo semplicemente usare URL semplici (come /home/section1).

Questa è una grande notizia, ma ci sono altri motori di ricerca che portano traffico significativo. Baidu per esempio guida più della metà del traffico in Cina (attualmente 1,3 miliardi di persone).

Inoltre, c’è ancora il problema delle prestazioni: un’app a pagina singola sarà più lenta a causa delle grandi quantità di Javascript di cui ha bisogno e dei grandi tempi di avvio, e quindi si comporterà peggio di una soluzione basata su HTML.

E questo significa drop off delle pagine, questo problema non andrà via molto presto, specialmente su mobile. C’è un modo per avere il meglio di tutti i mondi, e ottenere sia la navigazione istantanea, che la compatibilità SEO e le alte prestazioni su mobile?

La risposta è sì, con Angular Universal.

Cos’è Angular Universal, cosa permette?

In parole povere, Angular Universal ci permette di costruire applicazioni che hanno sia i vantaggi in termini di prestazioni e di coinvolgimento degli utenti delle applicazioni a pagina singola combinate con la facilità di SEO delle pagine statiche.

Il rendering lato server in realtà non è solo il rendering sul server

Angular Universal ha molte altre caratteristiche oltre a dare una soluzione per il rendering di HTML sul server. Basandoci sul termine “rendering lato server”, potremmo pensare che ciò che fa Angular Universal è simile, per esempio, a un linguaggio di template lato server come Jade. Ma c’è molta più funzionalità in esso.

Con Angular Universal, si ottiene quel carico iniziale di HTML renderizzato sul server, ma si avvia anche una versione ridotta di Angular sul client e da lì Angular prende la pagina come un’app a pagina singola, generando da lì tutto l’HTML sul client invece che sul server.

Così il risultato finale che si ottiene è lo stesso, la sua applicazione a pagina singola in esecuzione, ma ora perché si è ottenuto il payload HTML iniziale dal server si ottiene un tempo di avvio molto migliore e anche un’app completamente indicizzabile SEO.

Pre-rendering al momento della compilazione – caricare le app pre-renderizzate su Amazon S3

Un’altra possibilità che Angular Universal apre è il pre-rendering del contenuto che non cambia spesso al momento della compilazione. Questo sarà possibile utilizzando Grunt, Gulp o i plugin Weppack. Ecco come sarà una configurazione di Gulp, che pre-renderizza il contenuto della nostra applicazione in un file:

E poi semplicemente lo carica in un bucket Amazon S3 usando l’Amazon CLI:

Se colleghiamo questo bucket a una distribuzione CDN Cloudfront, abbiamo un sito web molto conveniente e scalabile.

E se l’utente inizia a interagire con la pagina immediatamente?

C’è un ritardo iniziale tra il momento in cui il semplice HTML viene reso e presentato all’utente e il momento in cui Angular entra in gioco sul lato client e assume il ruolo di SPA.

In quel lasso di tempo, l’utente potrebbe cliccare su qualcosa o anche iniziare a digitare in una casella di ricerca. Ciò che Angular Universal permette attraverso la sua funzionalità di preboot è di registrare gli eventi che l’utente sta innescando, e riprodurli una volta che Angular si avvia.

In questo modo Angular sarà in grado di rispondere a quegli eventi, come per esempio mostrando i risultati della ricerca in una lista Typeahead.

Ma come appare questo sul server in termini di codice?

Come rendere HTML con Angular nel server

Il modo in cui il contenuto viene reso sul server è usando il motore di rendering express Angular Universal expressEngine :

C’è anche un motore Hapi disponibile se si preferisce usare Hapi invece di Express. Ci sono anche motori di rendering server in arrivo per tutti i tipi di piattaforme: C#, Java, PHP, vedi questo post precedente per maggiori dettagli.

Come iniziare con Angular Universal?

Il posto migliore per iniziare è lo starter ufficiale universal-starter, con lo starter si ottiene un’applicazione in esecuzione che include un server express con il rendering lato server funzionante out of the box.

Quello che è innovativo di Angular Universal è la sua semplicità di utilizzo. Una delle principali caratteristiche del design di Angular Universal è il modo in cui utilizza l’iniezione delle dipendenze.

Lo sviluppo del rendering lato server non è come codificare solo per il client

La maggior parte delle volte vogliamo che la nostra applicazione faccia esattamente la stessa cosa sul server come sul client, non dipendendo direttamente dalle API del browser.

La realtà dello sviluppo del rendering lato server è che questo non è sempre possibile, e ci sono alcune cose che vogliamo fare diversamente sul client e sul server.

Prendiamo ad esempio il rendering di un grafico: probabilmente vogliamo chiamare una libreria di terze parti che usa SVG. Non possiamo chiamarla sul server, quindi come la renderizziamo?

Un altro esempio, come possiamo rendere le pagine autenticate? Perché il contenuto dipende da chi è attualmente loggato.

Using Dependency Injection to implement Authentication

Per gestire l’autenticazione, questo è un modo per farlo:

  • Sul client vogliamo che l’identità dell’utente sia presa da un token disponibile su un cookie o nella memoria locale del browser.

  • sul server, durante il rendering della richiesta vogliamo che il token di identità sia letto da un’intestazione di richiesta HTTP.

Come avere lo stesso output di pagina mentre si naviga verso quella pagina sul client tramite una transizione del router e sul server tramite un refresh del browser?

Prima definiamo un’interfaccia di servizio

Il primo passo è definire un’interfaccia che il servizio fornirà, che è indipendente dal runtime:

Quindi forniamo due implementazioni per questa interfaccia, una per il client e l’altra per il server. Per esempio, sul server non c’è occasione che il metodo di login venga chiamato, quindi lanciamo un errore:

Mentre sul client, attiveremo la schermata di blocco Auth0 (una libreria di terze parti solo per il browser) per fornire un modulo di accesso:

Iniettiamo quindi diverse implementazioni dell’interfaccia sul server e sul client, per lo stesso token di iniezione:

E questo è come possiamo fare qualcosa di diverso sul client e sul server in Angular Universal, sfruttando il contenitore di dependency injection di Angular.

In effetti, Angular Universal è costruito anche utilizzando questa nozione: per esempio il modo in cui l’HTML viene reso è che invece di iniettare un renderer DOM durante il bootstrapping del framework, si inietta un renderer server che genera HTML utilizzando la libreria di serializzazione HTML parse5.

Conclusioni

Come ogni tecnologia, i vantaggi del rendering lato server si evolveranno nel tempo. Ma in questo momento, il rendering lato server presenta un grande vantaggio per la costruzione di applicazioni mobile-friendly, amichevoli per i motori di ricerca che hanno un alto coinvolgimento dell’utente grazie alla navigazione istantanea senza soluzione di continuità.

Oggi è più facile che mai costruire questi tipi di applicazioni usando Angular Universal e lo starter universale.

Con Angular Universal l’uso della dependency injection rende molto semplice fare qualcosa di leggermente diverso sul server che sul client se ne abbiamo bisogno.

Iniziare con Angular

Se vuoi imparare di più su Angular, dai un’occhiata al corso Angular per principianti:

Altri post su Angular

Se ti è piaciuto questo post, ecco alcuni altri post popolari sul nostro blog:

  • Angular Router – Come costruire un menu di navigazione con Bootstrap 4 e percorsi annidati
  • Angular Router – Visita guidata estesa, Evitare le trappole comuni
  • Componenti Angular – I fondamenti
  • Come eseguire Angular in produzione oggi
  • Come costruire applicazioni Angular usando Observable Data Services – Trappole da evitare
  • Introduzione a Angular Forms – Template Driven, Model Driven o In-Between
  • Angular ngFor – Imparare tutte le caratteristiche tra cui trackBy, perché non è solo per gli array?
  • Angular Universal in pratica – Come costruire applicazioni SEO Friendly a pagina singola con Angular
  • Come funziona davvero il rilevamento dei cambiamenti in Angular?

Leave a Reply