Cloudflare Pages o Vercel: quale scegliere
Cloudflare Pages o Vercel: confronto onesto su prezzi e banda, supporto a Next.js, funzioni lato server, esperienza d'uso, con tabella e verdetto per caso.
Devi pubblicare un progetto e le due opzioni sul tavolo sono Cloudflare Pages e Vercel. Su internet trovi entusiasmo da entrambe le parti e poca sostanza, mentre c'è una sola domanda che decide davvero. In questo articolo trovi il confronto punto per punto, una tabella, e la sezione onesta su quando la scelta non conta per niente.
La differenza di fondo
Vercel è una piattaforma costruita attorno a un framework; Cloudflare Pages è una rete costruita per altro, su cui puoi anche pubblicare un sito.
Sembra una battuta, è la chiave di tutto. Vercel nasce dall'azienda che sviluppa Next.js e ogni scelta di prodotto parte da lì. Cloudflare possiede una delle reti più capillari del mondo, costruita per fare da CDN e da scudo a una fetta enorme del web; Pages è quella rete usata anche per servire i tuoi file.
Da questa origine discendono entrambe le differenze che contano: il modello di prezzo (uno ha la banda in casa, l'altro la compra) e l'affinità con Next.js (uno lo scrive, l'altro lo adatta).
I due prodotti singolarmente sono già raccontati in cos'è Vercel e cos'è Cloudflare Pages. Qui li mettiamo uno di fronte all'altro.
Il modello di prezzo
È la differenza che si traduce in soldi, quindi si parte da qui.
Su Vercel la banda è una metrica fatturata a consumo. C'è una soglia inclusa e sopra quella il traffico si paga. Il modello è prevedibile finché il traffico lo è; smette di esserlo il giorno in cui un articolo finisce su un aggregatore o un bot decide di girare in tondo sul tuo sito. Il costo cresce con il successo, non con la complessità, ed è l'opposto dell'intuizione di chi viene da un hosting a canone.
Su Cloudflare Pages la banda non è fatturata a consumo. Non è una soglia più generosa: è proprio una voce che non compare nel conto per il traffico verso i file statici. Il motivo non è generosità, è struttura dei costi: la rete c'è già e serve volumi enormi per altri business, quindi il tuo picco è rumore statistico. Le limitazioni esistono ma stanno altrove — numero di build, richieste alle funzioni — e sono vincoli che incontri lavorando, non subendo traffico.
La conseguenza pratica: se il tuo progetto è statico o quasi e può ricevere picchi imprevedibili, questa è l'unica differenza tra piattaforme moderne che si traduce direttamente in una cifra sulla carta di credito. Su entrambe, comunque, il limite di spesa e le notifiche vanno attivate il primo giorno.
C'è anche il tema dell'uso commerciale: il piano gratuito di Vercel è per progetti personali e non commerciali, e viene fatto rispettare. Su Cloudflare non esiste questa clausola. Per il sito della tua attività con budget zero è una differenza decisiva.
Next.js: il punto da dire chiaramente
Qui non c'è confronto, e girarci intorno non aiuta nessuno.
Vercel sviluppa Next.js. Se usi Next.js con le sue funzioni server, Vercel è la scelta giusta.
Non è questione di preferenza: rendering incrementale, streaming, componenti server, middleware, ottimizzazione delle immagini funzionano su Vercel il giorno del rilascio, senza adattatori, perché piattaforma e framework sono progettati insieme. Il quadro di quelle modalità è in SSG, SSR e ISR.
Su Cloudflare Pages Next.js gira, ma passa da uno strato di adattamento. Funziona bene per una fetta consistente di casi, e i progetti nuovi possono partire direttamente sul runtime di Cloudflare. Restano tre attriti reali:
- Non tutte le funzionalità sono coperte allo stesso modo, e la copertura si muove nel tempo.
- C'è una finestra di attesa tra l'uscita di una funzionalità e il suo arrivo nell'adattatore.
- Il runtime non è Node.js, e questo si porta dietro il punto successivo.
Se usi qualsiasi altra cosa — Astro, SvelteKit, Nuxt, Hugo, Eleventy, HTML a mano — il vantaggio di Vercel evapora. Entrambe rilevano il framework, lo costruiscono e lo pubblicano senza che tu configuri nulla. Su terreno neutro sei libero di scegliere per altri motivi.
Le funzioni lato server
L'altra differenza sostanziale, e va misurata sul tuo codice, non in astratto.
Le funzioni di Vercel girano in Node.js completo (oltre a un runtime più leggero per la parte al bordo): le librerie funzionano, i driver ufficiali funzionano, gli SDK pesanti si installano. È l'ambiente che conosci.
Le funzioni di Pages sono Cloudflare Workers, in un runtime in stile browser. Sono velocissime ad avviarsi e stanno vicino a chi visita; il costo è la compatibilità. I flag di compatibilità con Node coprono molto, non tutto: moduli nativi, filesystem e alcuni driver di database restano fuori.
Scrivere un endpoint su Pages è comunque immediato, e il file assomiglia molto a una route di Next.js:
// functions/api/iscrizione.js
export async function onRequestPost({ request, env }) {
const { email } = await request.json();
await env.DB.prepare("INSERT INTO iscritti (email) VALUES (?)")
.bind(email)
.run();
return Response.json({ ok: true }, { status: 201 });
}
La differenza non è nella sintassi, che si assomiglia parecchio: è in cosa puoi importare dentro quel file.
Il criterio operativo: prendi il package.json del progetto e controlla le dipendenze lato server prima di decidere. Una sola libreria incompatibile sposta la scelta, e scoprirlo dopo aver riscritto metà del backend è il modo peggiore di arrivarci.
Ecosistema e contorno
Attorno a Vercel c'è il mondo del framework: analisi, monitoraggio delle prestazioni, integrazioni curate con i fornitori di database.
Attorno a Pages c'è il mondo dell'infrastruttura: archiviazione a oggetti con R2, database e chiavi-valore, code, e tutto il resto di Cloudflare — DNS, protezione dagli attacchi, regole sul traffico. Se il dominio è già lì, tutto sta in un pannello solo.
Un punto che pesa: su Pages i servizi collegati parlano con le funzioni senza uscire su internet. Su Vercel il database è quasi sempre di un altro fornitore e ogni query attraversa la rete pubblica — vale il ragionamento di edge computing: codice vicino all'utente e dati lontani è la ricetta per una lentezza inaspettata.
Sull'esperienza d'uso, dichiarandola come soggettiva: Vercel è più accompagnata, Cloudflare più tecnica, con una documentazione che presuppone un lettore che sa già. La prima ora è più liscia su Vercel.
La tabella
| Cloudflare Pages | Vercel | |
|---|---|---|
| Origine | Rete globale già esistente | L'azienda dietro Next.js |
| Banda | Non fatturata a consumo | A consumo sopra le soglie |
| Next.js | Tramite adattatore, copertura variabile | Nativo e immediato |
| Altri framework | Ottimo | Ottimo |
| Runtime funzioni | Workers, non Node | Node.js completo |
| Compatibilità librerie | Parziale | Ampia |
| Avvio delle funzioni | Praticamente istantaneo | Cold start percepibile |
| Anteprime per ramo | Sì | Sì, molto curate |
| Uso commerciale sul gratuito | Ammesso | Non ammesso |
| Ecosistema | Storage, DB, code, sicurezza di rete | Integrazioni e strumenti per il frontend |
| Esperienza d'uso | Più tecnica | Più accompagnata |
| Sito statico | Eccellente | Eccellente |
Quando la scelta non conta (e capita spesso)
Va detto apertamente perché è la situazione più comune di tutte.
Se pubblichi un sito statico — portfolio, blog, documentazione, landing page, vetrina generata da Astro, Hugo o Eleventy — le due piattaforme sono equivalenti. Stesso flusso da Git, stessa anteprima per ramo, HTTPS automatico, contenuti serviti da una rete globale, piano gratuito abbondante. La differenza di velocità percepita è zero: quello che rende lento un sito sono le immagini e il JavaScript, non la piattaforma — il tema è in come velocizzare un sito web.
Con un'unica postilla: se quel sito può ricevere picchi grossi di traffico, Pages ha un vantaggio economico reale. Ma parliamo di decine di migliaia di visite in poche ore, non del blog che ne fa duecento al giorno.
Il costo di sbagliare è vicino a zero: il codice sta in Git, la configurazione è un file, e spostarsi da una all'altra è lavoro di un'ora. Ci ho visto perdere più tempo che a fare il deploy.
Errori comuni
Migrare un'applicazione Next.js complessa su Pages senza provare prima. È la delusione più frequente in assoluto: fai partire un ramo di prova e verifica, non migrare e poi scoprire. Il singolo modulo incompatibile col runtime dei Workers è il motivo numero uno per cui una migrazione si arena a metà.
Scegliere Pages solo per la banda su un progetto che non ne consuma. Se il sito fa qualche migliaio di visite al mese il risparmio è zero, e stai scegliendo in base a un problema che non hai.
Mettere Cloudflare in modalità proxy davanti a un sito su Vercel senza capire la cache. Due livelli di cache che non si parlano producono pagine dinamiche servite come statiche e aggiornamenti che non arrivano mai. Il tema è in cos'è il caching.
Confondere Pages con la CDN di Cloudflare davanti a un altro hosting. Una ospita il sito, l'altra accelera un sito che vive altrove.
Usare il piano gratuito di Vercel per un progetto commerciale. Il rischio non è un rimprovero, è il progetto sospeso nel momento peggiore.
Aspettarsi che una delle due faccia girare un processo sempre attivo. Per quello servono Railway o un VPS.
Il verdetto, caso per caso
Scegli Vercel se: usi Next.js con funzioni server e vuoi le novità appena escono; dipendi da librerie Node lato server; lavori in team dove le anteprime valgono il costo; il progetto genera ricavi e la fattura del traffico è sostenibile.
Scegli Cloudflare Pages se: il progetto è statico o prevalentemente statico; ti aspetti traffico alto o imprevedibile e vuoi un tetto di costo tranquillo; usi già Cloudflare per DNS e sicurezza; hai un progetto commerciale che deve stare legittimamente su un piano gratuito.
Prendi la prima che ti viene in mente se: stai pubblicando un blog, un portfolio o una documentazione. Davvero.
C'è anche l'ibrido che nessuno propone mai: sito su Pages, e le poche parti che richiedono Node completo su un altro servizio, collegate per sottodominio.
In sintesi
La differenza di fondo è l'origine: Vercel è nata attorno a un framework, Pages attorno a una rete. Tutto il resto discende da lì.
Next.js con funzioni server è il motivo più solido per stare su Vercel, e va detto senza ambiguità: chi lo sviluppa lo fa girare meglio.
La banda non fatturata a consumo è il motivo più solido per stare su Pages, ed è l'unica vera differenza di modello economico del settore — ma conta solo se il traffico c'è davvero.
Le funzioni sono il discrimine tecnico: Node completo su Vercel, runtime dei Workers su Pages. Controlla le dipendenze prima di decidere, non dopo.
Per un sito statico sono equivalenti, e dirlo è più utile che inventare un vincitore.
Per l'approfondimento su ciascuna leggi cos'è Vercel e cos'è Cloudflare Pages; se stai valutando anche la terza opzione, il confronto è in Vercel o Netlify.