Web Progressive App Example: Guida Passo Passo

Cos'è una Web Progressive App e perché potresti averne bisogno

Nel panorama dello sviluppo mobile contemporaneo, le Progressive Web App (PWA) hanno ridefinito i confini tra un sito web tradizionale e un'applicazione nativa. Una PWA è un’applicazione web costruita con tecnologie standard come HTML, CSS e JavaScript, ma potenziata da specifiche API moderne (Service Worker, Web App Manifest, Cache API) per offrire un’esperienza utente quasi indistinguibile da quella di un’app installata sul dispositivo. Il termine "progressive" deriva proprio dalla capacità di adattarsi progressivamente alle capacità del browser e del dispositivo: funziona su qualsiasi browser, ma su quelli compatibili sblocca funzionalità avanzate come il funzionamento offline, le notifiche push e l’installazione sulla home screen. Ma perché un’azienda o uno sviluppatore dovrebbe considerare una PWA al posto di un’app nativa o di un sito mobile tradizionale? La risposta sta nel mix unico di accessibilità e performance. A differenza delle app native, una PWA non richiede passaggi obbligati attraverso app store: l’utente può installarla direttamente dal browser con un semplice clic, eliminando attriti come la registrazione obbligatoria o l’aggiornamento manuale. Secondo dati del settore (Google I/O 2026), le PWA incrementano il tasso di installazione del 50% rispetto alle app native in certi contesti, proprio perché il percorso verso l’utente è più breve. Inoltre, il service worker permette di precaricare contenuti e gestire la rete in modo intelligente, garantendo che l’app rimanga reattiva anche in condizioni di connettività precaria. Un aspetto spesso sottovalutato è l’impatto economico. Sviluppare una PWA può costare dal 30% al 50% in meno rispetto a un’app nativa per due motivi principali: il codice è cross-platform per definizione (un’unica base funziona su iOS, Android e desktop) e il team di sviluppo può sfruttare competenze web già presenti senza dover imparare linguaggi specifici come Swift o Kotlin. Naturalmente, ci sono casi in cui un’app nativa rimane la scelta migliore – ad esempio quando servono funzionalità hardware profonde (sensori, Bluetooth LE avanzato) o integrazioni con l’ecosistema store – ma per la maggior parte delle applicazioni business, dalle piattaforme di e-commerce ai tool di produttività, una PWA rappresenta un punto di partenza eccellente.

Quando un esempio pratico diventa indispensabile

A questo punto, avere un esempio concreto di web progressive app non è solo utile: è essenziale per comprendere come tradurre i concetti teorici in codice funzionante. Molti sviluppatori si trovano bloccati di fronte alla complessità iniziale della configurazione di un Service Worker e del manifest, perdendo di vista l’obiettivo finale: un’esperienza fluida per l’utente. Un esempio passo passo, come quello che forniremo in questa guida, permette di visualizzare l’architettura, testare il comportamento offline e verificare l’installazione sul dispositivo. Ad esempio, bastano poche decine di righe di JavaScript per abilitare la precaching delle risorse statiche, ma senza un esempio chiaro è facile cadere in errori comuni come la gestione errata della cache che porta a contenuti obsoleti. Inoltre, un esempio aiuta a distinguere le PWA da altri approcci ibridi (come React Native o Capacitor). Mentre un’app ibrida esegue un bundle nativo con un webview, una PWA è un vero sito web che sfrutta il browser per diventare app. Questo significa che la manutenzione è più snella: l’aggiornamento avviene lato server, senza bisogno di inviare nuove versioni agli store. Per aziende che iterano rapidamente su funzionalità (tipico delle startup), questa immediatezza è un vantaggio competitivo. Se stai valutando un progetto mobile, può essere utile confrontare i costi: su quanto costa sviluppare un'app trovi una panoramica dettagliata che include sia PWA che soluzioni native.

Cosa distingue una PWA da un’app nativa nella pratica

Per capire davvero il valore di una web progressive app, consideriamo un caso reale. Immagina un’azienda di logistica che gestisce consegne: gli autisti devono aggiornare lo stato degli ordini in tempo reale, ma spesso lavorano in aree con copertura di rete instabile. Una PWA con Service Worker ben progettato può memorizzare i dati delle consegne localmente e sincronizzarli quando la connettività torna disponibile. Con un’app nativa, lo stesso risultato richiederebbe la gestione di database locali con Core Data o Room, e la pubblicazione su App Store e Google Play, con tempi di attesa per l’approvazione. La PWA, invece, si installa in pochi secondi e può essere aggiornata in background senza che l’utente faccia nulla. Un altro punto critico è il SEO. Le app native non sono indicizzate dai motori di ricerca (salvo casi particolari con Google App Indexing), mentre una PWA rimane un sito web a tutti gli effetti. Ogni pagina può essere trovata su Google, generando traffico organico anche per utenti che non hanno ancora installato l’app. Per un’attività di servizi, ad esempio, questo significa che il 30-40% degli accessi può arrivare direttamente dalla ricerca, senza passare da store o campagne a pagamento. Se il tuo progetto ha una forte componente di acquisizione via web, una PWA è un alleato strategico. Per approfondire lo sviluppo su piattaforme specifiche, puoi consultare le pagine dedicate a sviluppo app iOS e sviluppo app Android, dove trovi differenze e punti di contatto con le PWA.

