Cos'è Cloudflare Pages e quando conviene

Pubblichi un progetto, va bene, e un giorno finisce su un aggregatore con qualche decina di migliaia di visite in un pomeriggio. Sulla maggior parte delle piattaforme moderne quella è una bella notizia e una fattura più alta. Su Cloudflare Pages è solo una bella notizia. In questo articolo trovi cos'è, come funziona, perché il suo modello di prezzo è diverso da tutti gli altri e dove invece è ancora indietro.

Cos'è

Cloudflare Pages è la piattaforma di hosting e deploy di Cloudflare: colleghi un repository Git, lei costruisce il sito e lo serve direttamente dalla rete globale di Cloudflare, la stessa che fa da CDN e da scudo a una fetta enorme del web.

La differenza rispetto alle altre piattaforme non è nel flusso di lavoro — quello è identico — ma in cosa c'è sotto. Cloudflare possiede già una rete di data center distribuita in tutto il mondo, costruita per un business diverso. Pages è quella rete usata anche per servire i tuoi file.

Questo spiega sia il punto di forza sia i limiti.

Come funziona

Il flusso non riserva sorprese:

1. Colleghi un repository GitHub o GitLab.
2. Indichi comando di build e cartella di output (per molti framework vengono rilevati da soli).
3. Ogni push costruisce e pubblica.
4. Ogni ramo ottiene un URL di anteprima, come sulle altre piattaforme.

C'è anche la CLI, wrangler, che è lo stesso strumento usato per i Workers:

npm i -g wrangler
wrangler pages deploy ./dist                 # deploy della cartella costruita
wrangler pages deploy ./dist --branch=main   # deploy in produzione

Il risultato finale è un sito servito dal nodo Cloudflare più vicino a chi lo visita, con HTTPS attivo da subito e cache già configurata bene. Il funzionamento generale della distribuzione geografica è spiegato in cos'è una CDN.

Se il dominio è già gestito da Cloudflare, collegarlo richiede letteralmente un clic: i record DNS li scrive lei. Se sta altrove funziona lo stesso, con la procedura standard descritta in collegare un dominio al sito.

Il modello di prezzo: il vero punto di forza

Qui sta la ragione per cui vale la pena conoscere Pages anche se ti trovi bene altrove.

Su Cloudflare Pages la banda non è fatturata a consumo. Non è una soglia più alta della concorrenza: è proprio una voce che non compare nel conto. Il traffico verso i file statici non genera costo, indipendentemente da quanto sia.

Perché possono permetterselo: la rete c'è già e serve traffico enorme per altri motivi. Il tuo sito che va bene per un giorno è rumore statistico nella loro infrastruttura. Per Vercel o Netlify, che comprano capacità da fornitori terzi, la banda è un costo vero che devono ribaltare su di te.

Cosa cambia concretamente:

• Nessun conto a sorpresa dopo un picco di traffico.
• Nessuna ansia da immagine pesante o file scaricabile grosso.
• Nessun bisogno di stare a guardare il pannello di utilizzo ogni settimana.
• Puoi servire contenuti pesanti senza pensare al costo per gigabyte.

Il piano gratuito è generoso e le limitazioni riguardano semmai il numero di build al mese e le richieste alle funzioni, non il traffico. Se il tuo progetto è statico e ha molto traffico, questa è la differenza più grande esistente tra le piattaforme moderne, ed è l'unica che si traduce direttamente in soldi.

Il confronto tra le altre due è in Vercel o Netlify, dove il modello a consumo vale per entrambe.

Il rapporto con i Workers

Pages da sola serve file statici. Per la parte dinamica entrano i Workers, il servizio di funzioni serverless di Cloudflare, che girano nella stessa rete e quindi molto vicino a chi visita.

Metti un file dentro la cartella functions/ e diventa un endpoint:

// functions/api/ciao.js
export function onRequest(context) {
  return new Response(JSON.stringify({ messaggio: "ciao" }), {
    headers: { "content-type": "application/json" },
  });
}

Attorno c'è un ecosistema che negli ultimi anni è cresciuto molto: archiviazione di oggetti, database, chiavi-valore distribuite, code. Tutto pensato per stare vicino al codice e comunicare senza attraversare internet.

Il punto da capire è che i Workers non sono Node.js. Girano in un runtime diverso, più simile a quello di un browser. Molte librerie del mondo Node — quelle che usano il file system, i moduli nativi, alcuni driver di database — semplicemente non funzionano. Ci sono strati di compatibilità e coprono parecchio, ma non tutto.

