Worker Cloudflare e Pages: la differenza che conta prima di scegliere

La maggior parte dei tutorial su Cloudflare Workers e Pages fanno un confronto sbagliato. Li pone come concorrenti diretti, come se si dovesse scegliere tra un quadro e l'altro. I Worker e le Pagine risolvono problemi diversi a livelli diversi e scegliere senza comprendere questa distinzione crea architetture costose o che richiedono il refactoring in sei mesi.

Ciò che ognuno di essi è realmente

Workers è una piattaforma informatica. Scrivi il codice, lo distribuisci con wrangler deploy e quel codice viene eseguito su isolati V8 distribuiti sulla rete Cloudflare, attualmente in più di 300 punti di presenza. Il modello di esecuzione è guidato dagli eventi: ogni richiesta HTTP, messaggio in coda, trigger cron o gestore di posta elettronica genera un'invocazione. L'avvio a freddo è inferiore a 1 ms perché gli isolati V8 condividono lo stesso processo, a differenza dei contenitori che iniziano da zero.

Pages è una piattaforma di hosting. Il caso centrale è: hai un sito web o una SPA, costruisci git push, Cloudflare esegue la tua build (npm run build, Hugo, Astro, qualunque cosa) e le risorse statiche risultanti vengono distribuite attraverso la sua CDN globale. Le richieste per queste risorse (HTML, JS, CSS, immagini) vengono servite direttamente dalla CDN, senza passare attraverso alcun runtime di elaborazione.

Pages ha anche funzioni di Pages, che sono script Workers distribuiti tramite convenzione di directory (/functions). La confusione inizia qui: le funzioni di Pages vengono eseguite sullo stesso runtime V8 dei Workers, hanno gli stessi collegamenti (D1, KV, R2, oggetti durevoli), gli stessi limiti di CPU e memoria. La differenza tra Pages Functions e puro Workers non è tecnica: è operativa.

L'account che cambia tutto

Nel piano a pagamento Workers ($ 5 al mese), hai 10 milioni di richieste incluse e paghi $ 0,30 per milione in più. Viene conteggiata ogni richiesta HTTP elaborata dal runtime.

In Pages, le richieste di risorse statiche non costano nulla per richiesta: vengono servite dalla CDN di Cloudflare senza attivare il runtime di Workers. Paghi per le build ($ 20 al mese per il piano Pro, con un massimo di 5.000 build al mese e 5 build simultanee). Le richieste per le funzioni delle pagine consumano lo stesso budget dei lavoratori.

Traducendo in un caso reale: un sito Web con 100 milioni di richieste mensili, il 90% per risorse statiche (bundle JS, immagini, pagine HTML) e il 10% per percorsi API. Su Pages, i 90 milioni di richieste statiche costano 0 dollari. I 10 milioni di chiamate di funzioni fanno parte delle funzioni gratuite del piano Pro. Nell'architettura equivalente con Workers puri che servono le stesse risorse tramite fetch() rispetto a un bucket R2, pagheresti $ 27 al mese solo per la differenza ($ 0,30 × 90 milioni di richieste superiori ai 10 milioni incluse).

Questa differenza è strutturale e non scompare con l’aumento della scala, bensì peggiora.

Dove i lavoratori hanno un vantaggio reale

Alcuni primitivi esistono solo in Workers. I trigger Cron, ovvero la possibilità di eseguire codice a un orario programmato, non esistono in Pages. Se hai bisogno di un lavoro che venga eseguito ogni ora per sincronizzare i dati, elaborare una coda o pulire i record scaduti, questo è Workers. Non ha equivalenti in Pages.

Workers supporta anche i consumatori di code (elaborare i messaggi dalle code di Cloudflare in modo asincrono), Email Workers (ricevere ed elaborare e-mail) e Workers for Platforms (inviare script distribuiti dall'utente, utile per SaaS multi-tenant). Questi trigger non HTTP esistono solo nel modello Workers.

Gli oggetti durevoli funzionano in entrambi, ma il coordinamento complesso tra più istanze, ad esempio un server WebSocket con stato distribuito, tende ad essere più pulito in Workers, dove si ha il pieno controllo sulla distribuzione e sul routing.

La sovrapposizione effettiva

Le funzioni e i lavoratori delle pagine condividono esattamente lo stesso runtime. I limiti sono identici: 128 MB di memoria (limite rigido), 10 MB di script compresso sul piano a pagamento, 1.000 sottorichieste per invocazione sul piano a pagamento, 30 secondi di CPU per richiesta. Le associazioni disponibili sono le stesse: D1, KV, R2, Oggetti Durevoli, AI, Associazioni di Servizio per chiamare altri Worker.

Ciò significa che un'API di fascia media può essere costruita interamente su Pages Functions senza sacrificare nulla in termini di capacità di runtime. La domanda non è "quale ha più potenza di calcolo", ma "quale modello di distribuzione e fatturazione ha più senso per il mio carico di lavoro".

I criteri decisionali

L'euristica funziona in questo modo: se il tuo progetto ha risorse statiche generate da build (qualsiasi framework frontend, generatore di siti statici, SPA), Pages è il punto di partenza naturale. Ottieni una CDN globale per le risorse senza alcun costo per richiesta, distribuzioni di anteprima automatiche per filiale e una pipeline di compilazione integrata. I percorsi API sono in /functions e vengono eseguiti nello stesso runtime Workers.

Se il progetto è compute-first, ovvero senza risorse statiche significative o con trigger non HTTP come cron, code ed e-mail, Workers è la scelta diretta. Il modello di distribuzione tramite wrangler.toml è più esplicito, è possibile creare versioni nel codice e si integra meglio con flussi di lavoro CI/CD personalizzati.

La maggior parte dei progetti non vive solo a un estremo. Un tipico SaaS ha un frontend (Pages, con CDN gratuito), un'API (Funzioni di Pages, stesso codice base, stessa distribuzione) e una serie di lavori in background (Worker separati, con trigger cron). Questi lavoratori in background si connettono al progetto Pages tramite Service Binding: chiamate dirette tra lavoratori senza passare attraverso la rete Internet pubblica.

Ciò che la documentazione non spiega

Cloudflare documenta Worker e Pages come prodotti separati con pagine separate, il che oscura un dettaglio importante: un progetto Pages può chiamare Worker esterni tramite associazioni di servizi e i Worker esterni possono servire risorse da un progetto Pages. Non sono silos. Sono pezzi che si uniscono.

L'errore più comune è reimplementare in Workers ciò che Pages fa gratuitamente – servire risorse statiche – perché qualcuno ha letto prima di Workers e ha pensato che fosse "più avanzato". Workers non è più avanzato di Pages. È uno strumento diverso per un livello diverso del problema.