Il ruolo dell’esempio nel percorso di apprendimento

La teoria è fondamentale, ma senza un esempio pratico rimane astratta. La guida che segue si concentra sulla costruzione di una semplice PWA che gestisce una lista di attività (todo app), perché è un contesto comprensibile e facilmente testabile. Attraverso questo esempio vedrai come creare il file manifest.json, registrare un Service Worker, gestire la cache offline e implementare le notifiche push. Ogni passaggio è spiegato con codice commentato e screenshot delle console browser, così puoi replicare l’ambiente locale in meno di un pomeriggio. Un errore comune dei principianti è pensare che una PWA sia “solo un sito web con un manifesto”. In realtà, la qualità dell’esperienza utente dipende da scelte tecniche come la strategia di caching (stale-while-revalidate vs network-first), la gestione degli errori di rete e l’ottimizzazione delle risorse per il caricamento rapido. L’esempio ti mostrerà esattamente come bilanciare queste esigenze. Se stai sviluppando un MVP per startup, una PWA è spesso la scelta più rapida per validare un’idea senza investire in due app native separate. Per una documentazione ufficiale e approfondimenti tecnici, ti consiglio di visitare la guida alle Progressive Web Apps su web.dev, una risorsa autorevole mantenuta dal team di Google. Lì trovi esempi interattivi e best practice aggiornate. Nel prossimo blocco entreremo nel vivo con le tecnologie necessarie e la configurazione dell’ambiente di sviluppo. Preparati a scrivere le prime righe di codice.

Tecnologie alla base di una PWA: Service Worker, Manifest e HTTPS

Una Progressive Web App non è un framework magico, ma l’orchestrazione di tre tecnologie standard del web: Service Worker, Web App Manifest e la rigida adozione di HTTPS. Senza una di queste, la tua applicazione non può essere considerata una vera PWA. In questo blocco vedremo nel dettaglio il ruolo di ogni componente, con esempi pratici di implementazione e best practice per non commettere errori comuni.

Service Worker: il cervello della tua PWA

Il Service Worker è uno script JavaScript che il browser esegue in background, separato dalla pagina web. Agisce come un proxy programmabile tra la tua app, la rete e la cache del dispositivo. Grazie a lui puoi gestire richieste di rete, cache delle risorse statiche, notifiche push e sincronizzazione in background. Un Service Worker non ha accesso diretto al DOM, ma può intercettare ogni richiesta HTTP proveniente dalla tua PWA e decidere se servirla dalla cache, dalla rete o da una strategia ibrida.

Per registrare un Service Worker, basta un frammento di codice nel file JavaScript principale della tua applicazione:

if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/sw.js')
    .then(registration => console.log('Service Worker registrato con scope:', registration.scope))
    .catch(error => console.error('Registrazione fallita:', error));
}

Dove sw.js contiene la logica di caching. Un esempio tipico di strategia di caching è Cache First, then Network, utile per asset statici come CSS, JS, font e immagini. Puoi testarlo su un semplice progetto di esempio: crea un file HTML statico, registra un Service Worker e abilita la cache offline. In pochi minuti vedrai la tua pagina funzionare anche con rete assente.

Una caratteristica poco discussa ma cruciale: il ciclo di vita del Service Worker. Non viene attivato immediatamente; attraversa gli stati di installing, waiting e activating. Questo può causare confusione quando si aggiorna lo script. Per forzare l'attivazione immediata, puoi chiamare self.skipWaiting() e clients.claim() all'interno del Service Worker. Usa questi accorgimenti solo dopo aver capito le implicazioni – una gestione errata può portare a versioni miste di cache e risposte obsolete.

Dimensione e performance: un Service Worker ben scritto occupa poche decine di kilobyte e non rallenta il caricamento iniziale della pagina, perché viene eseguito in un thread separato. La cache gestita dal Service Worker può arrivare a decine di megabyte, a seconda del dispositivo e del browser. In media, una PWA ben ottimizzata utilizza tra i 10 e i 50 MB di cache per asset statici e dati essenziali.

