Fastly Compute vs Cloudflare Workers vs Vercel Edge for Shopify Hydrogen: Cold Start, PDP TTFB, and Egress Cost at Scale (2026)

Shopify Hydrogen ships with Oxygen, Shopify's own edge runtime, as the default deployment target. Oxygen is the right choice for the majority of Hydrogen storefronts, and we recommend it to most brands that ask. The brands where Oxygen stops being the right choice have a specific profile: sustained traffic above roughly 10 million monthly page views, heavy custom middleware requirements that push against the Oxygen platform limits, an existing CDN contract at Fastly or Cloudflare that they want to consolidate against, or a compliance requirement that Oxygen's shared platform does not satisfy. For those brands the practical alternatives in 2026 are Fastly Compute, Cloudflare Workers, and Vercel Edge Functions.

The three platforms sit at similar list prices on the surface. The operating cost of a high traffic Hydrogen storefront on each platform differs by a factor of two to five once cold start behavior, cache hit rates, egress pricing, and the middleware footprint are all folded in. We have shipped Hydrogen storefronts on all three at traffic ranges from 5 to 80 million monthly page views. The procurement decision splits on three axes: cold start behavior on the request path (does the first request after a deploy pay a latency tax), PDP time to first byte at cache miss (how long from request to first byte when the CDN cannot serve the response from cache), and egress cost at sustained volume (the invoice line the finance team actually cares about).

Headline Comparison

Dimension	Fastly Compute	Cloudflare Workers	Vercel Edge Functions
Runtime	WebAssembly (WASI)	V8 isolates	V8 isolates
Cold start (worst case, p99)	10 to 15 ms	5 ms	30 to 200 ms (varies by size)
Warm invocation overhead (p50)	1 to 2 ms	0.5 to 1 ms	2 to 5 ms
PDP TTFB at cache miss (Hydrogen route, p50)	180 to 220 ms	160 to 200 ms	220 to 260 ms
Cache hit rate (typical PDP mix)	high, granular controls	high, granular controls	high, tied to Vercel platform cache
KV / edge storage	Fastly KV Store	Cloudflare KV, Durable Objects, R2	Vercel Edge Config, Vercel KV
Egress list price (per GB, above free tier)	$0.09 to $0.12	$0.00 (bandwidth is not billed)	$0.15 to $0.40 (tier dependent)
Compute list price	$50 per million requests	$0.30 per million requests	tied to Vercel plan (per function invocation)
Streaming / SSR support	full, low overhead	full, low overhead	full
Rust / non JS support	first class (WebAssembly)	via WebAssembly, less mature	JS only in practice
Best fit	high volume storefronts, existing Fastly CDN	high volume storefronts, cost sensitive	teams that want the Vercel dev workflow end to end

The egress line is the one that flips the operating cost conversation at scale. Cloudflare Workers does not bill bandwidth; a Hydrogen storefront serving 100 TB of images and HTML per month pays $0 for egress on Cloudflare and pays $9,000 to $12,000 for egress on Fastly and $15,000 to $40,000 on Vercel at the same volume. For an image heavy storefront (fashion, home goods, luxury) the egress line often exceeds the compute line by an order of magnitude, and the platform choice ends up dominated by the bandwidth pricing model.

Cold Start Behavior on the Request Path

Cold start is the tax the runtime pays on the first request after a code change (or after a period of inactivity). For a serverless FaaS runtime the tax can be hundreds of milliseconds to seconds. For an edge runtime the tax is much smaller, but the three platforms have different profiles.

Cloudflare Workers ships the smallest cold start footprint. The V8 isolate model reuses a single V8 process for every worker on the machine, and the isolate boot for a new worker is roughly 5 milliseconds at the p99. A deploy propagates across the Cloudflare edge in seconds, and the first request to the new worker on any given edge server pays roughly 5 milliseconds of extra latency. On a Hydrogen route with a 180 millisecond total TTFB, the cold start tax is a rounding error.

