Prefetch

Use `<link rel=prefetch href=/lesson-4.js>` or a router that prefetches on link hover or when a link enters the viewport. In DevTools, prefetched requests show Lowest priority. The next page's matching request then reads from the prefetch or disk cache with near-zero time.

Success is measured on the next page: compare its load for sessions that were prefetched against those that were not. Waste is measured in bytes: files fetched and never used, which you can estimate by comparing prefetch requests with the navigations that actually followed.

A course site's lesson 3 page ends with a 'Next lesson' button. Lesson 4 weighs 180 KB of HTML and JS. Prefetching it once lesson 3's video passes 80% fetches it during idle time, and the click opens lesson 4 in 210 ms instead of 1.1 s on 4G.

Of 1,000 viewers, 620 click through and 380 downloaded 180 KB for nothing, about 68 MB across the batch. The team keeps the prefetch but skips it when the visitor has Save-Data on.

Prefetch is for the next navigation and runs at idle priority. Preload is for the current page and runs at high priority. Using prefetch for something the current page needs just delays it, and using preload for a future page steals bandwidth from what the visitor is looking at now.

Prefetching on metered or Save-Data connections. Prefetching every link in a 200-link footer. Expecting it to work on responses marked `no-store`. Forgetting that prefetch requests show up in server logs and can inflate raw request counts. Using it for resources the current page needs.

Start with the one link most visitors click next: the primary call to action or the 'next article'. Prefetch on hover or when the link enters the viewport, skip it when `navigator.connection.saveData` is true, and compare server logs for prefetched URLs that were never followed.