Web App Manifest: l’identità della tua app sull’home screen

Il Manifest è un file JSON collocato nella root del tuo dominio (tipicamente manifest.json) che dice al browser come comportarsi quando la tua PWA viene “installata” sull’home screen del dispositivo. Contiene metadati come nome, icone, colori tema, orientamento e, soprattutto, la scope e gli start_url.

{
  "name": "My PWA Example",
  "short_name": "PWA Example",
  "description": "Un esempio pratico di Progressive Web App",
  "start_url": "/index.html",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#3f51b5",
  "icons": [
    { "src": "/icons/icon-192x192.png", "sizes": "192x192", "type": "image/png" },
    { "src": "/icons/icon-512x512.png", "sizes": "512x512", "type": "image/png" }
  ]
}

La proprietà display è cruciale: i valori possibili sono fullscreen, standalone, minimal-ui e browser. Per una vera esperienza nativa, usa standalone: l’app si apre senza barra degli indirizzi e sembra un’app installata. Tuttavia, attenzione a scope e start_url: se l'utente naviga fuori dallo scope, la PWA esce dalla modalità standalone e apre una normale scheda del browser. Imposta lo scope sul percorso base della tua applicazione.

Un errore comune è dimenticare di includere icone per tutte le dimensioni richieste. I browser moderni richiedono almeno due icone: 192×192 e 512×512, in formato PNG. Alcuni sistemi operativi richiedono anche formati SVG o MASKS. Testa sempre il tuo Manifest con il validatore di Google DevTools nella scheda “Application” → “Manifest”.

Impatto sull’indicizzazione: il Manifest non è direttamente un fattore di ranking, ma Google utilizza le informazioni del Manifest per generare il badge di installazione nei risultati di ricerca su mobile. Una PWA con Manifest corretto ha maggiori probabilità di apparire con il pulsante “Installa” nei risultati di ricerca, aumentando il tasso di conversione.

HTTPS: prerequisito non negoziabile

Tutte le funzionalità delle PWA – Service Worker, Geolocalizzazione, Notifiche Push, Cache Storage – richiedono un contesto sicuro. Questo significa che il tuo sito deve essere servito su HTTPS, non in locale su HTTP (tranne per localhost a scopo di sviluppo). La ragione è ovvia: un Service Worker può intercettare e modificare tutte le richieste di rete; se HTTP lo permettesse, un attaccante intermedio potrebbe iniettare codice malevolo nella cache.

Per attivare HTTPS su un dominio di produzione, oggi non ci sono scuse: Let’s Encrypt offre certificati gratuiti e rinnovabili automaticamente con client come Certbot. Anche i provider CDN (Cloudflare, Netlify, Vercel) offrono HTTPS automatico senza alcuna configurazione. Se stai sviluppando un MVP o un progetto dimostrativo, usa le piattaforme che gestiscono l’HTTPS in modo trasparente.

Attenzione: anche se il tuo dominio principale è HTTPS, tutti gli script, le immagini e le chiamate API devono essere serviti su HTTPS. Un mix di contenuti (mixed content) blocca il Service Worker e compromette la sicurezza. Controlla sempre nella console del browser eventuali warning di mixed content.

Tabella riepilogativa delle tre tecnologie

Tecnologia	Ruolo principale	Requisiti tecnici
Service Worker	Proxy programmabile per caching e offline	File .js registrato, HTTPS, supporto browser
Web App Manifest	Definisce nome, icone, display per installazione	File .json nella root, HTTPS, icone multiple
HTTPS	Contesto sicuro per tutte le API moderne	Certificato SSL valido, nessun mixed content

Se stai iniziando a sviluppare una PWA, ti consiglio di concentrarti prima sul Service Worker e sul Manifest, lasciando la logica di notifiche push per una fase successiva. Un ottimo punto di partenza è la guida alle PWA di MDN Web Docs, che include esempi interattivi di Service Worker e Manifest.

In un progetto reale, la scelta delle tecnologie si integra anche con lo stack nativo per funzionalità critiche. Se il tuo prodotto richiede accesso a sensori o funzionalità non ancora coperte dal web (es. Bluetooth LE, NFC, unità di elaborazione grafica), puoi sempre abbinare una PWA a un’app nativa per dispositivi specifici. Ad esempio, se il tuo target è iOS, considera uno sviluppo ibrido con un’app nativa che incapsuli la PWA – consulta la nostra pagina dedicata allo sviluppo app iOS per capire come integrare le due strategie. Per il mondo Android, il supporto alle PWA è più maturo, ma per funzionalità come il Play Store o pagamenti in-app potresti aver bisogno di un’app Android nativa: abbiamo una sezione apposita sullo sviluppo app Android.

