Firefox Prefetch: How the Link Header Boosts Page Load and When to Use It

Why Prefetch Matters in Firefox

When a user clicks a link, the browser usually waits to request the new page’s assets until after the navigation starts. Firefox can break that pattern: if the server sends a Link header with rel=prefetch, the browser will start downloading the referenced resource in the background, even before the user follows the link. The result is a lower perceived latency for the next page.

What Firefox Accepts

• Only same‑origin URLs are prefetched automatically. For cross‑origin URLs you must also expose the resource with Access-Control-Allow-Origin (CORS).
• Firefox limits prefetch to MIME types considered safe for background download: text/css, application/javascript, image/*, and a few others. Unknown types are ignored.
• In battery‑saving or data‑saving modes the feature is throttled or disabled to conserve resources.

How to Enable Prefetch in Practice

1. Add the Link header to your HTTP response. A minimal example:

HTTP/1.1 200 OK
Content-Type: text/html
Link: <https://example.com/critical.js>; rel=prefetch

<!DOCTYPE html>…

2. Serve the referenced asset from the same origin or add CORS headers if it lives elsewhere:

HTTP/1.1 200 OK
Content-Type: application/javascript
Access-Control-Allow-Origin: *
…

3. Verify in Firefox:
   • Open Developer Tools (F12) → Network panel.
   • Reload the page. You should see a request with Type: prefetch before the page finishes loading.
   • Check the console for a log entry: Prefetching https://example.com/critical.js.
4. Disable data‑saving mode in about:preferences#general to ensure the request is issued during testing.

When to Use Prefetch vs. Preload

Prefetch is ideal for resources that the user is likely to need soon but aren’t critical to the current page render. For example, a script that the next page will execute, or a CSS file for a modal that appears after a click. Preload (rel=preload) should be reserved for assets that the current page needs immediately.

Trade‑offs and Limitations

• Bandwidth waste: If the user leaves the page quickly, Firefox may abort the prefetch, but the request still consumed bandwidth. On metered connections this can be costly.
• No guarantee of completion: Prefetch requests are best‑effort; they may finish after navigation or be canceled if the network is slow.
• Mobile throttling: In battery‑saving or data‑saving mode, Firefox disables prefetch, so performance gains disappear on mobile devices.
• Same‑origin restriction: Cross‑origin prefetch requires appropriate CORS headers, otherwise Firefox will ignore the header.

Practical Checklist Before Deploying Prefetch

• Identify assets that are used on the next page but not needed immediately.
• Ensure those assets are served from the same origin or expose them via CORS.
• Test in a non‑data‑saving environment to confirm the request appears as prefetch in DevTools.
• Monitor network usage on real devices to detect excessive prefetching.
• Pair prefetch with preload for high‑priority assets to avoid race conditions.

Conclusion

Firefox’s Link header rel=prefetch is a low‑friction way to reduce perceived latency for the next page. By adding a single header you can have the browser start downloading critical assets in the background. Just remember the trade‑offs: use it sparingly, test on mobile, and pair it with preload for the highest‑priority resources.