Performance
preload, prefetch and fetchpriority: which one to use
preload fetches a critical resource early, prefetch prepares the next page, fetchpriority changes the order. Three different tools and three mistakes.
Key points
- preload serves the current page, prefetch serves the next navigation, fetchpriority changes the priority of a request already in the markup.
- The site home page declares 5 preloads, all fonts, measured on 1 November 2026.
- A preload without the right crossorigin downloads the font twice.
preload fetches a resource this page needs right now, prefetch prepares a resource for the next page, fetchpriority changes the priority of a request already in the HTML. They are three different tools and they replace each other badly.
The three directives in one table
| Directive | What it does | When to use it |
|---|---|---|
rel="preload" | fetches now at high priority | fonts, the LCP image, critical CSS |
rel="prefetch" | fetches at low priority, for later | the likely next route |
fetchpriority | raises or lowers the priority of an existing request | the LCP image already in the markup |
Mistake one: preload everything
Every preload competes with the other requests. With five of them the browser puts them ahead of the CSS and the page waits for the wrong file. A preload unused after 3 seconds logs a console warning.
curl -s https://ui.eneawork.it/ | grep -o 'rel="preload"' | wc -lThe command counts the preloads declared in the served HTML. On the home page the result is 5 and they are all fonts: no image needs an extra preload.
The preload that downloads twice
A preload without as, or with a crossorigin value different from the tag that reuses it, produces two requests. Fonts always need crossorigin, even when they come from the same domain.
The first line pulls the font forward. The second marks the LCP image without adding a request, because the browser finds it in the markup anyway.
prefetch: when it pays off
prefetch spends bandwidth on a page the visitor may never open. Use it on one route with a high chance, for example the pricing link on the home page, and never on mobile data.
The limitation
These directives are hints: the browser may ignore them and change priority by connection and viewport. HTTP/2 ordering matters too, so a higher priority in the markup does not guarantee an earlier arrival.
Where to continue
The EneUI catalogue indexes 111,985 components and 12,808 icons with previews. The record scroll expansion hero is a hero with a large image: this is the case where a preload is worth measuring. For lazy loading read when lazy loading hurts, for the thresholds Core Web Vitals, for images in Next.js next/image.
Frequently asked questions
Should I preload a font?
Yes, if the font is the one used by the LCP element. The preload must declare as="font", type and crossorigin, otherwise the browser downloads the file twice.
Does preload replace fetchpriority?
No. preload creates an early request, fetchpriority changes the priority of a request that already exists in the HTML. On the LCP image fetchpriority is usually enough.
Is prefetch harmful?
It can be: it spends bandwidth and cache on a page the visitor may never open. Keep it to one likely route and make it lighter on mobile.
Why does the console report an unused preload?
Because the file was fetched and never requested within a few seconds. The usual causes are a duplicated preload, a wrong as value, or a resource the layout no longer uses.
Does this work in Safari?
preload and prefetch are supported; fetchpriority arrived later and older versions ignore it without errors. The worst case is the default order.