Resource hints: preload and preconnect.
Resource hints are directives that tell the browser in advance which resources will be needed early or which servers it will connect to.
While loading a page, the browser requests resources in the order it discovers them, and discovery advances as the document is parsed. Some resources are discovered far down that chain — a font referenced inside a stylesheet is known only after the stylesheet has downloaded and been parsed. Resource hints exist to shorten that delay.
But every hint is a claim of priority, and priority is a relative concept. Prioritizing everything yields the same result as prioritizing nothing — and the genuinely critical resource starts competing with the others for bandwidth.
Four hints, four different jobs
- Preconnect — the connection to the named server is established in advance. DNS resolution, handshake and the security negotiation are settled up front.
- DNS prefetch — only the resolution is done, no connection opened. Cheaper, but less gain.
- Preload — the named resource downloads at high priority but is not executed immediately. Closes the discovery delay.
- Prefetch — a resource the user will need on the NEXT page downloads while idle. A different purpose: navigation speed.
The first two are for connection costs and make sense only for external domains. The connection to your own server is already established; preconnecting to it gains nothing. That is the most common needless hint.
The third is the most powerful and the most dangerous. Applied to the right resource it lowers LCP measurably; applied to the wrong resource, or to too many, it slows the genuinely critical one.
How many, and which
The practical rule: the number of resources worth preloading on a page is usually one or two. The candidates are known — the LCP image, or the critical font when text is the LCP element.
On this site the fonts are served from the site’s own domain, so no external connection hint is needed; the content security policy blocks external resource requests anyway. The resource hint list is therefore short, and every entry has a rationale.
And a measurement rule: after a hint is added, its effect MUST be measured. Hints look intuitively right, and intuition misfires here often — a preload can raise LCP instead of lowering it, because it delayed another resource. A hint added without before-and-after measurement remains a guess.
A resource hint is not added on intuition; the before and the after are measured.
Priority declaration
A newer tool allows declaring a resource’s priority directly: an image can be given high priority, or a script’s priority lowered. This is a lighter intervention than the preload hint because it produces no extra request — it only changes the ordering.
Its most common use is the hero image: with high priority on the image tag, the browser downloads it before the other images and LCP shortens. It works in the other direction too — lowering the priority of an image outside the viewport leaves the bandwidth to the critical resources.
On this site the hero images are served at high priority and without lazy loading; the showcase images are lazy and at normal priority. The distinction rests on measurement of which element is the LCP element — not on a guess.
Prefetching and navigation
The fourth hint serves a different purpose from the rest: it does not speed up the current page, it prepares the NEXT one. The resources of the page the user will most likely visit download at low priority while the browser is idle.
Used right, the effect is striking: when the user clicks the link, the page arrives almost instantly because it is already downloaded. Used wrong, it is pure waste — bandwidth spent on pages the user never visits.
There are a few ways to decide which page to prefetch. The simplest is a fixed list: the two pages most visited from the home page. Smarter is fetching when the user hovers over a link or scrolls toward it — waiting for a signal of intent.
A measured warning: for mobile users, prefetching can produce real cost on metered data plans. Browsers report the data saver preference, and with it on, prefetching should not happen — that is respect for a wish the user stated explicitly.
Audit and cleanup
Resource hints accumulate over time and nobody cleans them. A provider is replaced but the preconnect to it stays; an image is renewed but its old address is still being preloaded. The result: requests that serve nothing yet consume bandwidth.
The browser console warns in this situation: a resource preloaded but unused produces an explicit message. Not ignoring that warning is the easiest path to cleanliness.
- An unused preload — the console warns; it must be removed.
- A preconnect to your own domain — needless; the connection is already established.
- Too many preloads — priority loses its meaning; do not exceed two.
- A preconnect to an old provider — when the provider changed, the hint must change too.
- The data saver preference — with it on, no prefetching.
This list can and should become an audit step: the hints on the page are extracted, each is asked for its rationale, and the ones without one are removed. Done once a year, this cleanup closes a few needless requests on most sites.
A priority note to close: resource hints are the last step of performance work, not the first. A large script load or an unoptimized hero image cannot be compensated with hints — a hint only changes the discovery order, not the resource’s own cost. First the resource is shrunk, then its order is tuned.
A practical checklist
Turning this page into an audit step, here is what to check in the resource hints. The list is kept short because long lists do not get walked; six items fit in one sitting.
- How many preloads exist — more than two is too many.
- What is each one’s rationale — the ones without get removed.
- Does the console warn — an unused preload produces a warning.
- Is there a preconnect to your own domain — needless.
- Does a hint still point to an old provider?
- Is the data saver preference respected?
This list should be walked once a year. Hints accumulate and nobody cleans them; the result is requests that serve nothing yet consume bandwidth.