---
term: 'PWA (Progressive Web App)'
seoTitle: 'PWA (Progressive Web App): service worker, offline e push'
headline: 'Che cos''è una PWA (Progressive Web App)?'
slug: pwa
category: frontend-web
shortDefinition: 'Una PWA è una web app che usa service worker, un manifest e HTTPS per essere installabile, funzionare offline e ricevere notifiche push.'
relatedTerms:
  - push-notifications-apns-fcm
  - cross-platform-development
  - ssr-vs-csr-vs-ssg
  - baas-vs-custom-backend
contrastsWith:
  - cross-platform-development
aboutTerms:
  - 'Service Worker'
  - 'Web App Manifest'
  - 'Offline Caching'
faq:
  - question: 'Che cos''è una PWA?'
    answer: 'Un''app costruita con le tecnologie web standard che sfrutta le capacità moderne del browser per comportarsi come un''app installata – icona nella schermata iniziale, finestra autonoma, funzionamento offline e notifiche push – il tutto da un''unica codebase distribuita via web. Il termine è stato coniato da Alex Russell e Frances Berriman nel 2015.'
  - question: 'Che cosa rende un''app una PWA?'
    answer: 'Tre elementi che lavorano insieme: un service worker (uno script in background che mette in cache gli asset e rende possibili l''uso offline e il push), un web app manifest (metadati JSON che la rendono installabile) e HTTPS (i service worker si rifiutano di girare fuori da un contesto sicuro). Il criterio pratico: installabile e affidabile, qualunque sia lo stato della rete.'
  - question: 'Che cos''è un service worker?'
    answer: 'Un file JavaScript che gira in background su un thread proprio e fa da proxy di rete tra l''app e la rete. Intercetta le richieste e le serve dalla cache o dalla rete – è ciò che rende possibili l''uso offline, la sincronizzazione in background e la ricezione di messaggi push mentre l''app è chiusa.'
  - question: 'PWA o app nativa: qual è la scelta migliore?'
    answer: 'Una PWA è più veloce ed economica da costruire, sta in un''unica codebase, si aggiorna all''istante, non ha bisogno di uno store ed è indicizzabile dai motori di ricerca. Un''app nativa ottiene accesso completo all''hardware, la UX più fluida, un push più affidabile e la presenza nello store. Conviene il nativo per grafica pesante o integrazione profonda con il dispositivo; la PWA per la copertura e la velocità di arrivo sul mercato.'
  - question: 'Qual è la differenza tra una PWA e un sito responsive?'
    answer: 'Un sito responsive si limita ad adattare il layout alla dimensione dello schermo e ha bisogno di una connessione. Una PWA aggiunge installabilità, cache offline e notifiche push. Ogni PWA è responsive, ma un sito responsive diventa una PWA solo quando aggiunge un service worker e un manifest.'
  - question: 'Le PWA possono inviare notifiche push?'
    answer: 'Possono ricevere web push tramite le API Push e Notification, ma il client si limita a sottoscrivere – a inviare davvero è un backend. Il supporto su iOS è arrivato con la versione 16.4, e solo quando la PWA è installata nella schermata Home: il web push raggiunge quindi un pubblico più ristretto del push nativo.'
  - question: 'Le PWA funzionano offline?'
    answer: 'Sì – il service worker mette in cache asset e dati e li serve quando la rete sparisce. Le strategie comuni sono cache-first per gli asset statici, network-first per i dati freschi e stale-while-revalidate per una visualizzazione immediata con aggiornamento in background. Le scritture fatte offline vanno in coda e si sincronizzano al ritorno della connessione.'
  - question: 'Si può pubblicare una PWA in uno store?'
    answer: 'In parte. Lo store di Android accetta le PWA impacchettate come trusted web activity, e alcuni store desktop le trattano come app a pieno titolo. L''App Store di Apple, nei fatti, no – le PWA che sono solo siti reimpacchettati vengono rifiutate regolarmente – ed è parte del motivo per cui iOS resta la piattaforma più difficile per le PWA.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'What is a progressive web app? — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/What_is_a_progressive_web_app'
  - name: 'Service Worker API — MDN Web Docs'
    url: 'https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API'
  - name: 'Web App Manifest — W3C'
    url: 'https://www.w3.org/TR/appmanifest/'
  - name: 'Progressive Web Apps: Escaping Tabs Without Losing Our Soul (Russell, 2015)'
    url: 'https://infrequently.org/2015/06/progressive-apps-escaping-tabs-without-losing-our-soul/'
  - name: 'Progressive web app — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Progressive_web_app'
