Loading00%
All articles

July 22, 2026

Cloudflare Workers: Running Code 50ms From Every Customer

Here's a problem most teams never measure. Your server lives in one data centre — say, Virginia. A customer in Colombo loads your checkout page. Their request travels roughly 14,000 kilometres, waits for the server to think, and travels 14,000 kilometres back.

Physics sets a floor on that round trip of around 250 milliseconds, before your code does a single thing. Do it four or five times in a page load and you've spent a second of the user's life on geography alone.

Edge computing removes the distance. Instead of one server in one city, your code runs in hundreds of cities at once — and whichever one is nearest handles the request.

What a Worker Actually Is

A Cloudflare Worker is a small piece of JavaScript or TypeScript that runs on Cloudflare's network, which spans data centres in over 300 cities. You deploy it once. Cloudflare puts it everywhere. A request from Colombo is handled in Colombo; a request from São Paulo is handled in São Paulo.

The simplest possible Worker:

export default {
  async fetch(request) {
    return new Response("Hello from the edge");
  },
};

That's a complete, deployable application. No server to provision, no container to configure, no region to choose.

Why It's Fast (And Why It's Not "Just Lambda")

Traditional serverless functions — AWS Lambda and friends — spin up a small virtual machine or container for your code. That startup is the infamous cold start: the first request after a quiet period waits hundreds of milliseconds, sometimes seconds, for the environment to boot.

Workers use a different mechanism. They run on V8 isolates — the same lightweight sandboxing that lets your browser keep dozens of tabs separated inside one process. Starting an isolate takes under 5 milliseconds and a few megabytes of memory.

The practical consequences:

  • No meaningful cold starts. A Worker that hasn't run in a week responds as fast as one running constantly.
  • No idle cost. You pay per request, not for a server waiting around.
  • Genuinely global by default. There is no "which region should I deploy to?" decision, because the answer is all of them.

What Workers Are Good At

Serving and shaping requests at the edge

Workers sit in front of your origin, so they can act on every request before it travels anywhere: redirects, custom headers, rewriting URLs, routing old paths to new ones, blocking abusive traffic. This is logic that would otherwise live in your server or a config file you're afraid to touch.

API endpoints that stay quick everywhere

Form handlers, webhook receivers, lightweight APIs, proxying a third-party service so you don't expose your API key to the browser. These are small pieces of code with global audiences — exactly the shape Workers fit.

Personalisation without slowing the page down

This is where the edge earns its keep for marketing sites. Your pages are static and served from cache. A Worker can still adjust them per visitor before delivery — showing local currency, the right language, the appropriate regional phone number — because it knows the visitor's country and runs at wire speed.

You keep static-site performance and still get relevant content. Without the edge, you'd have to pick one.

A/B tests that don't flicker

Client-side testing tools work by loading the page, then swapping content with JavaScript. That's why you sometimes see the original version flash before the variant appears — and why those tools drag down Core Web Vitals.

A Worker assigns the variant before the HTML is sent. The visitor only ever sees one version. No flicker, no layout shift, no extra script on the page.

Image and asset transformation

Resize, crop, and convert images to modern formats on the fly, at the edge, cached after the first request. One high-resolution original serves every device at the right size.

The Pieces Around Workers

Workers alone are just compute. Cloudflare pairs them with storage that lives on the same network:

  • KV — a key-value store, replicated globally. Fast reads everywhere, eventually consistent. Good for configuration, feature flags, cached lookups.
  • R2 — object storage for files and media, with no egress fees. This is the notable one: bandwidth charges are usually what makes storing large assets expensive.
  • D1 — a SQL database (SQLite-based) for structured data.
  • Durable Objects — coordinated state for things that need a single source of truth, like a chat room or a live counter.
  • Queues — for work that shouldn't block the response, like sending an email after a form submission.

Together these cover most of what a typical web application needs, without a traditional server anywhere in the picture.

The Constraints (Read These Before You Commit)

Workers are deliberately limited, and the limits are the price of the speed.

CPU time is capped. Each request gets a limited slice of CPU (generous on paid plans, tight on free). Workers are for fast request handling, not video encoding or heavy data processing.

It's not Node.js. Workers implement web-standard APIs — fetch, Request, Response, crypto. Node compatibility has improved a lot, but libraries that assume filesystem access or native modules may not work. Check your dependencies before planning a migration.

Bundle size is limited. A few megabytes after compression. Fine for most application code, not for shipping a large machine-learning model.

No long-lived connections to a traditional database. Classic connection pooling assumes a persistent server. Workers are ephemeral and everywhere. Use Cloudflare's own storage, or a database with an HTTP driver, or a connection pooler built for serverless.

You are choosing a platform. Worker code is portable in principle, but KV, R2, D1, and Durable Objects are Cloudflare-specific. Migrating away means rewriting that layer.

Should You Use Them?

A reasonable rule of thumb:

  • Yes, clearly — if you need global low latency, edge personalisation, request-level logic, or you're already on Cloudflare's CDN.
  • Maybe — if you're building an API and want to skip server management entirely.
  • Probably not — if you have a large existing Node application with heavy dependencies, need long-running processes, or your workload is CPU-intensive.

For most marketing sites and content platforms, the sweet spot is narrow but valuable: static pages on a CDN, with a Worker handling the handful of things that genuinely need to be dynamic.

The Shift Worth Noticing

The old model was: one server, one location, everyone travels to it. The edge model is: your code lives near your users, and distance stops being a tax you pay on every request.

For a business with customers in more than one country, that's not a technical detail. It's the difference between a site that feels local everywhere and one that feels far away for most of the world.

We build edge-first sites and applications at Growthscope — fast in every market, not just the one nearest the server. If your site is slow for customers abroad, book a 15-minute call and we'll show you where the time is going.