demo · v133
Prefetched resources now obey Cache-Control
Pre-133, a prefetched resource was kept in the prefetch cache for 5 minutes regardless of HTTP cache semantics — no-store, max-age=0, all ignored. From 133 the prefetch cache obeys the same rules as the regular HTTP cache, restoring interop with Firefox and Safari.
cacheable for 1 hour
Cache-Control: max-age=3600
prefetch survives. always did.
no-cache (must revalidate)
Cache-Control: no-cache
old: served for 5 min anyway. new: revalidated.
no-store
Cache-Control: no-store
old: served for 5 min. new: dropped immediately, second request goes to network.
| scenario | pre-133 | 133+ | cross-browser |
|---|---|---|---|
| max-age=3600, second use 10s later | served from prefetch | served from prefetch | consistent |
| max-age=0, second use 10s later | served (5-min rule) | refetched | now consistent with FF/Safari |
| no-store, second use 10s later | served (5-min rule) | refetched | now consistent |
| any cache, second use 6 minutes later | refetched | depends on Cache-Control | depends |
migration tip
If your app set explicit prefetch and assumed the resource would be there for "a while", double-check the upstream Cache-Control. Static assets are usually fine (they're already cacheable). API responses prefetched for speculative paint may want a small max-age rather than no-store.