Resource hints — preconnect, dns-prefetch, preload, and prefetch — are one-line HTML tags that tell the browser to start network work early instead of waiting until it stumbles on a resource. Used correctly, they shave real milliseconds off Largest Contentful Paint (LCP) and reduce layout shifts, which directly improves your Core Web Vitals. Used carelessly, they waste bandwidth and can actually slow the page. Here is exactly what each hint does and when to reach for it.
The four hints and what they do
Each hint targets a different stage of the loading process. Knowing which stage a resource is stuck at tells you which hint to use.
- dns-prefetch — resolves a domain's DNS ahead of time. Cheapest hint, only saves the DNS lookup. Good for third-party domains you will probably use but are not certain to.
- preconnect — does the DNS lookup plus the TCP handshake and TLS negotiation for a domain. Saves much more time than dns-prefetch, but each open connection has a cost, so use it only for a few critical origins.
- preload — tells the browser to fetch a specific file (a font, a hero image, a critical stylesheet) at high priority right now, because it is needed for the current page. This is the hint that most often moves LCP.
- prefetch — fetches a resource at low priority for a future navigation, such as the CSS for the page a user is likely to click next. It does nothing for the current page's speed.
Using preconnect and preload to improve LCP
Your LCP element is usually a hero image, a headline in a web font, or a large block of text styled by a render-blocking stylesheet. The delay before it appears is often spent connecting to a third-party origin or discovering a file buried deep in the HTML. Two hints fix most of this.
Add preconnect for the origins your critical resources come from — a font provider, an image CDN, or your own asset domain — near the top of the head. Because the browser opens the connection while it is still parsing HTML, the actual file arrives sooner. Then add preload for the single most important file: the LCP image, or the WOFF2 font file that renders your headline. A preloaded font also prevents the flash of invisible text and the layout shift that comes when a fallback font is swapped out, which helps your Cumulative Layout Shift score too.
One caution: preload is a high-priority command, not a suggestion. Preloading five things means nothing is truly prioritized, and preloading resources the page does not immediately need steals bandwidth from the ones it does. Preload one, maybe two, resources per page. For the full measurement picture, see our guide to Core Web Vitals and how LCP, INP and CLS are scored.
Where resource hints fit in a performance strategy
Resource hints are a precision tool, not a foundation. They help the browser use the network more efficiently, but they cannot rescue a slow server or an oversized image. If your Time to First Byte is high, the browser has nothing to preconnect to quickly — fix the server first, as covered in our guide to reducing TTFB. If your hero image is a 2 MB PNG, preloading it just downloads the bloat faster; compress and serve modern formats first, as in our guide to image optimization with WebP and AVIF.
The right order is: get the server responding quickly, keep assets small, and then use resource hints to line up the critical few so nothing waits its turn. Think of hints as removing idle gaps in an already lean loading sequence, not as a substitute for a lean sequence.
Common mistakes to avoid
The most frequent errors turn a speed tool into a drag. Too many preconnects — each one holds an open connection consuming memory and CPU; limit yourself to a handful of genuinely critical origins. Preloading fonts without the crossorigin attribute — fonts are fetched anonymously, and a preload without crossorigin creates a second, wasted request instead of priming the real one. Preloading below-the-fold or conditional resources — this fights the browser's own prioritization and delays what actually matters. And prefetching aggressively on mobile — you may burn a user's data plan fetching pages they never visit.
Add hints deliberately, measure before and after, and remove any that do not show a real improvement. A hint that does not help is not neutral; it competes for the same limited bandwidth as your critical content.
Resource hints only pay off when they target the resources that are genuinely holding your page back, and that requires seeing your real loading waterfall and Core Web Vitals. Run the CheckMy.site scanner to check your performance signals and find the render-blocking resources worth preloading — and the ones you are wasting priority on.