Un'app web progressiva è un sito web; tutti i suoi asset sono gli stessi che si trovano sul web, ma con nuovi strumenti per caricarli rapidamente online e disponibili offline.
Componenti dell'app
Lo sviluppo di un'applicazione richiede in genere diversi asset e risorse, dalla logica e il codice (compilati o meno) agli elementi dell'interfaccia utente come design dello schermo, immagini, loghi e caratteri.
Un'app web progressiva è un sito web, quindi tutti i suoi asset sono uguali a quelli sul web:
- HTML per i contenuti e rendering iniziale della pagina.
- JavaScript per la logica, inclusa la possibilità di eseguire moduli WebAssembly (codice compilato) e di eseguire il rendering di grafica 2D e 3D ottimizzata per l'hardware.
- CSS per layout, stili e animazioni.
- Immagini in formati web, come PNG, JPEG, WebP e SVG.
- Video in formati web, come MPEG-4 e WebM.
- Caratteri web.
- Dati in formato JSON o altri formati.
Per impostazione predefinita, i siti web scaricano gli asset sulla rete, a partire da HTML e proseguendo con il resto delle risorse.
Gestire queste risorse in modo che vengano caricate rapidamente e siano disponibili offline è stata una sfida per il web. Oggi le PWA utilizzano funzionalità precedentemente associate solo alle app specifiche per piattaforma.
Confronto tra app specifiche per piattaforma e PWA
Quando installi un'app specifica per la piattaforma, in genere scarichi un pacchetto che include tutti gli asset dell'app: codice, immagini, caratteri, video e così via. Pertanto, tutte queste risorse sono disponibili sullo spazio di archiviazione del tuo dispositivo, anche quando l'app è offline.
Al contrario, un sito web classico richiede una connessione di rete per scaricare gli asset quando necessario. Se sei offline, visualizzerai un errore nel browser perché non ci sono asset lato client.
L'approccio PWA migliora l'esperienza web tradizionale rendendo disponibili alcuni o tutti gli asset sul lato client come con le app specifiche per piattaforma. Di conseguenza, quando apri una PWA, il rendering iniziale può essere istantaneo come un'app della piattaforma perché gli asset sono disponibili senza accedere alla rete.
Cache e spazio di archiviazione
Fin dall'inizio del web, gli sviluppatori non avevano il controllo completo sul modo in cui una risorsa viene memorizzata nella cache. Il browser si occupa della cache HTTP e potrebbe memorizzare nella cache e pubblicare le risorse in base a criteri diversi. Altre opzioni di archiviazione, come Web Storage e IndexedDB, avevano lo scopo di salvare dati e oggetti semplici.
Le PWA non devono fare affidamento solo su queste norme per i loro contenuti. Al contrario, oggi disponiamo di soluzioni per ottenere un maggiore controllo su quando e come memorizzare le risorse nella cache, nonché quando e come distribuirle localmente: l'API Cache Storage. Sul Web sono disponibili alcune soluzioni di archiviazione lato client:
- Spazio di archiviazione web: include
localStorage
esessionStorage
. Queste API archiviano coppie chiave/valore semplici. Lo spazio di archiviazione sul web è limitato e ha un'API sincrona, pertanto dovrebbe essere evitato, se possibile. - IndexedDB: un database basato su oggetti (No-SQL) con un'API asincrona ottimale per le prestazioni web. IndexedDB può archiviare dati strutturati e binari sul lato client. In genere è ciò che utilizzi per archiviare i dati, ad esempio ciò che ricevi o che invii come richiesta API. È utile anche salvare i dati localmente immediatamente e sincronizzarli successivamente con il server. L'API IndexedDB viene utilizzata per interagire con il database.
- Spazio di archiviazione della cache: una raccolta di coppie di richieste e risposte HTTP che puoi utilizzare per archiviare e recuperare le risorse (con le relative intestazioni HTTP), esattamente come vengono inviate dal server. L'API Cache Storage ti consente di archiviare, recuperare, aggiornare ed eliminare le richieste di rete, ad esempio per le tue risorse, anche quando sei offline.
La necessità di service worker
Una PWA può archiviare i propri asset in Cache Storage e IndexedDB, ma come possiamo utilizzarli per offrire un'esperienza veloce e offline ai tuoi utenti. Risposta: Service worker.
Con un service worker, puoi pubblicare asset senza accedere alla rete, inviare notifiche a un utente, aggiungere un badge all'icona della PWA, aggiornare i contenuti in background e persino far funzionare l'intera PWA offline. Scopri di più sui Service worker nel prossimo capitolo.
Pronto per offline
Gli utenti si aspettano che la tua applicazione offra un'esperienza veloce e sempre disponibile. Ciò significa che l'app dovrebbe funzionare offline.
Se sei pronto per la modalità offline, non significa che tutti i tuoi contenuti o servizi dovrebbero essere disponibili senza una connessione di rete. Tuttavia, avere almeno un'esperienza di base quando l'utente è offline, come una pagina che ti chiede di connetterti a internet per continuare, fornirà una migliore esperienza utente, mantenendo l'utente all'interno dell'esperienza con la tua app anziché un errore generico del browser. In alcuni browser, si tratta di una funzionalità indispensabile per soddisfare i criteri di installazione delle PWA. La visualizzazione dell'interfaccia utente della PWA e dei contenuti memorizzati nella cache è preferibile. Consentire agli utenti di continuare a utilizzare l'intera PWA e alle modifiche del server di sincronizzazione quando sono di nuovo online è lo standard principale per lavorare offline.
Per rendere l'app disponibile offline, devi memorizzare nella cache gli asset necessari per la tua esperienza offline e fare in modo che il service worker li pubblichi in un secondo momento. Assicurati di aggiungere gli asset offline alla cache prima di averne bisogno. Si tratta di un caso particolare in cui non è possibile memorizzarli nella cache quando richiesto.
Approcci alla cache utilizzati di frequente
Nella tua PWA, sei responsabile di tutte le decisioni. Puoi scegliere l'approccio migliore per memorizzare nella cache o installare gli asset in base alle tue esigenze. Alcune decisioni da prendere sono:
- Memorizzazione nella cache: scegli gli asset da installare al primo caricamento. Questi devono includere il codice HTML e gli asset minimi per eseguire il rendering dell'app. Quando utilizzi la pre-cache, ricorda che stai utilizzando lo spazio e la rete del dispositivo. Sii consapevole e responsabile quando scarichi asset e li memorizzi nella cache.
- Memorizza la cache come necessario: viene utilizzato per aggiungere asset alla cache quando vengono richiesti. In genere si tratta di asset che possono cambiare indipendentemente dalla versione dell'app, come immagini o contenuti. Consulta la sezione relativa alla memorizzazione nella cache per conoscere le diverse strategie di memorizzazione nella cache in base alle esigenze.
- API e servizi web: le chiamate API possono essere memorizzate nella cache oppure, anziché memorizzare nella cache le risposte dell'API, puoi archiviare i relativi dati in IndexedDB.
Aggiornamento degli asset
Nel modello di app standard per le app installate nel catalogo di app, quando gli sviluppatori devono aggiornare l'app, pubblicano un nuovo pacchetto. Gli utenti dovranno scaricare di nuovo l'intero pacchetto, anche se la maggior parte degli asset non è stata modificata. Con le PWA, seguendo gli approcci descritti nella sezione precedente, decidi come e quando aggiornare gli asset. Di seguito sono riportate diverse opzioni per l'aggiornamento degli asset:
- Aggiornamento completo: in questo caso, ogni volta che apporti una modifica all'app, anche una minima, il codice scaricherà di nuovo tutti gli asset presenti nella cache.
- Aggiornamento parziale: in questo approccio, crei un metodo per definire quali asset sono stati aggiornati e aggiorni solo quelli, con o senza l'intervento dell'utente.
- Aggiornamento continuo: utilizzando questa tecnica, i tuoi asset verranno controllati e aggiornati automaticamente a ogni utilizzo di PWA individualmente
Dimensioni e durata
Solitamente le app specifiche della piattaforma non hanno a che fare con i limiti di dimensioni; al momento dell'installazione, le app possono avere dimensioni pari o superiori a gigabyte. L'installazione è consentita solo se la capacità del dispositivo è sufficiente. Inoltre, mentre l'app è installata, utilizzerà la quantità totale di spazio di archiviazione a prescindere dall'utilizzo o meno dell'app. Lo spazio di archiviazione viene gestito in modo diverso per le PWA. Il browser archivierà gli asset in base ai criteri che hai definito nella logica della PWA.
I limiti di dimensioni dipendono dal browser. Non è flessibile quanto le app specifiche della piattaforma, ma in genere è sufficiente per la maggior parte delle app web. Puoi trovare le limitazioni specifiche per browser in questo articolo.
I browser possono rimuovere gli asset in base alla pressione dello spazio di archiviazione o dopo alcune settimane di inattività, se l'utente utilizza la PWA nel browser. Su alcune piattaforme, se l'utente installa la PWA, l'eliminazione non avverrà. Se disponibile, il codice può richiedere l'archiviazione permanente attraverso un'API per evitare l'eliminazione.