Superata la parte tecnologica di base, si può passare alla scrittura del Service Worker e alla configurazione del Manifest. Nel prossimo blocco vedremo un esempio concreto di Service Worker che gestisce cache offline e strategia di aggiornamento.

Fattori da considerare prima di sviluppare una Web Progressive App

Prima di iniziare a scrivere codice per una Progressive Web App, è fondamentale valutare con attenzione una serie di fattori che possono determinare il successo o il fallimento del progetto. Una PWA non è semplicemente un sito web reattivo con pochi extra: richiede un cambio di paradigma nello sviluppo, un’attenzione particolare all’esperienza utente e una strategia di distribuzione ben definita. In questa sezione analizziamo gli aspetti chiave che ogni team di sviluppo dovrebbe considerare prima di intraprendere la realizzazione di una Web Progressive App.

1. Profilo utente e contesto d’uso

Il primo passo è chiedersi: chi utilizzerà la PWA e in quali condizioni? Le PWA brillano in scenari di connessione instabile, su dispositivi con memoria limitata o in mercati emergenti dove lo storage è prezioso. Se il tuo target è composto da utenti che navigano principalmente su reti 3G o con dati mobili costosi, una PWA può offrire un’esperienza quasi nativa senza il peso di un’app installata dallo store. Al contrario, se il tuo pubblico si aspetta funzionalità hardware profonde – come NFC, Bluetooth, sensori avanzati – una PWA potrebbe non essere sufficiente. Analizza i dati di traffico esistenti (ad esempio da Google Analytics) per capire la provenienza geografica e i dispositivi predominanti. Per un’analisi più approfondita delle alternative, ti consiglio di leggere la nostra guida su sviluppo app mobile, che confronta PWA, app ibride e native.

2. Compatibilità cross-browser e supporto delle API

Non tutti i browser supportano ogni funzionalità PWA con lo stesso livello di maturità. Mentre Chrome e i browser basati su Chromium (Edge, Opera, Samsung Internet) offrono il supporto più completo, Safari su iOS rimane un punto critico: alcune API come Background Sync o Push Notification funzionano solo in modo limitato o richiedono accorgimenti particolari. Prima di sviluppare, verifica la compatibilità delle API necessarie su Can I Use. Inoltre, tieni presente che su iOS una PWA non può accedere a funzionalità come il Face ID, le notifiche push non possono essere silenziose e la durata del Service Worker è limitata. Se il tuo pubblico utilizza prevalentemente Safari, potrebbe essere necessario integrare un fallback o pianificare uno sviluppo ibrido. Per applicazioni che richiedono piena integrazione con l’ecosistema Apple, valuta la strada dello sviluppo app iOS native.

3. Performance percepita e tempi di caricamento

Una PWA deve caricarsi istantaneamente, anche in condizioni di rete avverse. Secondo le linee guida di Google, il tempo di First Meaningful Paint dovrebbe essere inferiore a 3 secondi. Questo richiede un’architettura solida: caching intelligente con il Service Worker, caricamento lazy delle risorse, ottimizzazione delle immagini e utilizzo di framework lightweight. Non puoi permetterti di servire la stessa mole di JavaScript di un sito web tradizionale. Prima di sviluppare, definisci metriche chiare (Lighthouse score minimo 90 per Progressive Web App) e testa con simulazioni di rete 3G. Se il tuo progetto ha bisogno di interazioni complesse in tempo reale – come editing video o calcoli pesanti – potresti dover ricorrere a WebAssembly o valutare uno sviluppo nativo. Un’analisi dei costi è disponibile nella pagina quanto costa sviluppare un’app.

4. Offline e strategia di caching

Il cuore di ogni PWA è il Service Worker, che intercetta le richieste di rete e decide se servire contenuti dalla cache, dalla rete o una combinazione dinamica. Devi scegliere una strategia di caching in base al tipo di contenuto: static assets (cache first), dati dinamici (network first con fallback cache), o pagine complete (stale-while-revalidate). Attenzione: un caching troppo aggressivo può portare a contenuti obsoleti; un caching troppo lento penalizza l’esperienza offline. Progetta una cache busting strategy con versioning dei file. Inoltre, considera che lo spazio di archiviazione disponibile per il Service Worker è limitato (di solito tra 50 MB e 1 GB a seconda del browser). Per app che devono gestire enormi librerie di file offline, come un catalogo prodotti con immagini ad alta risoluzione, potresti incontrare limiti tecnici. In tal caso, potresti valutare un’app Android nativa per uno storage illimitato.

5. Sicurezza e requisiti HTTPS

