Some organizations move page composition from an origin application server to the CDN edge, using platforms like Cloudflare Workers or Fastly Compute, instead of a traditional origin-based composition service. What does moving composition to the edge actually change about latency and failure behavior, and what new constraints does the edge runtime environment impose that don't exist on an origin server?

## Where the composition step runs **Origin-based composition** runs the fragment-fetch-and-stitch step on the application's own servers, typically in one or a small number of data center regions. Even after that composition finishes, the assembled response still has to travel the public internet back to wherever the browser actually is — a user far from the origin region pays that long-haul round trip regardless of how fast composition itself was. **Edge composition** moves the identical logical step — fetch fragments, stitch them into one response — onto CDN points-of-presence distributed globally, so the server the browser talks to for composition is physically close to it. Platforms built for this, such as Cloudflare Workers and Fastly's Compute product, run the composition code inside a lightweight, fast-starting sandbox replicated across hundreds of points-of-presence, so the same composition function executes near the user regardless of which region they're in. | Property | Origin-based composition | Edge composition | |---|---|---| | Where it runs | one or a small number of data center regions | CDN points-of-presence distributed globally | | Browser round trip | the assembled response travels the public internet back | physically close to the user | | Compute | a normal VM or container with a full OS | hard limits on CPU time per request | | Runtime surface | a full server-side runtime like Node.js | a lightweight, fast-starting sandbox | | Cache | one origin, one cache | hundreds of points-of-presence for a purge to propagate to | ## The latency win, precisely The latency win is specifically about the browser-to-composition-layer round trip and, if fragments themselves can also be served or cached at the edge, the composition-to-fragment round trip too — both of which shrink dramatically compared to everything happening in one origin region. ## The constraints are structural That win is not free, and the constraints are structural, not just tuning knobs. Edge compute platforms enforce hard resource limits per request that a traditional origin server, a normal VM or container with a full OS, doesn't: - **CPU time.** These platforms typically cap CPU time per request in a small range on their base tier, with paid tiers extending it, as a way to keep the shared multi-tenant edge fleet fair and fast, not to offer generous general-purpose compute. A composition function that has to parse, transform, and reassemble several fragments' HTML, run any templating logic, and manage several concurrent outbound fetches has meaningfully less headroom to do that work than the same logic running on a dedicated origin composition service, so teams moving composition to the edge often have to actively simplify the composition logic to fit the budget. - **Runtime API surface.** It is also narrower than a full server-side runtime like Node.js — these platforms don't give a full filesystem, arbitrary native modules, or every server-side built-in, so composition code or its dependencies that assume a full Node environment often need porting or can't move to the edge at all without rework. ## Fragment locality and cache coherency The fragment-fetch side of the equation is where a subtle new failure mode shows up: edge composition only wins on latency if the fragment backends it calls out to are also fast to reach from wherever the edge node executing that request happens to be. If a fragment's backend lives in a single origin region and the edge composition function executing on the other side of the world has to call all the way back to that region for that fragment on every request, the edge win evaporates for exactly the users it was supposed to help most — the composition step is now local, but the slowest leg of the journey, edge-to-fragment-backend, hasn't moved, and can even get worse if the call now transits through additional routing hops. This makes edge composition's real payoff conditional on either: - the fragment backends themselves being multi-region or edge-deployed too, - or aggressive per-fragment caching at the edge so most requests are served from a nearby cache rather than a live cross-region call. And cache coherency across hundreds of points-of-presence is itself harder than at one origin: a cache purge or a personalization update has to propagate globally, and different points-of-presence can transiently serve different fragment versions to different users during that propagation window, a form of staleness that's structurally harder to reason about than a single origin server's cache. ## The failure and cost model Operationally, this also changes the failure and cost model an organization has to own. - **CPU-time-limit violations** at the edge fail fast and hard, since the request is simply terminated, so composition logic bugs that would merely be slow on an origin server can become outright failures at the edge, and debugging them means understanding a sandboxed, geographically-distributed runtime rather than a single box. - **Cost** is also typically metered per-invocation across a much higher effective request volume, since edge functions run per point-of-presence, closer to raw request count, rather than behind a smaller number of origin instances that can batch or amortize work, so a composition strategy that's cheap at moderate traffic can get materially more expensive at scale in a way that needs modeling before committing to it. ## The judgment call Principal-level judgment here means recognizing that moving composition to the edge is not a drop-in performance upgrade — it's a genuine architectural trade of one latency source, the origin round trip, for a new set of constraints: - compute budget, - narrower runtime, - fragment-backend locality, - and cross-region cache coherency, that only pays off once the fragment backends and caching strategy are redesigned to match.