Browsers cannot start downloading a file until they find out it exists. If your biggest image is set by a stylesheet, or your font is requested by a script, the browser only learns about it after a lot of other work. Resource hints let you tell it earlier, before it would have found out on its own.
This is the gap that surprises people. The image is small. The server is fast. The hosting is good. And the hero still paints a second and a half late, because nothing told the browser to go get it until the layout was nearly done.
Resource hints are the fix, and they are some of the highest leverage tags in modern web development. They are also easy to get wrong in a way that makes a site slower, which is why we are careful about how many we add.
Resource hints are small tags in the page head that tell the browser to start work early. Some warm up a connection to another server. Some download a specific file ahead of time. Some prepare a whole page you think the visitor will click next. All of them trade a little bandwidth for a lot of time.
The four you will actually use are preconnect, dns-prefetch, preload, and prefetch. A fifth attribute, fetchpriority, changes the order of things the browser already knows about. They solve related problems, and picking the wrong one is the usual reason a hint does nothing.
The useful way to think about it is discovery versus priority. Some hints help the browser discover a file sooner. Others change how urgently it treats a file it already found. Once you separate those two jobs, choosing the right tag gets much easier.
Preload tells the browser to fetch a specific file right away, at high priority, before the normal rendering process would find it. MDN describes it as a way to declare fetch requests in the page head for resources the page will need very soon, so they start loading early in the page lifecycle.
One detail catches everyone out. MDN is clear that despite the name, preload "doesn't load and execute the script but only schedules it to be downloaded and cached with a higher priority." The file arrives early and waits. Your normal tag still has to use it.
The "as" attribute is not optional in practice. MDN explains that it tells the browser what kind of resource this is, so it can store the file correctly in cache, apply the right content security policy, and send the correct Accept headers. Leave it off and the browser may fetch the file twice.
Fonts have an extra rule that trips up nearly every first attempt. MDN states that font and fetch preloading require the crossorigin attribute to be set. Without it you get a second download instead of a faster one, which is the exact opposite of the goal. We cover the wider font problem in our piece on how web fonts slow down your website.
MDN also discourages preloading several formats of the same resource, and recommends preloading only the format most of your users will actually use. Hedging costs you the bandwidth of every version you did not need.
Preconnect warms up the connection to another domain before you request anything from it. Google's web.dev guidance explains that setting up a secure connection takes three steps: resolving the domain name to an IP address, opening a connection to the server, and encrypting that connection. Each step costs a round trip.
Doing that work in advance means the file itself starts downloading the moment you ask for it. On a slow mobile connection those three round trips can be a meaningful slice of your load time, which is why preconnect is often the single most effective hint on a site that leans on third-party services.
The limit matters more than the technique. The web.dev guidance is explicit that you should only preconnect to critical domains you will use soon, because the browser closes any connection that is not used within 10 seconds. It also warns that unnecessary preconnecting can delay other important resources.
Our rule is a small handful, never a long list. Preconnect to the domain serving your fonts and the domain serving your largest image, and stop there. Every extra preconnect competes with the resources you actually need first.
Use dns-prefetch for the domains that matter but are not urgent. It only does the first of preconnect's three steps, the DNS lookup, so it is far cheaper. The web.dev guidance recommends exactly this split: preconnect for the most critical connections, dns-prefetch for all the rest.
The savings are real but modest. That same guidance notes a DNS lookup typically takes 20 to 120 milliseconds. You are not going to transform a page with dns-prefetch, but you can shave a real delay off an analytics script or a chat widget that loads later.
This is the right tool for the long tail of third-party domains most sites accumulate. Analytics, tag managers, support chat, and video embeds all sit on other people's servers, and each one costs a lookup the first time it is needed. Our guide on how third-party scripts slow down your website goes into what those services really cost.
Prefetch is for the next page, not this one. It downloads something at low priority for a navigation you expect the visitor to make soon. The classic use is fetching the first step of a checkout while someone reads a product page.
This area has moved. MDN documents the Speculation Rules API as an alternative to the widely available prefetch link, designed to supersede the Chrome-only, deprecated prerender link. It works on document URLs rather than individual files, which suits multi-page sites rather than single-page apps.
The newer API is genuinely better on paper. MDN lists cross-site prefetches, a more expressive syntax, and automatic respect for Battery Saver and Data Saver settings among its advantages, plus the fact that it is not blocked by Cache-Control headers the way older mechanisms are.
We are still cautious with it, and MDN explains why. It flags the API as experimental with limited availability, and states plainly that it "is not Baseline because it does not work in some of the most widely-used browsers." That is fine for a progressive enhancement and wrong for anything you depend on.
Fetchpriority does not help the browser find a file. It changes how urgently the browser treats a file it has already found. The attribute takes three values, high, low, and auto, and web.dev recommends setting it to high on your Largest Contentful Paint image or other critical images.
The reason it helps is a quirk of how browsers schedule images. Google's guidance explains that images start at low priority and only get boosted to high after layout completes, which puts a needless delay in front of every hero image. Marking it high in the markup skips that wait.
Preload and fetchpriority are complements, not competitors. The web.dev article draws the line clearly: preload helps browsers discover resources earlier but does not change their fetch priority, while fetchpriority adjusts prioritization but does not aid discoverability. For a background image set in CSS, it recommends doing both.
In practice fetchpriority is the first thing we reach for on a slow hero, because it is one attribute on an existing tag with no new request involved. If that is not enough, then we consider a preload. Our guide to fixing Largest Contentful Paint covers the rest of the sequence.
The most common mistake is adding too many. Every hint competes for the same bandwidth, so preloading six files means none of them arrives first. A page with fifteen preconnects is usually slower than the same page with two, because the browser spends its early connections on the wrong things.
The second mistake is preloading something the page never uses. Chrome tells you about this for free, and almost nobody looks. As DebugBear documents, the console warns that a resource "was preloaded using link preload but not used within a few seconds from the window's load event." If you see that, the tag is pure cost.
The third is preloading files the browser would have found instantly anyway. A stylesheet linked in the head is already discovered in the first pass of the HTML. Preloading it adds a line of code and changes nothing.
The fourth is treating hints as a substitute for smaller files. A hint moves a download earlier in time. It does not make the download smaller. If your hero image is 900 kilobytes, no combination of tags fixes that, and compressing it properly will beat every hint on this page.
Measure before and after on the same page, on a throttled connection, and look at Largest Contentful Paint rather than a total score. Chrome DevTools shows the request waterfall, which is where a hint either visibly moves a bar to the left or does not. If nothing moved, remove the tag.
Lab tools and field data answer different questions. Lighthouse and WebPageTest give you a controlled comparison you can rerun. The Chrome User Experience Report, which feeds PageSpeed Insights, tells you what real visitors on real devices actually got. We use the lab to decide and the field to confirm.
The waterfall is where the real learning happens. You can see the three connection steps that preconnect removes, and you can see a preloaded file jump to the front of the queue. Once you have watched that a few times, choosing the right hint stops being guesswork.
Keep a record of what you added and why. Resource hints accumulate quietly over years, and the person auditing the site later needs to know whether that preconnect to an old analytics domain is still doing anything. Most of the time, it is not.
Start with one preconnect to whichever third-party domain serves your most important asset, and one fetchpriority of high on your hero image. Those two changes take about ten minutes and cover the majority of the gain available. Measure, keep what worked, and delete what did not.
Only after that should you consider preload, and only for a file the browser genuinely discovers late. Fonts referenced inside CSS and images set as CSS backgrounds are the honest candidates. Almost everything else is already found early enough.
Leave prefetch and the Speculation Rules API for last. They are useful on content sites with predictable next clicks, and they are experimental enough that they should never be load-bearing. Treat them as a bonus for the browsers that support them.
If your site feels slow and you cannot tell which of these would actually help, we are happy to look at the waterfall with you. Send us the URL at phoenix.studio and we will tell you what is really costing you time, even if the answer is that no tag will fix it.
Tell us where you want to go. We'll tell you how we'd get you there.