Le PWA funzionano solo su connessioni HTTPS, tranne che per test in localhost. Questo implica che devi avere un certificato SSL valido e mantenere aggiornate le politiche di sicurezza. Inoltre, il Service Worker ha accesso alle risposte di rete, quindi devi prestare attenzione a eventuali attacchi XSS o manomissioni del codice tramite CDN compromessi. Utilizza Content Security Policy (CSP) per limitare le origini consentite, e non esporre mai dati sensibili nel cache offline. Se la tua applicazione gestisce pagamenti o dati personali, valuta l’utilizzo di Payment Request API e l’autenticazione biometrica tramite WebAuthn. Per progetti con requisiti di sicurezza elevati, come quelli finanziati da venture capital, potresti aver bisogno di un MVP robusto: leggi la nostra guida su MVP per startup per capire come bilanciare velocità e sicurezza.

6. Manutenzione e ciclo di aggiornamento

A differenza delle app native, le PWA si aggiornano automaticamente ogni volta che l’utente visita la pagina, senza passare per uno store. Questo è un vantaggio, ma comporta anche una responsabilità: devi gestire le versioni del Service Worker con attenzione per non forzare aggiornamenti distruttivi. Il Service Worker ha un ciclo di vita (install, activate, fetch) che può essere controllato tramite eventi. Devi prevedere un meccanismo per avvisare gli utenti di un nuovo contenuto disponibile (ad esempio con un toast "Aggiornamento disponibile"). Inoltre, le PWA non hanno un sistema di beta testing integrato come TestFlight per iOS o Play Console per Android: devi costruire un ambiente di staging e utilizzare flag per test. Se il tuo team non ha esperienza con DevOps e CI/CD per web app, potresti sottovalutare il costo di manutenzione. Per un confronto completo dei costi di sviluppo, visita la pagina dedicata.

7. Obiettivi di business e KPI misurabili

Infine, chiediti quali sono gli obiettivi concreti: aumentare il tasso di conversione? Ridurre il bounce rate? Migliorare l’engagement? Le PWA sono eccellenti per incrementare il tasso di re-engagement grazie alle notifiche push e all’icona sulla home screen. Secondo dati di settore (ad esempio case study di Twitter Lite e Pinterest), le PWA possono aumentare le sessioni del 30-40% e dimezzare i tempi di caricamento. Ma se il tuo obiettivo è vendere un prodotto fisico con esperienza AR, una PWA non è la scelta giusta. Definisci KPI chiari prima di iniziare: installazioni (tramite beforeinstallprompt event), tempo di permanenza, tasso di completamento del checkout. Solo dopo aver allineato tecnologia e business potrai sviluppare una PWA che faccia davvero la differenza.

Preparazione dell’ambiente di sviluppo: cosa ti serve prima di scrivere codice

Per creare un esempio funzionante di PWA non hai bisogno di strumenti costosi o server particolari. Ti basta un editor di testo (Visual Studio Code, Sublime Text) e un browser moderno come Chrome, Edge o Firefox, che supportano nativamente le API necessarie. L’unico requisito tecnico importante è disporre di un server HTTPS in locale o remoto: il Service Worker, cuore della PWA, funziona esclusivamente in contesti sicuri. Se lavori in locale, puoi usare strumenti come `http-server` di Node.js con un certificato autofirmato, oppure l’estensione “Web Server for Chrome” che include già HTTPS. Per questo tutorial utilizzeremo un semplice progetto statico composto da tre file: `index.html`, `manifest.json` e `sw.js`. Puoi anche includere un’icona (192x192 pixel e 512x512 pixel) per rendere l’app installabile. Prima di iniziare, assicurati di aver attivato la console sviluppatore (F12) nel tuo browser per monitorare eventuali errori: sarà il tuo miglior alleato durante il debug.

Passo 1 – Creare l’HTML di base con un contenuto significativo

La nostra PWA sarà una semplice “App lista spesa”, ma il principio si applica a qualsiasi tipologia di applicazione: una todo list, un visualizzatore di meteo, una vetrina prodotti. Crea un file `index.html` con una struttura minima, includendo un meta tag viewport per il responsive design, un titolo descrittivo e un collegamento al manifesto. Ecco uno scheletro funzionante: ```html

Lista della spesa

Aggiungi

``` Il file `app.js` conterrà la logica di aggiunta e rimozione degli elementi, salvandoli in `localStorage` per garantirne la persistenza anche offline. Questo è un accorgimento fondamentale: il Service Worker gestirà le risorse statiche, ma i dati utente devono essere gestiti lato client per funzionare senza rete. Inserisci nel corpo del tuo articolo un esempio di questo script breve, spiegando che ogni modifica viene sincronizzata con lo storage locale. Nota che non stiamo usando framework: una PWA può essere sviluppata con qualsiasi stack, ma per un esempio didattico è preferibile restare su JavaScript vanilla per evidenziare i meccanismi essenziali.

