Cloudflare Workers vs Pages: The Difference That Matters Before You Choose

Most tutorials on Cloudflare Workers and Pages make the wrong comparison. It places the two as direct competitors, as if you had to choose between one framework and another. Workers and Pages solve different problems at different layers — and choosing without understanding this distinction creates architectures that are expensive or require refactoring in six months.

What each one actually is

Workers is a computing platform. You write code, deploy it with wrangler deploy, and that code runs on V8 isolates distributed across the Cloudflare network — currently in more than 300 points of presence. The execution model is event-driven: each HTTP request, queue message, cron trigger or email handler generates an invocation. Cold start is below 1ms because V8 isolates share the same process, unlike containers that start from scratch.

Pages is a hosting platform. The central case is: you have a website or SPA, you build git push, Cloudflare runs your build (npm run build, Hugo, Astro, whatever), and the resulting static assets are distributed across its global CDN. Requests for these assets — HTML, JS, CSS, images — are served directly from the CDN, without going through any computing runtime.

Pages also has Pages Functions, which are Workers scripts deployed via directory convention (/functions). The confusion starts here: Pages Functions run on the same V8 runtime as Workers, have the same bindings (D1, KV, R2, Durable Objects), the same CPU and memory limits. The difference between Pages Functions and pure Workers is not technical — it's operational.

The account that changes everything

On the Workers paid plan ($5/month), you have 10 million requests included and pay $0.30 per million above that. Each HTTP request processed by the runtime counts.

In Pages, requests for static assets cost nothing per request — they are served by Cloudflare's CDN without triggering the Workers runtime. You pay for the builds ($20/month for the pro plan, with up to 5,000 builds/month and 5 concurrent builds). Requests for Pages Functions consume the same budget as Workers.

Translating to a real case: a website with 100 million monthly requests, 90% for static assets (JS bundles, images, HTML pages) and 10% for API routes. On Pages, the 90 million static requests cost $0. The 10 million Function calls are part of the free Functions on the pro plan. In the equivalent architecture with pure Workers serving the same assets via fetch() versus an R2 bucket, you would pay $27/month just for the difference ($0.30 × 90M requests above the 10M included).

This difference is structural and does not disappear as the scale increases — it worsens.

Where Workers have a real advantage

Certain primitives exist only in Workers. Cron triggers — the ability to execute code at a scheduled time — do not exist in Pages. If you need a job that runs every hour to synchronize data, process a queue, or clean up expired records, this is Workers. It has no equivalent in Pages.

Workers also supports Queues consumers (process messages from Cloudflare Queues asynchronously), Email Workers (receive and process emails), and Workers for Platforms (dispatch for user-deployed scripts, useful for multi-tenant SaaS). These non-HTTP triggers only exist in the Workers model.

Durable Objects work in both, but complex coordination between multiple instances — for example, a distributed stateful WebSocket server — tends to be cleaner in Workers, where you have full control over deployment and routing.

The actual overlay

Pages Functions and Workers share exactly the same runtime. The limits are identical: 128MB of memory (hard limit), 10MB of compressed script on the paid plan, 1,000 subrequests per invocation on the paid plan, 30s of CPU per request. The available bindings are the same: D1, KV, R2, Durable Objects, AI, Service Bindings to call other Workers.

This means that a mid-range API can be built entirely on Pages Functions without sacrificing anything in terms of runtime capability. The question isn't "which one has more computing power" — it's "which deployment and billing model makes the most sense for my workload."

The decision criteria

The heuristic works like this: if your project has static assets generated by build (any frontend framework, static site generator, SPA), Pages is the natural starting point. You get a global CDN for assets at no cost per request, automatic preview deployments per branch, and an integrated build pipeline. The API routes are in /functions and run in the same Workers runtime.

If the project is compute-first — without significant static assets, or with non-HTTP triggers like cron, queues and email — Workers is the direct choice. The deployment model via wrangler.toml is more explicit, versionable in code, and integrates better with customized CI/CD workflows.

Most projects do not live at just one extreme. A typical SaaS has a frontend (Pages, with free CDN), an API (Pages Functions, same code base, same deploy), and a set of background jobs (separate Workers, with cron triggers). These background Workers connect to the Pages project via Service Bindings — direct calls between Workers without going through the public internet.

What the documentation doesn't explain

Cloudflare documents Workers and Pages as separate products with separate pages, which obscures an important detail: a Pages project can call external Workers via Service Bindings, and external Workers can serve assets from a Pages project. They are not silos. They are pieces that come together.

The most common mistake is to reimplement in Workers what Pages does for free — serve static assets — because someone read about Workers first and thought it was "more advanced." Workers is not more advanced than Pages. It's a different tool for a different layer of the problem.