v138 · performance · headers
Prefetch Budget Monitor
Run a local server-side budget policy that uses Sec-Purpose: prefetch to identify speculative fetches, serve slim responses, and enforce per-origin bandwidth quotas. Watch how speculative vs real requests are handled differently — and how the header lets the server make that distinction.
Prefetch queue
Bandwidth used: 0 / 80 KB
Server response log
—
Click "Run server-backed wave" to start.
/* <link rel=prefetch> sends Sec-Purpose: prefetch */
<link rel="prefetch" href="/product/123">
// Server (Deno) — detect speculative fetch and serve slim
const secPurpose = req.headers.get("sec-purpose");
const purpose = req.headers.get("purpose"); // legacy compatibility
const isPrefetch = `${secPurpose ?? ""} ${purpose ?? ""}`.includes("prefetch");
if (isPrefetch) {
// Return a lightweight stub — skip A/B bucketing,
// skip analytics write, return slimmer HTML body
return res.send(slimResponse);
}
// Full render path for real navigations
return res.send(fullRender);
Why this matters: This page hits a real local JSON endpoint under
./budget-endpoint; the server records the request headers, applies an 80 KB
speculative budget, and returns its decision. Before Chrome 138, servers had no reliable way to
distinguish a <link rel=prefetch> request from a real navigation. Now
Sec-Purpose: prefetch is a first-class header. Servers can return a slim
response (smaller HTML, no analytics write), enforce per-origin bandwidth budgets, skip A/B
experiments on speculative loads, and accurately measure "real" page views vs speculative
ones — all using the standard header that Chrome 138 attaches automatically.