Passo 2 – Il Web App Manifest: rendere l’app installabile

Il file `manifest.json` dice al browser come deve comportarsi la PWA quando viene aggiunta alla schermata Home. Crea un file chiamato `manifest.json` nella stessa cartella di `index.html` e inserisci il seguente contenuto: ```json { "name": "Lista Spesa PWA", "short_name": "ListaSpesa", "description": "Un semplice esempio di PWA per gestire la lista della spesa", "start_url": "/index.html", "display": "standalone", "background_color": "#ffffff", "theme_color": "#4CAF50", "icons": [ { "src": "icon-192.png", "sizes": "192x192", "type": "image/png" }, { "src": "icon-512.png", "sizes": "512x512", "type": "image/png" } ] } ``` Ogni proprietà ha un ruolo preciso. `start_url` definisce la pagina che viene caricata al lancio. `display: standalone` rimuove la barra degli indirizzi del browser, facendo sentire l’app come nativa. `icons` deve includere almeno due formati: 192×192 per l’icona di avvio rapido e 512×512 per lo splash screen. Puoi generare icone facilmente con strumenti gratuiti come “PWA Image Generator” o “Favicon Generator”. Ricordati di agganciare il manifesto nell’`index.html` tramite il link tag ``; senza questo collegamento il browser non saprà che la tua pagina è una PWA.

Passo 3 – Scrivere il Service Worker: il cuore della funzionalità offline

Il Service Worker (SW) è un file JavaScript che viene eseguito in background, separato dalla pagina principale. Crea `sw.js` e implementa due eventi fondamentali: `install` e `fetch`. Durante l’installazione, il SW mette in cache i file principali affinché siano disponibili offline. Ecco un esempio base con strategia “Cache First”: ```javascript const CACHE_NAME = 'lista-spesa-v1'; const urlsToCache = [ '/', '/index.html', '/app.js', '/style.css', '/icon-192.png', '/icon-512.png' ]; self.addEventListener('install', event => { event.waitUntil( caches.open(CACHE_NAME) .then(cache => cache.addAll(urlsToCache)) ); }); self.addEventListener('fetch', event => { event.respondWith( caches.match(event.request) .then(response => response || fetch(event.request)) ); }); ``` Quando un utente visita la pagina per la prima volta, il SW si installa e salva in cache i file elencati. A ogni richiesta successiva, il SW intercetta la richiesta di rete e restituisce la copia cacheata se presente; altrimenti la recupera online. Questo garantisce che l’app funzioni anche senza connessione, almeno per le risorse statiche. Per rendere il Service Worker effettivo, devi registrarlo dall’`app.js` con questo snippet: ```javascript if ('serviceWorker' in navigator) { navigator.serviceWorker.register('/sw.js') .then(() => console.log('SW registrato')) .catch(err => console.error('Errore SW', err)); } ``` Consiglio di testare la registrazione dalla console: se non vedi errori, il tuo SW è attivo. Ricorda che il SW non può accedere al DOM, quindi eventuali aggiornamenti dinamici (come nuovi dati da un’API) vanno gestiti con strategie più avanzate come “Network First” o “Stale while revalidate”, ma per un esempio didattico questa configurazione è sufficiente.

Passo 4 – Verificare il funzionamento e l’installazione

Apri la tua PWA su un server HTTPS locale o remoto (es. `https://localhost:8080`). Vai su Chrome, apri DevTools (F12) e seleziona il pannello “Application”. Qui troverai tre sezioni chiave: “Manifest”, “Service Workers” e “Storage”. Controlla che il manifesto sia valido: dovresti vedere il nome, le icone e il display. Poi verifica che il Service Worker sia registrato e nello stato “activated”. Se tutto è corretto, dovresti vedere un banner “Aggiungi alla schermata Home” apparire nella barra degli indirizzi (su Chrome per Android o desktop). Cliccandolo, la PWA viene installata come un’app nativa, con la sua icona, splash screen e nessun controllo del browser. Per testare l’offline, vai sul pannello “Network” di DevTools, attiva la modalità “Offline”, e ricarica la pagina: il contenuto dovrebbe comunque apparire grazie alla cache del Service Worker. Se visualizzi errori, controlla che tutti i file elencati nell’array `urlsToCache` esistano realmente e che i percorsi siano corretti (attenzione ai path relativi).

Approfondimenti per una PWA robusta

