On one project I sprinkled tags everywhere. The logic was simple: download things early and the page will be fast. LCP was telling me the opposite. Once I dug in, the lesson stuck: resource hints aren’t free. A misused preload fights the actually critical resource for bandwidth.
Three hints, three different problems.
Preconnect: tells the browser “start opening a connection to this origin”. It pulls DNS lookup, TCP handshake, and TLS negotiation forward. Makes sense for third-party servers like Google Fonts, analytics, or a CDN. It’s time-boxed: if you don’t request a resource from that origin within 10 seconds the browser can close the connection. So put it in , but only for origins you’ll genuinely hit.
Preload: says “download this resource now, I’ll need it shortly”. Fonts, critical CSS, above-the-fold images, a hero video. Non-render-blocking but still critical. The biggest mistake is skipping the as attribute. Preload a font without as="font" and the browser downloads it twice. Font preloads also need crossorigin.
Prefetch: says “this user will probably go to the next page, fetch it in the background”. It runs at idle, low priority. Meaningful on e-commerce (list to product detail) or in a blog (next article).
On a client’s e-commerce site I preloaded the hero image. LCP dropped from 3.8 seconds to 2.1. That image was only discovered after CSS parsing, so the browser was finding it late. Preload erased that delay.
But on the same site I had preloads on two analytics scripts. That turned out to be the source of my LCP jitter. The analytics scripts already ran deferred; adding preload made the browser treat them as critical and divert resources to them. I removed the preloads and LCP dropped to 1.8 seconds.
There’s one more case where preload is essential: web fonts. Fonts get declared inside CSS, so the browser doesn’t know they exist until CSS is parsed. That produces FOIT or FOUT. Preloading the critical font cuts the gap.
Be careful with prefetch. Put it everywhere and you’re downloading a pile of resources in the background that never get used. On mobile you’re eating someone’s data plan. There are smart prefetch libraries like Quicklink that prefetch links when they enter the viewport. I use it on my blog, so the next article opens as soon as the user moves toward it.
The worst bug: preloading the same resource and also loading it normally, but with mismatched cache keys so the browser downloads it twice. I’ve hit this trap with font files; the crossorigin attribute didn’t line up.
DNS-prefetch also exists, but in modern browsers it behaves like a subset of preconnect. It only earns its own slot when you’re connecting to many origins and don’t want to burn preconnect slots.
One practical tip: check whether hints actually helped in the waterfall view in Lighthouse or WebPageTest. When was the resource requested, when did it start, how much did the hint buy you? Adding hints without watching those numbers is guessing in the dark.