When static at the edge beats edge rendering
On this surface every leaf is identical for every visitor. Cloudflare cached HTML serves at the edge in twenty to thirty milliseconds globally. An edge-rendered version that recomputes the page from a slug manifest would add ten to forty milliseconds of compute per request and earn nothing in return; the output is byte-identical. The Lighthouse SEO and Core Web Vitals scores on this surface are 98 to 100 because the static-at-edge approach hits both LCP and TTFB targets without effort. For a surface with no personalization, do not enable edge rendering.
When edge rendering wins: locale and segment
If your leaves are personalized by locale (currency, language, regulatory disclaimer) edge rendering lets you serve the right variant from the request's geography without a redirect. On a separate engagement we ship a Kenyan SaaS surface where the currency displayed switches between KES and USD based on the Cloudflare CF-IPCountry header; the variant is computed at the edge in roughly five milliseconds. The static-cache approach would have required a redirect chain (origin to /locale-aware/ to final URL) adding two hundred milliseconds to first paint.
The cold-start trade-off
Edge workers have per-region cold-starts; the first request to a region after idle pays a fifty to one-hundred-fifty millisecond startup cost. On a low-traffic surface with global distribution, this cost is paid more often than on a high-traffic centralized surface. The math: if your surface sees fewer than ten thousand requests per region per day, the cold-start tax averages over more requests than the latency benefit; static-at-edge is better. Above ten thousand requests per region per day, the worker stays warm and the cold-start tax disappears. We have not enabled edge rendering on this surface for exactly this reason.
