Angular day 2018: performance quasi native con Angular PWA

14 June 2018

2402

Angular day 2018, ep.6: costruiamo webapp performanti come app native insieme a Emanuele Bartolesi

Angular day 2018: Emanuele Bartolesi ci insegna a ottimizzare le app col suo talk Creare PWA con Angular 5 e Visual Studio Code.

Le app native sui browser hanno sicuramente qualche vantaggio sulle webapp in termini di performance e di funzionalità, o almeno così è stato fino a poco tempo fa, visto che la tecnologia attuale dei browser ha fatto passi da gigante. Infatti, basta dare un’occhiata su whatwebcando.today per realizzare quello che il browser sul nostro device può fare già oggi.

Non solo il divario tra le app native e le webapp si va sempre più assottigliando, ma da uno studio di marketingland.com risulta che gli utenti mobile spendono l’80% del loro tempo online solo sulle 3 app principali che hanno installato, di solito tra Facebook, Instagram, Pinterest, email e poco altro.

Angular Day 2018 - 1

Il fatto è che il processo di scaricamento e installazione delle app, per quanto non difficile, è piuttosto articolato: bisogna cercare e trovare la app sullo store, bisogna scaricarla, bisogna accettare le richieste dei permessi… Non solo, ma il numero di app disponibili negli store è oramai così ampio che emergere per una app è diventata un’impresa, con il risultato che il tempo online si concentra “nelle mani” di poche app.

Qui sopra una comparazione approssimativa del tempo di “scopribilità” tra webapp (sinistra) e app native (destra). La maggiore complessità di reperimento contribuisce in modo sostanziale all’utilizzo sempre più ridotto delle app, oltre al fatto indiscutibile che sviluppare app native è un processo decisamente più complesso e costoso rispetto alle webapp. È per questo che ci vengono in aiuto le PWA.

Progressive Web Applications (PWA)

Una PWA è un’applicazione web, che grazie a concetti come Caching e Service Worker, si comporta come una app nativa, anche come performance, riuscendo a risultare utile anche in caso di disconnessione dalla rete.

È importante sottolineare che “Progressive Web Application” in sé non è né una tecnologia, né un framework di sviluppo, ma piuttosto una serie di requisiti che una webapp deve rispettare per poter funzionare alla stregua di una nativa. Come ci si riesce quindi?

Caching di risorse statiche

Caching significa salvarsi in locale dei dati allo scopo di ridurre il numero di chiamate via rete. La prima volta che una PWA viene lanciata, scarica in locale tutte le risorse statiche come CSS, font, JavaScript, che abitualmente cambiano molto poco nel tempo, in modo che al successivo utilizzo vengano visualizzate immediatamente senza bisogno di richiederle nuovamente al server.

Caching delle risposte

Questa è una delle caratteristiche più salienti delle PWA, ovvero la capacità di salvarsi in locale i risultati delle richieste dinamiche. Ad esempio, uno potrebbe aprire il feed di Google News, e in caso di disconnessione dalla rete la PWA mostrerebbe le news scaricate la volta precedente. Se la webapp viene lanciata due volte nel giro di 5 minuti o meno, visualizzerà un bottone che consente all’utente di installare la webapp come se fosse una nativa.

Le risorse necessarie all’installazione, come grafica e font, vengono indicate nel Web Application Manifest (un file JSON di configurazione della webapp).

Service Worker

Il Service Worker è la feature che sta alla base del funzionamento delle PWA, consentendo tutta la “magia”, e che altro non è che un file JavaScript che viene “registrato” (esempio sotto) nel file JS principale della webapp. Il SW viene lanciato dalla webapp, ma risiede in un processo separato all’interno del browser, e non viene terminato quando si esce dalla app, consentend

// app.js if ('serviceWorker' in navigator) 
{ window.addEventListener('load', function(){
    navigator.serviceWorker.register('/sw.js').then(function(registration){
    // Registration was successful
    console.log('ServiceWorker registration successful with scope: ', registration.scope);
  }, function(err) {
      // registration failed :
      ( console.log('ServiceWorker registration failed: ', err);
     });
  });
}

Angular Day 2018 - 3

Il ciclo funziona così:

Il client manda una request al server
Se non c’è un Service Worker attivo, la app scarica, mette in cache le risorse statiche dell’app e ne attiva uno
Se è online, il SW prova a recuperare i dati dal server remoto, altrimenti recupera i dati dalla cache (se c’è)

Potenziali problemi

Il primo punto di attenzione è che il server dovrebbe gestire le chiamate via HTTPS, altrimenti mantenere un ciclo di richieste automatiche dei dati in background potrebbe aprire potenziali falle di sicurezza senza che l’utente ne sia consapevole.

Un altro punto importante è avere un’opportuna gestione dell’invalidazione della cache: ci sono diverse soluzioni a riguardo, come il sw-precache distribuito da Google.

Il Service Worker è uno strumento potente, ma occorre tenere a mente che anche se non ha accesso al DOM, può mandare e ricevere messaggi, ha accesso a indexedDB in locale. e ha un life cycle non banale. Illuminante a riguardo il divertente (ma serio) video di Alexander Pope su come un semplice Service Worker può sfuggire di mano.