Preload, Preconnect and Prefetch: Resource Hints Explained
26/07/2026
By default a browser only discovers resources as it reads the HTML line by line. It notices a font when it hits the CSS that calls it, an image when it reaches the <img> tag. That late discovery costs time. Resource hints — preload, preconnect, dns-prefetch and prefetch — are how you tell the browser: prepare this ahead, I will need it. Used well, they shorten the critical loading path by 100–400 ms.
preconnect: warm up the connection early
Every connection to a domain (Google Fonts, a CDN, analytics) needs three steps: a DNS lookup, a TCP handshake and a TLS negotiation. That easily takes 100–300 ms before a single byte is downloaded. With <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> the browser does those steps immediately, while still parsing the HTML, so when the resource is actually needed the connection is already warm. Use it for your 2–4 most important third-party domains — more than that wastes resources for no gain.
dns-prefetch: the cheaper, weaker variant
<link rel="dns-prefetch"> does only the DNS part, not TCP/TLS. It helps less than preconnect but is cheap and has wider support in older browsers. A common pattern is to list both for key domains: preconnect first, then dns-prefetch as a fallback.
preload: fetch a critical resource sooner
<link rel="preload"> tells the browser to download a specific high-priority file right away, even though it has not yet "seen" it in the HTML. The most common uses are:
- The font used by your main heading —
as="font"withcrossorigin, to avoid FOIT (invisible text while the font loads). - The LCP image (hero banner) —
as="image", often withimagesrcsetfor responsive versions. - A critical CSS or JS file the page cannot render correctly without.
Careful: preload is a command, not a suggestion. If you preload something that is not used in the first few seconds, you steal bandwidth from the truly critical resources. The console warns you with "was preloaded but not used".
prefetch: prepare the next page
<link rel="prefetch"> is about the future, not the current page. It tells the browser to fetch, in the background when the network is idle, a resource likely needed on the next page — for example the product page''s JS bundle while the user is on a category page. When the user clicks, the page is almost instant. Its priority is low, so it does not disturb the current page load.
How to order them
A practical order in the <head>: preconnect to font and CDN domains first, then preload the font and LCP image, and only then the rest. On WordPress most of this is handled by performance plugins (WP Rocket, Perfmatters) or the theme, but it is worth checking what actually happens in DevTools → Network under the "Priority" column.
Common mistakes
First: preloading too many things — then nothing is a priority. Second: a missing crossorigin on fonts, which makes the resource download twice. Third: preconnecting to a domain nothing loads from. Fourth: using prefetch for current-page resources, where it does not help. Always measure before and after — hints only help when they target the right, slow resources.
Frequently asked questions
Do resource hints replace fast hosting? No. They schedule what you have to download anyway more intelligently, but if the server sends HTML slowly (high TTFB) the problem is deeper. The best result is a fast server plus well-placed hints.
How many preconnects are too many? Beyond 4–6 it starts to hurt, because each warm connection uses memory and battery on mobile. Stick to the most important domains.
Our plans ship with a free global CDN and NVMe drives, so preconnect and preload pull from a fast source. See our plans and pricing or the details of SEO hosting.