cta:
  title: 'Il backend sotto la tua PWA'
  text: 'Il service worker mette in cache; Back4app è la fonte di verità – autenticazione, dati sincronizzati e il server che invia davvero le tue notifiche web push, un solo backend per PWA, web e nativo.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-23'
translationKey: progressive-web-app-pwa
---

**Una PWA è una web app che usa service worker, un manifest e HTTPS per essere installabile, funzionare offline e ricevere notifiche push.** Il termine, coniato da Alex Russell e Frances Berriman nel 2015, indica ciò che colma la distanza tra un sito web e un'app installata senza uscire dal web: un'unica codebase, un'icona nella schermata iniziale, una finestra autonoma e uno schermo che continua a funzionare quando il treno entra in galleria. La prospettiva che questo glossario aggiunge, e che le guide frontend saltano: **una PWA resta un client** – il service worker mette in cache, ma la fonte di verità è il [backend](/glossary/it/baas-vs-backend-personalizzato/).

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| I tre pilastri | Service worker · web app manifest · HTTPS |
| Che cosa aggiunge | Installabile · utilizzabile offline · pronta per il push – su un'unica codebase |
| vs. un sito responsive | Aggiunge service worker + manifest; il solo layout non fa una PWA |
| vs. il nativo | Copertura e velocità vs. accesso all'hardware e presenza nello store |
| La verità lato backend | La cache del SW è uno specchio; l'[API/BaaS](/glossary/it/baas-vs-backend-personalizzato/) è la fonte autorevole |

## I tre pilastri, e il backend dietro di loro

**JavaScript:**

```javascript
// JavaScript — the PWA's three pillars + the backend behind them
// 1 · Service worker: caches the shell, buffers writes when offline
navigator.serviceWorker.register('/sw.js');

// 2 · Manifest (public/manifest.json) makes it installable:
//    { "name": "Notes", "display": "standalone", "start_url": "/", "icons": [...] }

// 3 · HTTPS is required — service workers refuse to run otherwise.

// The catch: the SW cache is a MIRROR, not the source of truth.
// saveEventually() stores the write offline and sends it when back online:
const note = new Parse.Object('Note').set('text', draft);
await note.saveEventually(); // the BaaS is authoritative; the cache was a buffer
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK (Flutter web compiles to a PWA)
// The service worker caches the app shell; data still lives on the backend.
final note = ParseObject('Note')..set('text', draft);
await note.save();
// Offline-first pattern: write locally, queue, and sync when connectivity
// returns — the API/BaaS is the source of truth, the cache is a local mirror.
// Push notifications need a BACKEND to send them; the client only subscribes.
```

**Swift:**

```swift
// Swift — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
var note = Note()
note.text = draft
_ = try await note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs) both need a backend to SEND them.
```

**Kotlin:**

```kotlin
// Kotlin — a native shell can host a PWA/WebView; the backend is shared
// The point of parity: whatever the client (PWA, native, web), the
// source of truth is the same backend API.
val note = ParseObject("Note")
note.put("text", draft)
note.save()
// Offline-first: cache locally, sync when online — the API is authoritative.
// Web push (PWA) and native push (APNs/FCM) both need a backend to SEND them.
```