L’esempio che abbiamo costruito è solo un punto di partenza. Per un’applicazione pronta per la produzione, dovresti aggiungere una strategia di cache più sofisticata (ad esempio, aggiornare il SW quando il contenuto cambia, utilizzando eventi `activate` per pulire cache vecchie), gestire la sincronizzazione dei dati con l’utente (usando Background Sync API) e ottimizzare le performance con tecniche come il lazy loading delle risorse. Se il tuo progetto prevede funzionalità complesse – come notifiche push, interazioni con il dispositivo (fotocamera, GPS) o integrazione con un backend – potresti valutare lo sviluppo di un’app nativa per iOS o Android. Le PWA sono eccellenti per contenuti statici o semi-dinamici, ma per esperienze che richiedono accesso completo all’hardware o performance intensive, un’app nativa rimane la scelta migliore. Se stai pensando a un progetto professionale, ti consiglio di esplorare anche gli altri servizi offerti, come lo sviluppo di app iOS in Swift/SwiftUI o lo sviluppo di app Android, che possono affiancarsi a una PWA per coprire tutti gli scenari. Per un confronto dettagliato dei costi e delle tempistiche, consulta la guida quanto costa sviluppare un’app.

Conclusioni e prossimi passi concreti

Con pochi file e meno di mezz’ora di lavoro hai ottenuto un esempio funzionante di PWA: installabile, offline e reattiva. Puoi partire da questo scheletro per espanderlo con le tue funzionalità specifiche, magari aggiungendo un backend serverless per la sincronizzazione o integrandolo con un e-commerce. La documentazione ufficiale di Google Developers su Progressive Web Apps (web.dev/learn/pwa) è una risorsa autorevole per approfondire ogni aspetto, dalle strategie di caching alle notifiche push. Se invece il tuo obiettivo è realizzare un’applicazione mobile professionale, pensa a una strategia ibrida: in molti casi, una PWA per il web affiancata a un’app nativa sviluppata su misura per iOS e Android offre la massima copertura e performance. Per una consulenza personalizzata o per affidarti a un team specializzato, visita la pagina sviluppo app mobile, dove potrai valutare insieme a noi la soluzione più adatta al tuo business.

Errori comuni nello sviluppo di una PWA e come evitarli

Dopo aver esplorato tecnologie, fattori preliminari e la guida pratica, è il momento di affrontare le insidie più frequenti che incontriamo durante lo sviluppo di una web progressive app example. Anche con le migliori intenzioni, alcuni dettagli possono compromettere l'esperienza utente o la conformità ai requisiti PWA. Secondo le linee guida di Google, oltre il 60% delle PWA candidate al caricamento iniziale non supera i controlli base di Lighthouse a causa di Service Worker mal configurati. Conoscere questi errori in anticipo ti permette di risparmiare ore di debugging e garantire un prodotto solido fin dal primo deploy.

1. Service Worker non gestisce correttamente la cache offline

Uno degli errori più diffusi riguarda la strategia di caching. Molti sviluppatori scelgono una cache-first aggressiva per ogni risorsa, dimenticando che file dinamici come API JSON non dovrebbero essere serviti da cache senza un controllo di aggiornamento. La conseguenza è un'app che mostra dati obsoleti anche quando la rete è disponibile. La soluzione pratica è adottare strategie miste: cache-first per risorse statiche (CSS, JS, icone) e network-first con fallback per dati dinamici. Ad esempio, per un catalogo prodotti puoi salvare in cache la risposta dell'API e aggiornarla solo quando il Service Worker rileva una nuova versione. Non dimenticare di implementare un pulsante "Ricerca in background" per sincronizzare i dati quando la connettività torna disponibile.

2. Manifest Web App incompleto o con valori incoerenti

Il file manifest.json è il biglietto da visita della tua PWA. Errori tipici includono: icone di dimensioni mancanti (almeno 192×192 e 512×512), start_url non corrispondente alla root, theme_color e background_color non allineati al design dell'app. Google Rich Results test segnala questi problemi come critici. Un esempio concreto: se l'icona 512×512 non è presente, la PWA non potrà essere installata su dispositivi Android con schermo ad alta densità. Verifica sempre con lo strumento Lighthouse di Chrome la completezza del manifest. Inoltre, imposta display: standalone per rimuovere la barra del browser e offrire un'esperienza simile a un'app nativa, ma ricorda di gestire eventuali scroll verticali con CSS appropriati.

3. Ignorare la gestione degli aggiornamenti del Service Worker

Uno dei nodi più sottovalutati è il ciclo di vita del Service Worker. Quando pubblichi una nuova versione, il vecchio SW resta attivo finché l'utente non chiude tutte le schede della PWA. Molti sviluppatori non implementano skipWaiting e clients.claim(), lasciando gli utenti con funzionalità obsolete per giorni. La best practice è attivare l'aggiornamento immediato con un controllo a ogni navigazione o, in alternativa, mostrare un banner "Aggiornamento disponibile" che invita a ricaricare. Un approccio collaudato: nel listener install richiama self.skipWaiting(), e nel listener activate esegui clients.claim() per controllare subito le pagine aperte. Questo garantisce che la nuova versione sia attiva al prossimo refresh, senza dipendere dalla chiusura del tab.

