Per anni la risposta alla domanda “dove distribuisco questo su Cloudflare” era semplice: siti statici e frontend andavano su Pages, mentre la logica serverless andava su Workers. Nel 2026 quella linea si è sfumata, perché Workers può ora servire asset statici direttamente, il che significa che un singolo Worker può ospitare l’intero sito, frontend e backend insieme. Questo ha cambiato la raccomandazione stessa di Cloudflare per i nuovi progetti, e vale la pena capire perché prima di scegliere una parte.
Questa guida spiega cos’è ciascun prodotto, come il passaggio agli asset statici ha cambiato la decisione tra Cloudflare Pages vs Workers, e fornisce una raccomandazione chiara per nuovi progetti e per chiunque si chieda se migrare.
In breve
- Pages è hosting connesso a git per siti statici e framework frontend, con CI/CD integrato e deploy di anteprima
- Workers è la piattaforma di calcolo serverless di Cloudflare, e ora serve anche asset statici, quindi può ospitare siti completi
- Per i nuovi progetti nel 2026, Cloudflare raccomanda Workers con asset statici, perché unifica frontend e backend in un unico deploy
- Pages resta pienamente supportato; non c’è bisogno di affrettarsi a spostare un progetto Pages esistente
- Scegli in base al flusso di lavoro: Pages per un deploy statico puro in git-push, Workers per tutto ciò che mescola contenuto statico e logica dinamica
Cos’è Cloudflare Pages
Cloudflare Pages è una piattaforma per distribuire siti web direttamente da un repository git. Colleghi un repo GitHub o GitLab, Cloudflare esegue il tuo comando di build, e l’output viene distribuito sull’edge globale. Ogni push ottiene un deploy di anteprima con il suo URL, e il merge nel ramo di produzione aggiorna il sito live. È il classico flusso Jamstack: pushare il codice, ottenere un sito distribuito.
Pages supporta anche comportamenti dinamici tramite le Pages Functions, che sono Workers sotto il cofano, quindi puoi aggiungere route di API e logica lato server a un sito altrimenti statico. Ho usato esattamente questo approccio per costruire un sistema completo di registrazione e login su Cloudflare Pages , che mostra fino a che punto può spingersi un host “statico”.
Cos’è Cloudflare Workers
Cloudflare Workers è la piattaforma di calcolo serverless e di hosting serverless: codice che gira sulla rete di Cloudflare, vicino ai tuoi utenti, senza server da gestire. Workers è nato come funzioni pure per API, middleware e logica all’edge, e si lega al resto della piattaforma, R2 , D1 , KV, Queues e Workers AI . Se costruisci su questi binding di archiviazione, le mie app desktop gratuite li rendono facili da gestire: Easy Cloudflare R2 , Easy Cloudflare D1 e Easy Cloudflare KV .
Lo sviluppo chiave del 2026 sono gli Static Assets. Un Worker può ora servire una directory di file statici (HTML, CSS, JS, immagini) direttamente, con il Worker che gestisce qualsiasi route dinamica. Ciò significa che un singolo Worker può ospitare il tuo frontend compilato e la tua API in un unico deploy, qualcosa che prima richiedeva di dividere il lavoro tra Pages e Workers.
Cosa è cambiato per Pages vs Workers: gli Static Assets
Il motivo per cui questo confronto ha senso adesso è la capacità degli asset statici. Storicamente, se avevi un frontend React o Astro più un’API backend, la divisione naturale era Pages per il frontend e un Worker separato per l’API. Due progetti, due deploy, due cose da collegare.
Con gli asset statici su Workers, distribuisci una sola volta. Il Worker serve il tuo build statico per le richieste normali ed esegue il tuo codice per le route di API o le pagine renderizzate lato server. Per i framework full-stack e le app che mescolano contenuto statico e dinamico, questo è più semplice da costruire, distribuire e ragionare. È per questo che Cloudflare ora indirizza i nuovi progetti full-stack verso Workers anziché Pages.
Pages vs Workers: a confronto
| Criterio | Cloudflare Pages | Cloudflare Workers |
|---|---|---|
| Scopo principale | Hosting di siti connesso a git | Calcolo serverless + asset statici |
| Hosting statico | Sì (funzione di base) | Sì (tramite asset statici) |
| Logica dinamica/server | Pages Functions | Nativa |
| CI/CD git + anteprime | Integrato | Tramite integrazione CI / Wrangler |
| Binding (R2, D1, KV, AI) | Sì | Sì, di prima classe |
| Ideale per | Siti statici/Jamstack puri | App full-stack e API |
| Raccomandazione 2026 per nuovi progetti | Ancora supportato | Preferito |
Quando scegliere Pages
Nella decisione Pages vs Workers, Pages è ancora un’ottima scelta quando:
- Hai un sito puramente statico o un build di framework frontend e vuoi il flusso di deploy git-push più semplice possibile
- Apprezzi il CI/CD integrato e i deploy di anteprima senza configurare nulla
- Le tue esigenze dinamiche sono leggere e ben servite dalle Pages Functions
- Sei già su Pages e funziona; non c’è alcuna penalità nel restare
Quando scegliere Workers
Nella decisione Pages vs Workers, Workers è la scelta migliore quando:
- Stai costruendo un’applicazione full-stack che mescola contenuto statico con logica lato server consistente
- Vuoi frontend e backend in un unico deploy anziché due progetti coordinati
- Ti affidi pesantemente a binding come D1, R2, KV, Queues o Workers AI
- Stai avviando un nuovo progetto nel 2026 e vuoi seguire il percorso attualmente raccomandato da Cloudflare
- Hai bisogno di un controllo fine su routing, caching e gestione delle richieste
Cloudflare Pages vs Workers: dovresti migrare?
No, non per riflesso. Se hai un progetto Pages funzionante, resta pienamente supportato e non c’è alcuna scadenza che imponga uno spostamento. Migra quando hai una ragione concreta: stai aggiungendo logica backend sostanziale, vuoi consolidare un frontend/backend separato in un unico deploy, o stai incontrando un limite specifico di Pages che Workers risolve.
Per i progetti greenfield nella scelta Pages vs Workers, parti da Workers con asset statici. Per un deploy Pages esistente che ti soddisfa, lascialo finché non emerge un’esigenza reale. La ragione peggiore per migrare è la novità; la ragione migliore è unificare un’app full-stack che altrimenti dovresti dividere.
Punti chiave
- Pages è hosting connesso a git per siti statici e Jamstack con CI/CD integrato e anteprime
- Workers è calcolo serverless che ora serve anche asset statici, quindi può ospitare siti completi
- Gli Static Assets sono il cambiamento che permette a un singolo Worker di ospitare frontend e backend insieme
- Per i nuovi progetti full-stack nel 2026, Workers è il percorso raccomandato da Cloudflare
- Pages resta pienamente supportato; migra solo quando hai una ragione concreta
- Nella decisione Cloudflare Pages vs Workers, scegli Pages per la semplicità puramente statica e Workers per tutto ciò che mescola contenuto statico con logica reale
Domande frequenti
Qual è la differenza tra Cloudflare Pages e Workers? Pages è hosting connesso a git per siti statici e frontend con CI/CD integrato e deploy di anteprima. Workers è la piattaforma di calcolo serverless di Cloudflare. La linea si è sfumata nel 2026 perché Workers può ora servire asset statici, consentendo a un Worker di ospitare sia un frontend che un backend.
Dovrei usare Pages o Workers per un nuovo progetto nel 2026? Per la maggior parte dei nuovi progetti full-stack, Workers con asset statici è ora la scelta raccomandata da Cloudflare perché unifica frontend e backend in un unico deploy. Per un sito puramente statico dove vuoi il flusso git-push più semplice, Pages resta un’opzione eccellente.
Cloudflare Pages è in fase di dismissione? No. Pages resta pienamente supportato. Cloudflare ora indirizza i nuovi progetti full-stack verso Workers, ma i progetti Pages esistenti continuano a funzionare e non c’è alcuna migrazione forzata.
Workers può ospitare un sito web statico? Sì. Con la funzione degli asset statici, un Worker può servire file statici come HTML, CSS, JS e immagini direttamente, gestendo anche route dinamiche nel codice. È questo che permette a un singolo Worker di ospitare un intero sito.
Pages e Workers usano gli stessi binding? Entrambi possono usare binding Cloudflare come R2, D1, KV e Workers AI. Pages li espone tramite le Pages Functions, mentre Workers li tratta come di prima classe. Funzionalmente puoi raggiungere gli stessi servizi della piattaforma da entrambi.
Dovrei migrare il mio sito Pages esistente a Workers? Solo se hai una ragione concreta, come aggiungere logica backend significativa o consolidare un frontend e un backend separati in un unico deploy. Un progetto Pages funzionante è pienamente supportato e non ha bisogno di essere spostato.
Commenti