Un **service worker** è uno script in background che si colloca tra l'app e la rete come un proxy – mette in cache la shell e la serve offline; un **web app manifest** è un file di metadati JSON (nome, icone, `display: standalone`, URL di avvio) che rende l'app installabile; e **HTTPS** è obbligatorio, perché i service worker si rifiutano di girare fuori da un contesto sicuro. Questi tre elementi costituiscono la facciata dell'app. Il `save()` nelle schede di codice mostra ciò che c'è dietro: la cache è uno *specchio*, e quando la rete torna la scrittura si sincronizza con il backend autorevole.

## Come una PWA serve una pagina offline

```mermaid
flowchart LR
  accTitle: Un service worker che fa da intermediario tra una PWA e il suo backend
  accDescr: Una richiesta della progressive web app passa dal service worker, che restituisce una risposta dalla cache per l'uso offline oppure la recupera dalla rete. Le letture e le scritture di dati arrivano infine all'API del backend, che è la fonte di verità; le scritture fatte offline vengono messe in coda nella cache e sincronizzate con il backend al ritorno della connessione. Le notifiche push partono dal backend e raggiungono il service worker tramite un servizio push.
  APP["UI della PWA"] --> SW["Service worker<br/>(proxy di rete)"]
  SW -->|"cache hit"| C[("Cache<br/>specchio locale")]
  SW -->|"cache miss / dati freschi"| API[("API del backend<br/>fonte di verità")]
  C -.->|"scritture offline in coda<br/>sincronizzate quando online"| API
  API -->|"messaggio push"| PS["Servizio push"] --> SW
```

## Strategie di cache offline

| Strategia | Serve da | Adatta a |
| --- | --- | --- |
| Cache-first | Cache, poi rete | Asset statici – shell, icone, font |
| Network-first | Rete, con ripiego sulla cache | Dati freschi che devono essere aggiornati |
| Stale-while-revalidate | Cache subito, aggiornamento in background | Contenuti che possono restare per un attimo non aggiornati |
| Cache-only / network-only | Una sola fonte | Essenziali precaricati in cache / chiamate mai in cache |

La decisione si prende risorsa per risorsa, non a livello di app: la shell vuole cache-first per caricamenti istantanei; i dati vivi dell'utente vogliono network-first per la freschezza; un feed può accontentarsi di stale-while-revalidate per sembrare istantaneo e correggersi da solo. Qualunque sia la strategia scelta, la cache è un *buffer di lettura/scrittura* sopra l'[API](/glossary/it/api/) – le scritture offline vanno in coda localmente e si riconciliano alla riconnessione, la [stessa disciplina di recupero](/glossary/it/live-queries-tempo-reale/) che ogni client offline-first richiede.

## Da dove arrivano davvero le notifiche push

Il meccanismo che quasi nessun glossario spiega, e il motivo per cui una PWA ha bisogno di un backend anche solo per notificare. Il client si limita a *sottoscrivere*: chiede il permesso e riceve un endpoint di sottoscrizione. L'invio è un lavoro del server – **il backend → il servizio push del browser → l'evento `push` del service worker → una notifica visualizzata.** Il service worker può svegliarsi per mostrarla con l'app chiusa, ma non arriva nulla se un backend non l'ha inviata: "le PWA hanno il push" è quindi solo metà di una feature senza la metà server. L'articolo sulle [notifiche push](/glossary/it/notifiche-push/) copre la catena di consegna; il punto qui è che web push e push nativo terminano entrambi nel *proprio* codice che decide di inviare.

## PWA vs. app nativa

| | PWA | Nativa |
| --- | --- | --- |
| Codebase | Una sola, sul web | Una per piattaforma (o [multipiattaforma](/glossary/it/sviluppo-multipiattaforma/)) |
| Distribuzione | Un URL – nessuno store richiesto | App store, con revisione |
| Aggiornamenti | Istantanei, lato server | Ciclo di rilascio dello store |
| Visibilità nelle ricerche | Indicizzata dai motori di ricerca | Solo ricerca nello store |
| Accesso all'hardware | Limitato (varia a seconda del sistema operativo) | Completo |
| Affidabilità del push | Buona su Android, condizionata su iOS | Affidabile via [APNs/FCM](/glossary/it/notifiche-push/) |
| Realtà su iOS | Installazione solo dal menu Condividi, push dalla 16.4 | App a pieno titolo |