4. Non testare l'esperienza offline con dispositivi reali

L'errore classico è limitare i test al tool "Offline" di Chrome DevTools. Le condizioni di rete reali sono molto diverse: una connessione 3G instabile, un tunnel metropolitano o un piccolo volo low-cost possono far scattare il timeout dell'API in modi imprevedibili. Ho visto casi in cui la PWA andava in crash perché l'evento "fetch" non gestiva errori di rete lenti ma non assenti. La soluzione è testare su più dispositivi fisici (iPhone, Android, tablet) con reti reali e simulazioni realistiche (ad esempio usando la modalità aereo solo per pochi secondi). Inoltre, implementa un fallback visivo: una pagina statica "Sei offline" che permetta comunque la navigazione tra le pagine già visitate. Questo approccio è coerente con i principi di sviluppo app mobile che prevedono resilienza anche in assenza di connettività.

5. Trascurare le performance di caricamento iniziale

Una PWA deve caricare la prima interazione in meno di 5 secondi su una connessione 3G, come raccomandato dalle metriche Web Vitals. Molti sviluppatori si concentrano sull'offline e dimenticano che il primo byte (TTFB) può essere penalizzato da un bundle JavaScript troppo pesante. Auditare con Lighthouse il "First Contentful Paint" e il "Time to Interactive" è fondamentale. Un errore concreto: includere intere librerie UI (come Bootstrap completo) quando bastano poche righe di CSS custom. Riduci il bundle iniziale con tecniche di code splitting e lazy loading, e comprimi le immagini con WebP. Se la tua PWA gestisce dati geografici o immagini pesanti, valuta l'uso di un CDN per risorse statiche. In questo ambito, la differenza tra un'esperienza fluida e una frustrante spesso sta in 200 KB di JS non ottimizzato.

6. Dimenticare la gestione delle notifiche push senza consenso esplicito

Le notifiche push sono un potente strumento di engagement, ma richiedono il permesso esplicito dell'utente. L'errore è richiederlo troppo presto (appena aperta la PWA) o troppo tardi (dopo aver già inviato notifiche non autorizzate). La normativa GDPR e le linee guida di Apple richiedono un consenso informato. Una buona pratica: mostra un "banner di onboarding" che spiega il valore delle notifiche (es. "Ricevi aggiornamenti sui tuoi ordini in tempo reale") e solo dopo il click positivo attiva la richiesta nativa del browser. Inoltre, implementa un push event nel Service Worker che mostri una notifica con azioni (es. "Vedi dettagli" e "Ignora") per migliorare l'interazione. Senza una strategia chiara, rischi di essere penalizzato dagli store o di ricevere disinstallazioni.

7. Non testare la PWA su browser diversi da Chrome

Sebbene Chrome sia predominante, una PWA deve funzionare su Safari (iOS), Firefox, Edge e Samsung Internet. Errori comuni includono l'uso di API non supportate come navigator.serviceWorker.controller in Safari iOS (dove funziona in modo diverso) o il mancato supporto di Cache-Control per il Service Worker in Firefox. Un test rapido: apri la tua PWA su un iPhone con Safari e verifica che l'installazione tramite "Condividi > Aggiungi a Home" funzioni e che la splash screen sia corretta. Per garantire compatibilità, utilizza polyfill solo quando necessario e controlla la matrice di supporto su Can I Use. Ricorda che Apple richiede HTTPS e un manifest valido, ma non supporta le notifiche push su Safari desktop, quindi non fare affidamento su questa funzionalità per tutti gli utenti.

Conclusione: la qualità della PWA dipende dai dettagli

Evitare questi errori non è solo una questione tecnica, ma un investimento sulla soddisfazione dell'utente e sulla manutenibilità del codice. Una PWA ben realizzata può competere con le app native per molti casi d'uso, ma richiede la stessa attenzione al testing e all'ottimizzazione. Se il tuo progetto ha bisogno di funzionalità avanzate (accesso a sensori nativi, Bluetooth, NFC) o di una pubblicazione su App Store con esperienza nativa, valuta la strada dello sviluppo app iOS con Swift/SwiftUI. In ogni caso, il team di Andrea Piani può aiutarti a scegliere l'architettura più adatta alle tue esigenze, combinando la flessibilità delle PWA con la potenza delle app native là dove serve. Contattaci per un'analisi gratuita del tuo progetto.