Nella guida precedente ti ho spiegato cos’è una PWA e come creare una, ora vorrei andare più a fondo negli aspetti tecnici dei requisiti.
In questa pagina trovi la checklist ufficiale di Google, in inglese. Dato che la guida in italiano mancava, ho pensato di tradurre quella originale rendendola anche più digeribile.
Le Progressive Web App (PWA) sono affidabili, veloci, coinvolgenti e scalabili. Ci sono infatti molti dettagli tecnici che possono elevare una PWA dall’essere una app modello base (Baseline Progressive Web App) ad una app complessa (Exemplary Progressive Web App). Una PWA complessa fornisce un’esperienza offline più significativa, interattività molto rapida ed è curata fin nel più piccolo particolare.
Di seguito trovi due checklist, una basilare con i requisiti minimi necessari e un’altra avanzata con le caratteristiche ottimali che una PWA dovrebbe avere.
Checklist per PWA base
Lo strumento Lighthouse è in grado di verificare automaticamente molti elementi di questo elenco e può rivelarsi utile per testare facilmente i siti.
Il sito è servito su HTTPS
Come testare: Usa Lighthouse per verificare che le pagine siano servite su HTTPS.
Come correggere: Implementa il protocollo HTTPS. Puoi controllare su letsencrypt.org per iniziare.
Le pagine hanno design responsive, adatto a tablet e dispositivi mobili
Come testare:
- Usa Lighthouse per verificare che il sito web sia ottimizzato per i dispositivi mobili. Potrebbe essere utile verificare anche manualmente con device a tua disposizione.
- Controlla con il test di ottimizzazione mobile
Come correggere: Cerca di implementare un design responsive o di servire in modo adattivo un sito compatibile con i device mobili.
Tutti gli URL delle app vengono caricati offline
Come testare: Naviga varie pagine della PWA mentre il tuo smartphone è in modalità aereo. Assicurati che l’app presenti alcuni contenuti anche offline. Usa Lighthouse per verificare che l’URL di partenza risponda con status code 200 quando è offline.
Come correggere: Utilizza un service worker.
I metadati per il banner di installazione “Add to Home screen”
Come testare: Usa Lighthouse per verificare che siano tutti rispettati i requisiti per chiedere all’utente di aggiungere la PWA alla schermata Home.
Come correggere: Aggiungi il file Web App Manifest al tuo progetto.
Primo caricamento rapido anche su 3G
Come testare: Usa Lighthouse su un Nexus 5 (o simile) per verificare che il tempo necessario alla pagina per diventare interattiva (time to interactive) sia inferiore ai 10 secondi, per la prima visita su una rete 3G simulata. Questo audit identifica il momento in cui una pagina sembra essere sufficientemente pronta da consentire all’utente di interagire con essa.
Come correggere:
- Esistono molti modi per migliorare le prestazioni.
- Puoi capire meglio le tue prestazioni utilizzando Pagespeed Insights (obiettivo per punteggio > 85) ed il valore SpeedIndex su WebPageTest (mira a < 4000 come prima visualizzazione su Mobile 3G Nexus 5 Chrome).
- Alcune delle migliori best practices riguardano la riduzione degli script da caricare. Assicurati che lo script sia caricato, dove e quando possibile, in modo asincrono usando <script async> e assicurati di evitare blocchi di rendering dovuti a dipendenze CSS.
- È inoltre possibile utilizzare il modello PRPL e strumenti come PageSpeed Module sul server.
Il sito funziona cross-browser
Come testare: Prova il sito in Chrome, Edge, Firefox e Safari
Come correggere: Risolvi i problemi che si verificano durante l’esecuzione dell’applicazione cross-browser
Le transizioni di pagina veloci
Le transizioni da una pagina ad un’altra dovrebbero essere scattanti al tocco dello schermo, anche su una rete lenta. Questa è una caratteristica chiave per ottimizzare le prestazioni percepite.
Come testare: Apri l’app su una rete molto lenta simulata. Ogni volta che tocchi un link/pulsante nell’app, la pagina dovrebbe rispondere immediatamente, tramite:
- Transizione immediata alla schermata successiva e visualizzazione di una schermata di caricamento segnaposto in attesa di contenuti dalla rete.
- Un indicatore di caricamento viene mostrato mentre l’app attende una risposta dalla rete.
Come correggere: Se si utilizza un’applicazione a pagina singola (renderizzata lato client), passare immediatamente l’utente alla pagina successiva e mostrare una skeleton screens (una versione vuota della pagina attualmente in fase di caricamento) e mostrare qualsiasi contenuto come titolo o miniatura già disponibili durante il caricamento del contenuto.
Ogni pagina ha un URL specifico
Come testare: Assicurati che le singole pagine siano collegabili tramite URL e che gli URL siano unici ai fini della condivisibilità sui social media. Verifica che le singole pagine possano essere aperte e accessibili direttamente tramite le nuove finestre del browser.
Come correggere: Se crei un’applicazione a pagina singola, assicurati che il router lato client possa ricostruire la pagina che si attende l’utente partendo da un determinato URL.
Checklist per PWA complessa
Molti di questi controlli devono essere eseguiti manualmente, poiché non sono ancora stati implementati in Lighthouse.
Indicizzabilità e social
Per ulteriori informazioni, consulta la guida social optimization e social discovery.
Il contenuto del sito è indicizzato da Google
Come testare: Utilizza lo strumento Visualizza come Google per visualizzare l’anteprima di come Google vedrà il tuo sito quando viene sottoposto a scansione.
Come correggere: Il sistema di indicizzazione di Google esegue JavaScript ma potrebbe essere necessario risolvere alcuni problemi per rendere accessibile il contenuto. Ad esempio, se stai utilizzando nuove funzionalità del browser come Fetch API, assicurati che non impediscano il funzionamento dell’app nei browser senza supporto.
I metadati di Schema.org sono forniti solo quando appropriati
I metadati di Schema.org possono aiutare a migliorare l’aspetto del tuo sito nei risultati dei motori di ricerca.
Come testare: Usa lo strumento di test per assicurarti che titolo, immagine, descrizione, ecc. siano indicati e disponibili.
Come correggere: Inserisci il markup nel contenuto. Per esempio:
- Un’app per ricette deve avere il markup del tipo Ricetta per le Rich Cards.
- Un’app di notizie dovrebbe avere il markup del tipo NewsArticle per le Rich Cards e/o supporto per AMP.
- Un’app di e-commerce dovrebbe avere il markup del tipo Product per le Rich Cards.
I metadati sociali sono forniti laddove appropriati
Come testare:
- Apri una pagina rappresentativa nel crawler di Facebook e assicurati che sia validata.
- Verifica che i metadati delle Twitter Cards siano presenti (ad esempio <meta name=”twitter:card” content=”summary” />) se ritieni che sia appropriato.
Come correggere: Inserisci il markup Open Graph come consigliato da Twitter.
Gli URL canonici sono forniti quando necessario
Questo è necessario solo se il tuo contenuto è disponibile su più URL.
Come testare:
- Verifica se ci sono pagine identiche su due URL diversi.
- Apri entrambe queste pagine e assicurati che usino il tag <link rel=canonical> nella sezione <head> dell’HTML per indicare ai motori di ricerca la versione canonica.
Come correggere: Aggiungi la tag canonical alla sezione <head> di ogni pagina, indicando il documento sorgente canonico. Vedi la guida di Google per maggiori informazioni.
Le pagine utilizzano le History API
Come testare: Per le app a pagina singola, assicurati che il sito non utilizzi _escaped_fragment_. Per esempio dopo il #! in https://example.com/#!user/26601.
Come correggere: Utilizza le History API invece dell’_escaped_fragment_.
Esperienza utente
Il design del contenuto resta stabile durante il caricamento della pagina
Come testare: Carica varie pagine nella PWA e assicurati che il contenuto o l’interfaccia utente non “salti” mentre la pagina viene caricata.
Come correggere: Assicurati che tutti i contenuti, in particolare le immagini e gli annunci, abbiano una dimensione fissa nel CSS o in linea sull’elemento. Prima di caricare l’immagine, potresti voler mostrare un quadratino grigio o una versione sfocata/piccola (se disponibile) come segnaposto.
Premendo indietro da una pagina di dettaglio si mantiene la posizione di scorrimento sulla pagina di elenco precedente
Come testare: Trova una visualizzazione a lista/elenco nell’app. Scorri verso il basso. Tocca un elemento per accedere alla pagina dei dettagli. Scorri sulla pagina dei dettagli. Premi indietro e assicurati che la vista ad elenco scorra nello stesso punto in cui si trovava prima che il collegamento/pulsante di dettaglio fosse premuto.
Come correggere: Ripristina la posizione di scorrimento negli elenchi quando l’utente preme ‘indietro’. Alcune librerie di routing hanno questa funzione.
Quando selezionate, le aree di input di testo non vengono coperte dalla tastiera sullo schermo
Come testare: Trova una pagina con un’area per input di testo (un form di contatto). Scrolla per posizionare l’arei di input più in basso possibile nello schermo dello smartphone. Tocca l’area di input e verifica che non venga coperta dalla tastiera.
Come correggere: Utilizza funzionalità come Element.scrollIntoView() e Element.scrollIntoViewIfNeeded() per garantire che, quando toccata, l’area di input sia sempre visibile sullo schermo.
Il contenuto è facilmente condivisibile dalla modalità standalone o a schermo intero
Come testare: Assicurati, dalla modalità standalone (dopo aver aggiunto l’app alla schermata iniziale), che sei in grado di condividere il contenuto, se appropriato, dall’interfaccia utente dell’app.
Come correggere: Fornisci pulsanti di condivisione sociale o un pulsante di condivisione generico all’interno dell’interfaccia utente. Se si utilizza un pulsante generico, è possibile copiare direttamente l’URL negli appunti dell’utente quando viene toccato, offrire loro i social network da condividere o provare la nuova Web API Share per l’integrazione con il sistema di condivisione nativo su Android.
Il sito è responsivo su tutte le dimensioni dello schermo del telefono, del tablet e del desktop
Come testare: Visualizza la PWA su schermi piccoli, medi e grandi e assicurati che funzioni in modo ragionevole su tutti.
Come correggere: Consulta la guida ufficiale di Google sull’implementazione di interfacce utente responsive.
Non richiedere eccessivamente di installare l’app
Come testare: Verifica che la PWA non utilizzi un banner interstitial per l’installazione di app quando viene caricata.
Come correggere:
- Dovrebbe esserci un solo banner di installazione presente nell’app, in alto o in basso.
- Dopo che la PWA è stata aggiunta alla schermata iniziale dell’utente, tutti i banner superiore/inferiore devono essere rimossi.
La richiesta di aggiunta alla schermata home viene riconosciuta dal browser
Come testare: Verificare che il browser non visualizzi il banner A2HS (Add To Home Screen) in un momento non opportuno, ad esempio quando l’utente si trova nel mezzo di un flusso che non deve essere interrotto o quando un altro prompt è già visualizzato sullo schermo.
Come correggere:
- Intercettare l’evento beforeinstallprompt e posticiparlo.
- Chrome gestisce quando attivare il prompt, ma in certe situazioni questo potrebbe non essere l’ideale. È possibile posticipare il prompt in un secondo momento nell’utilizzo dell’app. Potrebbe anche aiutare oscurare lo schermo, come consigliato per richiedere le autorizzazioni di seguito.
Prestazioni e tempi di caricamento
Primo caricamento rapido anche su 3G
Come testare: Usa Lighthouse su un Nexus 5 (o simile) per verificare che il tempo per rendere l’app interattiva sia inferiore ai 5 secondi, per la prima visita su una rete 3G simulata (al contrario dell’obiettivo 10s per gli PWA di base )
Come correggere:
- Controlla la sezione prestazioni di WebFundamentals e assicurati di seguire le best practice.
- Puoi capire meglio le tue prestazioni utilizzando Pagespeed Insights (obiettivo per punteggio > 85) ed il valore SpeedIndex su WebPageTest (mira a < 4000 come prima visualizzazione su Mobile 3G Nexus 5 Chrome).
- Alcune delle migliori best practices riguardano la riduzione degli script da caricare. Assicurati che lo script sia caricato, dove e quando possibile, in modo asincrono usando < script async > e assicurati di evitare blocchi di rendering dovuti a dipendenze CSS.
Funzionalità di caching
Il sito utilizza il sistema cache-first
Come testare:
- Imposta l’emulazione di rete sull’impostazione più lenta e sfoglia l’app.
- Quindi, imposta l’emulazione di rete su offline e continua a navigare l’app. L’app non dovrebbe sembrare più veloce quando è offline rispetto a una connessione lenta.
Come correggere: Utilizza le risposte cache-first dove possibile. Esamina anche il set di librerie di service worker che rendono più semplice l’implementazione di questi tipi di modelli.
Il sito informa appropriatamente l’utente quando è offline
Come testare: Emula una rete offline e verifica che la PWA fornisca un’indicazione che l’utente è offline.
Come correggere: Utilizza la Network Information API per mostrare all’utente un’indicazione quando è offline.
Le notifiche push
Questa check list si applica solo se vengono implementate le notifiche push. L’aggiunta di notifiche push non è un requisito per un’applicazione web progressiva avanzata.
Fornire un contesto all’utente su come verranno utilizzate le notifiche
Come testare:
- Visita il sito e trova l’opt-in (l’attivazione) delle notifiche
- Quando viene visualizzata la richiesta di autorizzazione da parte del browser, assicurati che sia stato fornito il contesto per spiegare a cosa il sito richiede l’autorizzazione.
- Se il sito richiede l’autorizzazione al caricamento della pagina, assicurati di fornire in quel momento un contesto molto chiaro per il motivo per cui l’utente deve abilitare le notifiche push.
Come correggere: Consulta la guida per creare flussi di permessi di notifica facili da usare.
L’interfaccia utente che incoraggia gli utenti a attivare le notifiche push non deve essere eccessivamente aggressiva
Come testare: Visita il sito e trova l’opt-in per le notifiche push. Assicurati che, se si ignora la notifica push, non venga richiesta una seconda volta all’interno della stessa sessione.
Come correggere: Se gli utenti dicono di non volere un certo tipo di notifica, non ripetere la replica per almeno alcuni giorni (ad esempio, una settimana).
Il sito oscura lo schermo quando viene visualizzata la richiesta di autorizzazione
Come testare: Visita il sito e trova l’opt-in delle notifiche push. Quando Chrome mostra la richiesta di autorizzazione, assicurati che la pagina “oscuri” (sovrapponendo un overlay scuro) tutto il contenuto non rilevante per spiegare perché il sito vorrebbe inviare notifiche push.
Come correggere: Quando si utilizza Notification.requestPermission oscura lo schermo. Ripristina la visibilità dopo la scelta dell’utente.
Le notifiche push devono essere tempestive, precise e pertinenti
Come testare: Abilita le notifiche push dal sito e assicurati che i casi d’uso delle notifiche push siano:
- Tempestivi – una notifica tempestiva viene visualizzata quando gli utenti lo desiderano e quando è importante per loro.
- Precisi – Una notifica precisa è quella che ha informazioni specifiche su cui è possibile agire immediatamente.
- Rilevanti – Un messaggio rilevante riguarda le persone o i soggetti a cui l’utente importa.
Come correggere: Vedi la guida sulla creazione di ottime notifiche push per un consiglio. Se i tuoi contenuti non sono tempestivi e pertinenti per questo utente, prendi in considerazione l’uso della posta elettronica.
Fornisce controlli per abilitare e disabilitare le notifiche
Come testare: Abilita le notifiche push dal sito. Assicurati che ci sia un posto nel sito che ti permetta di gestire le autorizzazioni di notifica o disabilitarle.
Come correggere: Creare un’interfaccia utente che consenta agli utenti di gestire le proprie preferenze di notifica.
Caratteristiche aggiuntive
L’utente ha effettuato l’accesso su tutti i dispositivi tramite Credential Management API
Questo si applica solo se il tuo sito ha un flusso di login.
Come testare:
- Crea un account per un servizio e assicurati di vedere la finestra di salvataggio della password/account visualizzata. Fai clic su “Salva”.
- Cancella i cookie per il sito (facendo clic sul lucchetto o sulle impostazioni di Chrome) e aggiorna il sito. Assicurati di vedere un raccoglitore di account (ad es. Se ci sono più account salvati) o ti ricollegano automaticamente.
- Esci e aggiorna il sito. Assicurati di vedere il selettore di account.
Come correggere: Segui la guida Credential Management API Integration Guide.
L’utente può pagare facilmente tramite l’interfaccia utente nativa e Payment Request API
Questo controllo si applica solo se il tuo sito accetta pagamenti.
Come testare: Esegui il flusso di pagamento. Invece di compilare un modulo convenzionale, verifica che l’utente sia in grado di pagare facilmente tramite l’interfaccia utente nativa attivata da Payment Request API.
Come correggere: Segui la guida all’integrazione dell’API per richieste di pagamento.
Autore
![Giovanni Sacheli](https://www.evemilano.com/wp-content/uploads/2024/01/sacheli-wmf17_2_sq.jpg)
Commenti |1
Lascia un commentoCiao Giovanni molto utile questa check-list. Sebbene la tecnologia delle PWA sia ancora nuova, si possono fare già diverse cose interessanti. Bravo, bel blog!