25 May 26 
Three small HTML hints can make a site feel noticeably faster by telling the browser what to fetch early. Here is what preload, prefetch, and preconnect actually do, when to use each, and how to avoid the common mistakes.
WEB PERFORMANCE
A lot of perceived slowness on the web is not the browser being slow, it is the browser waiting: waiting to discover a font, waiting to open a connection to another server, waiting to find out it needs a file it could have started fetching seconds earlier. Resource hints are small instructions you add to your HTML that let you get ahead of that waiting by telling the browser what is coming. Three of them do most of the useful work: preconnect, preload, and prefetch. They are easy to add, and used well they can make a site feel meaningfully quicker without changing a single line of your actual application code.
preconnect: open the door early
When your page needs something from another domain, a font provider, an analytics service, an image CDN, the browser has to set up a connection first, and that handshake takes real time before a single byte of the actual resource arrives. preconnect tells the browser to do that setup work early, in the background, so that when the resource is actually requested the connection is already open and waiting. It is most valuable for important third-party origins you know you will hit, especially fonts and CDNs. The rule of thumb is to preconnect only to the few origins that genuinely matter early, because each connection has a cost and opening a dozen of them speculatively does more harm than good. This pairs naturally with getting third-party scripts under control, since those are often the very origins worth connecting to early or cutting entirely.
preload: fetch this now, it is critical
preload tells the browser to fetch a specific resource with high priority, right away, because you know the page will need it soon even if the browser would not discover it until later. The classic use is a web font or a hero image that is critical to the first paint but is normally found late, buried in a stylesheet or deep in the markup. By preloading it, you pull that discovery forward and the critical resource arrives in time to matter. The caution here is real: preload is a strong instruction, and preloading things that are not actually critical steals bandwidth and priority from the things that are. Reserve it for the handful of resources that genuinely block a good first impression, which ties directly into fixing a failing LCP, where a late-loading hero image is one of the most common culprits.
prefetch: fetch this for later, quietly
prefetch is the gentle one. It tells the browser to fetch a resource at low priority, in idle time, because the person is likely to need it soon, typically on the next page they visit. If you can reasonably predict where someone will go next, prefetching the key resource for that page means it is already in the cache when they get there and the next navigation feels instant. Because it runs at low priority, prefetch does not fight with what the current page needs, which makes it low risk, but it is also wasted if your prediction is wrong, so use it where the next step is genuinely likely rather than everywhere.
Getting the balance right
The theme across all three is that they are about priority, not magic. A browser only has so much bandwidth and so many connections, and these hints let you spend that budget deliberately instead of leaving everything to default discovery order. That also means they can backfire if you overuse them: preconnect to everything and you waste connections, preload everything and nothing is actually prioritised, prefetch everything and you burn people’s data for pages they never visit. The right approach is surgical. Identify the two or three origins worth connecting to early, the one or two resources genuinely critical to the first paint, and the occasional next-step worth prefetching, and leave the rest to the browser. Measure before and after with real field data rather than trusting that more hints must mean more speed, in the spirit of field data versus lab data for Core Web Vitals.
The takeaway
Resource hints are a cheap, high-leverage way to remove waiting from a page. Use preconnect to open connections to critical third-party origins early, preload to pull forward the few resources that block a good first impression, and prefetch to quietly prepare the likely next step. Apply each sparingly and deliberately, measure the effect, and you can make a site feel faster without rebuilding anything underneath it.
If you want help finding where your site is waiting and making it feel faster, we would love to help.