Cloudflare sta unificando Pages e Workers in un prodotto solo. Per i progetti nuovi conviene sapere che la direzione è quella, anche se ciò che pubblichi oggi continua a funzionare.

I limiti veri

Onestà: Pages non è la scelta migliore per tutto, e i punti deboli sono precisi.

Le funzioni sono meno mature. Il runtime ridotto è il limite principale: se la tua applicazione dipende da librerie Node comuni, ti scontrerai con incompatibilità che altrove non esistono. Anche gli strumenti di diagnostica — log, tracce, capire perché una funzione fallisce — sono meno immediati.

Le build sono più spartane. Ambiente di build meno ricco, meno plugin, meno automatismi. Su progetti con passaggi di build particolari può servire più lavoro di configurazione. La via d'uscita è costruire con GitHub Actions e pubblicare il risultato con wrangler.

Il supporto ai framework dinamici è più indietro. Un sito statico va liscio con qualsiasi generatore. Next.js con tutte le sue funzioni server è un'altra storia: serve un adattatore e non tutto è coperto. Se vivi sul filo delle novità di Next.js, questa non è la tua piattaforma.

L'esperienza d'uso è più tecnica. Cloudflare è un prodotto pensato per chi fa infrastruttura, e si vede: il pannello ha molte più voci, i messaggi di errore danno per scontate cose, la documentazione presuppone un lettore che sa già. Niente di insormontabile, ma il percorso è meno accompagnato che altrove.

Confronto rapido

	Cloudflare Pages	Vercel / Netlify
Banda	Non fatturata a consumo	A consumo sopra le soglie
Rete	Rete Cloudflare, molto capillare	CDN globale, ottima
Sito statico	Eccellente	Eccellente
Framework dinamici	Supporto più limitato	Migliore, soprattutto Next.js su Vercel
Funzioni	Workers, runtime non-Node	Più mature e compatibili
Ecosistema integrato	Storage, DB, code, sicurezza	Più orientato al framework
Esperienza d'uso	Più tecnica	Più accompagnata
Uso commerciale sul gratuito	Ammesso	Vercel non lo ammette

Errori comuni

Aspettarsi che un'app Next.js complessa funzioni senza adattamenti. È la delusione più frequente. Verifica la compatibilità prima di migrare un progetto già avviato, non dopo.

Confondere Pages con la CDN di Cloudflare messa davanti a un altro hosting. Sono due cose diverse: Pages ospita il sito, la modalità proxy davanti a un server esistente protegge e accelera un sito che vive altrove. Puoi usare l'una o l'altra, non ti servono entrambe per lo stesso sito.

Doppia cache non capita. Cloudflare ha regole di cache proprie sopra a quelle del sito. Se una pagina non si aggiorna dopo un deploy, quasi sempre è una risposta in cache e non un problema di build. Il tema è in cos'è il caching.

Ignorare il limite sulle build. La banda non si paga, ma il numero di build mensili sul piano gratuito sì che è limitato. Un repository con decine di push al giorno e build automatica su ogni ramo lo consuma in fretta.

Quando è la scelta giusta

Conviene se: hai un sito statico o prevalentemente statico (blog, documentazione, portfolio, vetrina, landing page), ti aspetti traffico alto o imprevedibile, usi già Cloudflare per DNS e sicurezza, vuoi un tetto di costo prevedibile, o hai un progetto commerciale che non vuoi far girare su un piano gratuito dove non è ammesso.

Non conviene se: l'applicazione è fortemente dinamica e legata a Next.js, dipendi da librerie Node non compatibili col runtime dei Workers, o vuoi il percorso più liscio possibile senza mettere le mani in configurazioni un po' più tecniche.

C'è anche un caso ibrido che funziona bene: sito su Pages, e le poche parti che richiedono un runtime Node completo su un altro servizio o su un VPS, collegate per sottodominio.

In sintesi

Cloudflare Pages è hosting collegato a Git servito direttamente dalla rete Cloudflare.

Il motivo per sceglierla è uno e pesa molto: la banda non si paga a consumo. In un settore dove tutti fatturano il traffico, questa è l'unica vera differenza di modello economico, e diventa decisiva appena un progetto cresce.

Il prezzo da pagare è la maturità della parte dinamica: funzioni su un runtime che non è Node, build più spartane, supporto ai framework server più indietro, interfaccia più tecnica.

La regola pratica: sito statico o quasi, Pages è la scelta più solida e la più tranquilla dal lato costi. Applicazione Next.js piena di funzioni server, resta su Vercel e valuta il confronto in Vercel o Netlify.

Per il quadro generale vedi come fare il deploy di un sito e come mettere online un sito a costo zero.