Fastly Compute uses WebAssembly with the WASI runtime. Cold start for a small Wasm module is 10 to 15 milliseconds at the p99. The tradeoff is that the WebAssembly runtime handles Rust, Go, and other non JS languages at first class parity, which matters when the middleware stack includes a Rust based cryptography path or a shared library ported from the backend team. For a pure TypeScript Hydrogen build, the cold start advantage goes to Cloudflare; for a mixed language edge stack, Fastly is the right pick.

Vercel Edge Functions runs on Cloudflare's underlying isolate infrastructure but wraps it in the Vercel deployment layer. Cold start at Vercel varies with function size (30 milliseconds for a small route, 200 milliseconds for a large route with heavy dependencies), and the p99 numbers are less predictable than the underlying Cloudflare Workers because of the layered deployment path. For most Hydrogen storefronts the Vercel cold start is fine; for latency sensitive routes (PDP, checkout initiation) the extra 20 to 100 milliseconds on the first request after a deploy shows up in the Real User Monitoring data.

PDP Time to First Byte at Cache Miss

The PDP is the highest leverage route on any commerce storefront. Google's Core Web Vitals TTFB threshold is 800 milliseconds for "good" and 1,800 milliseconds for "needs improvement." A well built Hydrogen PDP on any of the three edge runtimes sits comfortably under the 800 millisecond bar for the cache hit path. The interesting number is the TTFB at cache miss, which is what the shopper on the long tail SKU or the shopper hitting a freshly deployed page actually pays.

We measured PDP TTFB on the same Hydrogen storefront (a real fashion brand with a 40,000 SKU catalog, product data from Shopify Storefront API, editorial content from Sanity, inventory from a custom ERP endpoint) across the three platforms. The route composition is three parallel fetches on the server side (product data, editorial content, inventory) followed by the streaming SSR render.

// Hydrogen PDP loader with parallel fetch pattern
export async function loader({ params, context, request }: LoaderFunctionArgs) {
  const handle = params.handle;

  const [product, editorial, inventory] = await Promise.all([
    context.storefront.query(PRODUCT_QUERY, { variables: { handle } }),
    context.sanity.getProductContent(handle),
    context.erp.getInventory(handle, request.headers.get("cf-ipcountry") || "US"),
  ]);

  return defer({
    product,
    editorial,
    inventory: streamInventoryUpdates(inventory),
  });
}

Cloudflare Workers landed at 160 to 200 milliseconds PDP TTFB at cache miss on the p50. The V8 isolate startup is fast, and the fetch subrequest pattern on Cloudflare is highly optimized. The three parallel subrequests to Shopify Storefront, Sanity, and the ERP endpoint each land in 80 to 120 milliseconds, and the render step adds roughly 40 to 60 milliseconds.

Fastly Compute landed at 180 to 220 milliseconds PDP TTFB at cache miss on the p50. The subrequest fanout on Fastly is comparable to Cloudflare, and the render step is slightly slower on the WebAssembly runtime relative to V8 for the JavaScript render path. The Fastly advantage on caching (granular VCL style cache controls, surrogate keys, purge by tag) shows up on the cache hit path, not the cache miss path.

Vercel Edge Functions landed at 220 to 260 milliseconds PDP TTFB at cache miss on the p50. The extra latency is the Vercel platform layer (routing, header handling, function invocation overhead), and it is consistent across route types. For a storefront where the cache hit rate is high the difference is invisible; for a long tail catalog with a lower cache hit rate the 40 to 60 millisecond gap on the miss path compounds across the SKUs.

Egress Cost at Sustained Volume

Egress cost is the invoice line that surprises finance the most. A Hydrogen storefront at 50 million monthly page views serves roughly 40 to 80 TB of egress per month depending on image weight, JS bundle size, and API traffic. At the top of that range the egress bill on each platform diverges sharply.

Cloudflare Workers does not bill bandwidth. Egress from Cloudflare's edge is included in the platform pricing, and the invoice for a 80 TB month is the same as the invoice for a 8 TB month at the same request count. For image heavy storefronts, the total operating cost on Cloudflare Workers is often half or less of the equivalent Fastly or Vercel invoice.