L'asimmetria onesta sta nell'ultima riga: iOS è il punto debole delle PWA – installazione solo dal menu Condividi, nessun install prompt automatico, push solo una volta installata e solo sulle versioni recenti, sincronizzazione in background incompleta. Su Android e desktop la distanza dal nativo è piccola; su iOS è il fattore decisivo per molti prodotti.

## Casi d'uso comuni

- **Contenuti e commercio** – copertura, SEO e bassa frizione di installazione battono il download da uno store nel raggiungere nuovi utenti.
- **Strumenti interni** – app installabili e tolleranti all'offline per utenti noti, senza distribuzione tramite store.
- **App sul campo offline-first** – raccogliere dati senza segnale, sincronizzare quando torna; il pattern della cache come buffer.
- **Copertura [multipiattaforma](/glossary/it/sviluppo-multipiattaforma/) a basso costo** – un'unica codebase web per coprire piattaforme che una build nativa triplicherebbe.
- **A fianco di un'app nativa** – lo stesso [backend](/glossary/it/baas-vs-backend-personalizzato/) serve una PWA per la copertura e un'app nativa per la profondità.

## Conviene costruire una PWA? Matrice decisionale

| Situazione | Scelta consigliata |
| --- | --- |
| Copertura, SEO, bassa frizione, un'unica codebase | PWA |
| Pubblico principalmente Android/desktop | PWA – la distanza dal nativo è piccola |
| iOS critico con forte dipendenza dal push | Nativo, oppure accettare le riserve di iOS |
| Grafica pesante, AR, hardware in profondità | Nativo |
| Raccolta dati offline-first | PWA con un backend di sincronizzazione |
| Serve una presenza nello store | Nativo (o PWA nello store dove è accettata) |

## Limiti e trade-off

- **iOS fissa il tetto.** Installazione manuale dal menu Condividi, push condizionato e lacune nella sincronizzazione in background fanno di iOS il vincolo che più spesso decide tra PWA e nativo.
- **L'accesso all'hardware è parziale.** Bluetooth, NFC, contatti e API avanzate della fotocamera sono limitati o assenti a seconda del sistema operativo – le app molto legate al dispositivo vogliono ancora il nativo.
- **La cache non è il database.** Trattare la cache del service worker come fonte di verità apre la porta a scritture perse e conflitti su dati non aggiornati; è un buffer sopra il [backend](/glossary/it/baas-vs-backend-personalizzato/) autorevole.
- **Il push è metà client, metà server.** Sottoscrivere è facile; una PWA ha comunque bisogno di un backend per inviare, quindi "offline e push" è una feature backend con un distintivo frontend.
- **La visibilità nelle ricerche è un'arma a doppio taglio.** Nessun filtro dello store significa anche nessuna vetrina dello store; si scambiano curatela e cerimonia di installazione con un URL.

## Le PWA su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. È la metà backend della feature che i pilastri frontend si limitano a completare: il service worker mette in cache la shell, ma Back4app è la fonte di verità di cui quella cache è lo specchio – utenti [autenticati](/glossary/it/autenticazione-vs-autorizzazione/), dati sincronizzati che riconciliano le scritture offline alla riconnessione, e il *server che invia davvero* il web push a cui una PWA può solo sottoscriversi. Poiché un solo backend serve allo stesso modo una PWA, una web app classica e un'app nativa attraverso [SDK per piattaforma](/glossary/it/sdk-backend/), la copertura [multipiattaforma](/glossary/it/sviluppo-multipiattaforma/) che una PWA promette sul frontend trova il suo corrispettivo sul backend, scritto una volta sola – il client mette in cache, la piattaforma ricorda, e le due metà di "installabile, offline e push" finalmente si incontrano.