Cloudflare Pages o Netlify: un deploy può pesare più del traffico

Per un sito statico aggiornato spesso, Cloudflare Pages Free offre più margine per pubblicare nuove versioni; nei piani Netlify a crediti, invece, i deploy di produzione possono incidere più del traffico. Le tariffe Netlify a crediti assegnano al Free 300 crediti mensili e ne consumano 15 per ogni deploy di produzione, 20 per GB di banda web e 2 ogni 10.000 richieste web.

La scelta dipende quindi da quante versioni rendi pubbliche, oltre che da quanto viene visitato il sito. I limiti di Cloudflare Pages prevedono sul Free 500 build mensili, una alla volta, e un massimo di 100 progetti per account: anche le build destinate alle anteprime vanno considerate. Un sito ibrido richiede poi di valutare separatamente il codice eseguito a ogni richiesta.

Tre siti, tre conti mensili

Per stimare il consumo Netlify di un sito statico, il calcolo di base è: deploy di produzione × 15, più GB trasferiti × 20, più richieste web ÷ 10.000 × 2. Il risultato esprime crediti, non euro; esclude funzioni, database e altri servizi misurati. Conta i rilasci arrivati al dominio principale: preparare più versioni dello stesso cambiamento non equivale necessariamente a pubblicarle tutte.

I seguenti sono scenari ipotetici, ciascuno riferito a un mese. Le richieste comprendono gli accessi ai singoli file serviti, come pagine, immagini, fogli di stile e script; perciò non coincidono con il numero di visitatori.

• Portfolio personale: 4 deploy di produzione, 1 GB di banda e 20.000 richieste consumano 60 crediti per i rilasci, 20 per la banda e 4 per le richieste: 84 in totale. Con modifiche sporadiche, il margine del Free resta ampio.
• Progetto open source: 30 deploy di produzione, 2 GB e 50.000 richieste consumano 450 + 40 + 10 = 500 crediti. Una pubblicazione quotidiana supera da sola i 300 crediti del Free, pur con un traffico modesto.
• Piccolo SaaS con frontend statico: 30 deploy di produzione, 10 GB e 500.000 richieste consumano 450 + 200 + 100 = 750 crediti. I rilasci restano la voce maggiore; eventuali funzioni aggiungerebbero altro consumo.

Il peso relativo si vede anche su scala più piccola: un solo deploy assorbe gli stessi crediti di 0,75 GB di banda web, prima di contare le richieste. Venti deploy consumerebbero tutti i 300 crediti del Free anche senza traffico, quindi quel numero non rappresenta una capacità mensile utilizzabile per un sito visitato. Per un progetto con più siti nello stesso team, il conto va fatto sul consumo complessivo, non su ogni sito isolatamente.

Build, anteprime e dimensione del progetto

Cloudflare Pages conta le build dell’account, comprese quelle avviate per rami che producono un’anteprima. Se il progetto open source ipotetico genera 30 build per la versione pubblica e 60 per le revisioni, ne usa 90 della quota mensile. Il numero di anteprime che possono restare attive non ha un limite indicato, ma ogni nuova build entra comunque nel conteggio e ha un tempo massimo di esecuzione.

Netlify tratta diversamente i deploy preview e quelli dei rami: il loro rilascio non comporta i 15 crediti del deploy di produzione. La guida Netlify ai crediti precisa però che banda e richieste generate dalle anteprime visitate vengono conteggiate; precisa inoltre che i piani a crediti si applicano ai nuovi account dal 4 settembre 2025, mentre gli account precedenti possono essere su piani Legacy. Per un team che condivide spesso le anteprime, il loro traffico va quindi aggiunto al calcolo.

Pages pone anche limiti all’output: sul Free, un sito può contenere fino a 20.000 file e un singolo asset può misurare al massimo 25 MiB. Il controllo riguarda i file prodotti dalla build, non soltanto quelli presenti nel repository. Un portfolio leggero difficilmente si avvicina a queste soglie; una documentazione generata con molte pagine o una raccolta di file scaricabili potrebbe incontrarle prima del limite mensile di build.

Che cosa succede al limite

Il saldo Netlify Free è un limite rigido. Quando i crediti del team finiscono, tutti i suoi progetti web vengono messi in pausa e chi li visita vede una pagina di indisponibilità; si fermano anche i nuovi deploy. Sul Free non si possono acquistare crediti aggiuntivi: per riprendere il servizio occorre attendere il ciclo successivo oppure passare a un piano a pagamento. Su Personal e Pro è possibile acquistare crediti o attivare la ricarica automatica, disattivata per impostazione predefinita.

Questo rende diverso il rischio dei due contatori. Una quota di build esaurita su Pages riguarda la possibilità di distribuire un’altra versione nel periodo; un saldo Netlify esaurito incide anche sulla disponibilità dei siti già pubblicati. Per una pagina pubblica che deve restare raggiungibile, consumare quasi tutti i crediti con i soli rilasci lascia poco spazio a visite, download o una correzione urgente.

Quando il frontend esegue codice

Su un sito ibrido, la distribuzione degli asset statici e l’esecuzione delle funzioni vanno tenute distinte. Le regole di Pages Functions indicano che le richieste agli asset statici che non invocano una Function sono gratuite e illimitate; le invocazioni delle Functions condividono invece la quota Workers Free di 100.000 richieste al giorno. La configurazione delle rotte conta: se una richiesta passa dalla Function, non è più una semplice richiesta statica ai fini di quella quota.

Nel piccolo SaaS ipotetico, i 750 crediti Netlify rappresentano soltanto deploy, banda e richieste del frontend assunti nel calcolo. Un’API per autenticazione o accesso ai dati aggiunge consumo di calcolo su Netlify, mentre su Pages usa le risorse previste per Workers e per eventuali servizi collegati. Due applicazioni con lo stesso numero di visitatori possono così avere costi diversi se una serve file già pronti e l’altra esegue codice per molte richieste.

Redirect e cache incidono sulla scelta

Una migrazione può richiedere lavoro anche quando il nuovo piano sembra più conveniente. Il confronto di Mirror sui redirect distingue le regole supportate dai due file _redirects: Netlify gestisce condizioni basate su parametri della query, paese o lingua che il file di Pages non supporta. Cambia anche il codice predefinito se la regola non ne specifica uno: permanente su Netlify, temporaneo su Pages. Per un sito con molti URL storici, quelle regole possono richiedere una riscrittura esplicita.

La cache merita attenzione quando Pages usa un dominio con regole Cloudflare già configurate. Una regola personalizzata che conserva l’HTML può far apparire una versione precedente dopo un deploy; può anche interferire con redirect e Functions. Per un portfolio nuovo e semplice il problema può non presentarsi, mentre una documentazione migrata o un SaaS con instradamento condizionale devono includere questi comportamenti nel costo della scelta.

Per pubblicazioni frequenti di file statici, entro i limiti di build e dimensione, Pages offre un margine più ampio. Netlify resta una scelta ragionevole quando i deploy di produzione sono meno frequenti oppure servono le sue regole di instradamento. La stima decisiva è il consumo di un mese rappresentativo: rilasci pubblici, banda, richieste delle anteprime e, per i siti ibridi, lavoro delle funzioni.

Leggi anche:

• OBS Studio o Streamlabs: la facilità pronta all’uso può pesare sulla CPU
• Shopify o WooCommerce: il software gratis non azzera il costo del negozio
• Copilot Studio: una risposta può consumare più contatori di crediti