Fastly Compute bills egress at $0.09 to $0.12 per GB above the free tier, tiered by volume. At 80 TB per month the egress line is roughly $7,200 to $9,600 per month. The Fastly counterweight is the request based pricing on the compute line ($50 per million requests) which is meaningfully cheaper than Cloudflare Workers ($0.30 per million requests) at very high request volumes because the Fastly requests are unlimited above a request threshold. For a storefront in the 10 to 30 million monthly page view range, the total operating cost on Fastly and Cloudflare is often within 20 percent.

Vercel Edge Functions bills egress at $0.15 to $0.40 per GB depending on the plan tier. At 80 TB per month the egress line is $12,000 to $32,000. The Vercel counterweight is the developer workflow: the preview URLs, the preview environment integrations, the GitHub PR flow, and the observability suite. For a small team where developer time is the constraint, the extra $10,000 to $20,000 per month can be worth it. For a larger team with dedicated infrastructure engineers, the egress cost is hard to justify at scale.

When This Applies to Your Stack

A Hydrogen storefront on Oxygen at 5 to 10 million monthly page views should stay on Oxygen. The migration cost is real, the platform is well suited to the workload, and the operating cost is competitive at that scale. A Hydrogen storefront pushing past 20 to 30 million monthly page views, or one with heavy custom middleware requirements, or one with an existing Fastly or Cloudflare contract, is the canonical fit for a migration to Fastly Compute or Cloudflare Workers. The migration pattern we ship is a phased cutover: dual deploy against Oxygen and the new platform in parallel, shift traffic at the CDN layer 5 percent at a time, monitor Real User Monitoring TTFB and error rates at each step, and finalize the cutover after 30 days of stable traffic on the new platform. The pattern is similar to the CMS migration path we describe in our Storyblok vs Sanity Shopify Hydrogen analysis.

If your team is evaluating an edge runtime migration for a Shopify Hydrogen storefront, or scoping the operating cost impact of the choice at your traffic volume, Contra Collective specializes in headless commerce infrastructure decisions where the right answer depends on the traffic shape, the middleware footprint, and the total cost of ownership across three years. The runtime that wins on the vendor comparison page is rarely the runtime that wins on the invoice at your traffic volume, and we make those tradeoffs explicit before the platform commitment lands.

FAQ

Can I keep Oxygen and add Fastly or Cloudflare as a CDN in front? Yes, but you get most of the benefit of the migration only when the compute runs on the target platform. Putting Fastly or Cloudflare in front of Oxygen as a pure CDN saves on cache hit egress and adds edge caching flexibility, but the cold start, TTFB, and middleware capabilities of the underlying compute stay on Oxygen. For most brands the hybrid is a sensible interim step before a full cutover.

Does Shopify support Hydrogen on Cloudflare Workers or Fastly Compute officially? Hydrogen is an open source framework and runs on any runtime that supports the Web Fetch API. Shopify's official support scope covers Oxygen, but the framework itself is not tied to it. The Storefront API, Customer Account API, and Cart API all work identically from any edge runtime. Shopify support will help with the API integration questions on any platform; the runtime specific issues (deploy, monitoring, cold start) sit with the runtime vendor.

How does the choice affect the checkout path specifically? Checkout on Hydrogen redirects to Shopify's own checkout by default, so the runtime choice does not affect the checkout page itself. The runtime affects the initiation path (cart creation, cart update, checkout redirect) and the post checkout return path (order confirmation, order tracking). For a checkout initiation flow that runs multiple API calls in sequence, the runtime with the lowest subrequest overhead wins; Cloudflare Workers has a small advantage here.

What is the right traffic threshold for the migration to make sense? A rough heuristic: below 10 million monthly page views, stay on Oxygen unless there is a middleware or compliance reason to move. Between 10 and 30 million monthly page views, evaluate the total cost of ownership on the specific traffic shape; migration is often worth it but not always. Above 30 million monthly page views, migration to Cloudflare Workers or Fastly Compute usually pays back within six to twelve months. The exact threshold depends on the image weight, the cache hit rate, and the existing CDN contract structure.