v138 · network / connectivity

Pass 'Sec-Purpose: prefetch' header with <link rel=prefetch>

Chrome 138 brings <link rel=prefetch> in line with speculation rules prefetch: speculative link requests now carry Sec-Purpose: prefetch, giving servers a standard signal for slim responses, analytics suppression, and bandwidth budgeting.

concepts

  1. Sec-Purpose Header

    <link rel=prefetch> now sends Sec-Purpose: prefetch. Servers can detect speculative fetches and tune their response.

  2. Server tuning

    A server-side decision tree: skip A/B bucketing, skip analytics, return a slimmer body for speculative GETs, run full path for real navigations. The point of the header.

  3. Header trace

    Side-by-side: three different prefetch mechanisms (<link rel=prefetch>, speculation rules, plain fetch()) traced through a Service Worker. Compatibility matrix included.

  4. Prefetch budget monitor

    Run a server-backed bandwidth budget policy that uses Sec-Purpose: prefetch to identify speculative fetches, serve slim responses, and block fetches that exceed the per-origin quota. Timeline shows each server decision with byte savings vs the full-render path.

why it shipped

Before this change, speculation rules prefetches already sent Sec-Purpose: prefetch, while <link rel=prefetch> only exposed the older Purpose: prefetch signal. Chrome 138 standardizes the link path on Sec-Purpose, so servers can distinguish regular requests from resource hints with one fetch metadata header.

references