Why Every Site I Build Runs on Cloudflare's Edge

When I tell a prospect that every site I build deploys to Cloudflare’s edge, I sometimes get a polite nod that means “the developer is talking about hosting again.” So this post is the business case, with numbers, for treating where your site runs as the first performance decision, made before a line of code is written, rather than an IT afterthought.

TTFB is the floor under every other metric

Every speed metric you have heard of, First Contentful Paint, Largest Contentful Paint, all of them, sits on top of one number: time to first byte. The browser cannot paint what it has not received. Google’s guidance at web.dev is direct about this: TTFB precedes the user-centric metrics, and most sites should keep it at 0.8 seconds or less, with anything over 1.8 seconds rated poor.

Here is the part that gets skipped in hosting conversations: TTFB is mostly geography and architecture. When your site lives on one server in one data center, every visitor outside that region pays a distance tax on every request, before your page weight, your images, or your code quality get a vote. You can optimize a page forever and never fix a first byte that spends 600 milliseconds crossing an ocean or waiting on a busy shared host.

And the business stakes of those milliseconds are documented. The Google and Deloitte “Milliseconds Make Millions” study measured what a 0.1 second improvement did on real retail sites: conversions rose 8.4% and average order value rose 9.2%. Google’s mobile benchmark research runs the other direction: as load time goes from 1 second to 3 seconds, bounce probability increases 32%.

What “the edge” actually means

The edge is a simple idea with a lot of marketing around it: instead of one server in one place, your site is rendered and served from a network of data centers, and each visitor is answered by the one nearest to them.

Cloudflare’s network, per its own network page, spans 337 cities in over 100 countries, and 95% of the world’s Internet-connected population is within 50 milliseconds of a Cloudflare data center, most within 20. When a site is deployed to Cloudflare Workers, that whole network is the server. A visitor in Knoxville, a visitor in London, and a visitor in Sydney each get answered locally.

That is the whole trick. There is no cleverness that beats being close.

What it looks like on my builds

I would rather show a measured number than an adjective, so here is one. On June 15, 2026, I measured this site, betteroffgrowth.com, an AstroAstroAstro is a modern web framework for building fast, content-driven websites that ship zero JavaScript by default. build rendered on Cloudflare Workers, from East Tennessee: TTFB came back between 130 and 200 milliseconds across five consecutive runs. That is one location on one day, so treat it as an illustration rather than a benchmark, but it is a sixth of Google’s 0.8 second threshold, with margin for visitors much farther from a data center than I am.

Two decisions produce that number, and they compound. The hand-coded Astro build keeps the page itself nearly weightless, and the edge deployment makes the first byte arrive from nearby. Either one alone helps. Together they are why I do not have to buy “speed optimization” back after launch. If you want the deeper background on why these thresholds matter for a business site, I have written a full guide to Core Web Vitals for B2B leaders.

Enterprise infrastructure at small-business cost

A decade ago, this posture, hundreds of points of presence, DDoS absorption, global caching, was an enterprise CDN contract with an enterprise invoice. Today the same physical network is available to a five-person business, priced near zero for the traffic most marketing sites actually see.

That economic shift is quietly part of how my pricing model works. Sites I build have effectively no marginal infrastructure cost: no server to rent, patch, or babysit, no hosting margin to pass along. That is a real reason the $0-upfront build model stays viable. I am not reselling hosting with a markup; the architecture removed most of what there was to mark up.

The catch, and it is a real one, is that the site must be built for this. A legacy page-builder site dragging a database and a plugin stack cannot simply be relocated to the edge. The build decision and the deployment decision have to be made together, which is exactly why I make them together.

When the edge is not the answer

Edge-first deployment is the right call for marketing sites, content sites, and most lead-generation properties, which is to say, the sites I build. It is not automatically right for everything:

• Heavy server-side compute like long-running jobs, big report generation, and machine-learning workloads belongs on infrastructure built for sustained compute, not edge functions.
• Region-pinned data is another case: if regulation or architecture requires your data to live and be processed in one jurisdiction, a globally distributed runtime adds complexity instead of removing it.
• Apps that are mostly database gain little, because when nearly every request is a round trip to a single-region database, the edge moves the rendering closer but not the data. Real application builds deserve their own architecture conversation.

None of those describe a marketing site. For the site whose job is to load instantly for a stranger and turn them into a lead, the edge is simply where that job is easiest to do well.

If you want the short version of how this fits into my builds, this is what the Cloudflare work looks like.