Every millisecond a browser spends waiting to discover a resource is a millisecond the user spends looking at a blank or half-loaded page. The browser's preload scanner already handles the obvious resources — images in <img> tags, scripts in <body> — but late-discovered resources like web fonts, LCP images buried in CSS, and third-party CDN assets fall through the cracks.
Resource hints exist to close that gap. A single well-placed <link rel="preload"> can shave hundreds of milliseconds off your LCP. A misplaced one can consume bandwidth you needed for something else. The difference comes down to understanding exactly what each hint does — and what it does not.
Key Takeaways
preloadfetches a specific resource the current page needs early — use it for the LCP image, critical fonts, and render-blocking scriptspreconnectestablishes a connection to an origin without fetching anything — use it for third-party domains you'll request from (fonts.googleapis.com, CDNs)prefetchfetches a resource the browser will likely need for the next page — low priority, does not affect current page loaddns-prefetchonly resolves DNS — cheaper than preconnect; use it for origins where you don't know what you'll request yet- Over-preloading is a real risk: every preloaded resource competes for bandwidth; preloading resources that aren't used on the current page wastes connection budget
The Four Resource Hints Compared
| Hint | What it does | Priority | Use for |
|---|---|---|---|
preload |
Fetches a specific resource now | High | LCP image, critical font, key CSS/JS for current page |
preconnect |
Opens TCP+TLS connection to an origin | Medium | Third-party domains you'll fetch from this page |
prefetch |
Fetches a resource for future navigation | Low | Next page's critical resource |
dns-prefetch |
Resolves DNS only | Very low | Third-party origins where resource URL is unknown |
preload — For Critical Current-Page Resources
preload tells the browser: "I will definitely need this resource on this page — start fetching it now, before the parser discovers it."
<!-- Preload the LCP image -->
<link rel="preload" as="image" href="/hero.jpg" fetchpriority="high">
<!-- Preload a critical web font -->
<link rel="preload" as="font" href="/fonts/inter.woff2" type="font/woff2" crossorigin>
<!-- Preload a render-blocking script -->
<link rel="preload" as="script" href="/critical.js">The as attribute is required — it tells the browser what type of resource to expect so it can set the correct Content-Type and request priority. Omitting it causes the browser to fetch the resource at a low default priority, defeating the purpose.
When to use:
- The LCP element (hero image, header image) — the single highest-impact preload on most pages
- Web fonts referenced in CSS (the browser doesn't discover them until the CSS is downloaded and parsed)
- Critical scripts that are currently render-blocking and can't be deferred
When NOT to use:
- Resources already visible to the browser's preload scanner — scripts in
<body>, images with<img>tags. The scanner handles these without help. - Resources used on other pages — use
prefetchinstead - Every font on the page — only preload fonts needed for above-the-fold text. Preloading every weight and style burns bandwidth before the page is interactive.
as attribute is wrong.
preconnect — For Third-Party Origins
preconnect tells the browser: "I will make requests to this origin — start the DNS lookup, TCP handshake, and TLS negotiation now." It does not fetch any specific resource; it just warms up the connection so the first actual request to that origin doesn't have to wait for the full connection sequence.
<!-- Preconnect to Google Fonts -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<!-- Preconnect to your CDN -->
<link rel="preconnect" href="https://cdn.yourdomain.com">Use crossorigin for origins that serve font files — fonts are fetched as CORS requests, and the browser needs to open a separate CORS connection if you don't declare it upfront. Not needed for same-origin requests or non-CORS resources like images.
When to use: Third-party domains you know you'll make requests to on the current page — Google Fonts, CDNs serving images or scripts, analytics endpoints, tag manager domains.
Limit: Chrome supports a maximum of 10 simultaneous preconnect hints; beyond that they are silently ignored. Only preconnect to origins you actually use on the current page. Preconnecting to origins that are never requested wastes TCP/TLS handshake time for no benefit.
prefetch — For the Next Page
prefetch fetches a resource at very low priority for use on a future navigation. Unlike preload, it is explicitly a hint about the next page, not the current one. The browser will only download it when it has idle bandwidth — it will not compete with current page resources.
<!-- Prefetch the next article's hero image -->
<link rel="prefetch" href="/images/next-article-hero.jpg" as="image">
<!-- Prefetch the checkout page's main script -->
<link rel="prefetch" href="/js/checkout.js" as="script">When to use: When you can predict the user's next page with high confidence — a "next article" button, a multi-step checkout flow, a post-login redirect. The value is highest on slow connections where the next page would otherwise load noticeably slowly.
When NOT to use: For resources on the current page (use preload). For resources on pages the user is unlikely to visit — prefetching unused resources wastes bandwidth, especially on mobile. Prefetching everything speculatively provides no measurable benefit and degrades the current page experience on constrained connections.
dns-prefetch — Lightweight Origin Hint
dns-prefetch resolves DNS for an origin — no TCP handshake, no TLS negotiation. It is cheaper than preconnect and appropriate when you know you'll request something from an origin but don't yet know the full resource URL, or when the connection warm-up overhead of preconnect isn't justified.
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//analytics.example.com">Note that dns-prefetch uses protocol-relative syntax (//) in many examples — both // and https:// forms work.
When to use: Origins that will be used on the page but where the connection cost of preconnect is too high — a tracking pixel loaded after user interaction, analytics endpoints triggered on scroll, third-party widgets loaded conditionally. DNS resolution alone typically saves 20–120ms per uncached origin.
dns-prefetch vs preconnect: If you know you'll make a request to an origin on page load, use preconnect. If the request might happen later or conditionally, use dns-prefetch. If you're unsure, dns-prefetch is the safer default — it is always cheap.
preconnect encounters a dns-prefetch hint for an HTTPS origin, it may automatically perform the full TCP+TLS handshake anyway. The hints are advisory — the browser makes the final call based on its own heuristics and available resources.
Detecting Missing Preconnects and Preloads
Resource hint problems are easy to miss in development because local servers are fast. On real user connections — especially mobile on 4G — the difference between a preloaded LCP image and an unpreloaded one can be 500ms or more of LCP delay.
The Page Speed Inspector detects:
- Missing
<link rel=preconnect>for third-party origins used on the page - LCP images that aren't preloaded (a key cause of slow LCP scores in Core Web Vitals)
- Render-blocking scripts and stylesheets that could benefit from preload or defer
- Web fonts loaded without preload (common cause of layout shift and invisible text flash)
Run the Page Speed Inspector on any URL and the recommendations section will list specific resource hint opportunities with the actual URLs involved — not generic advice, but the specific assets missing preload or preconnect on your page.
Find Missing Preloads and Preconnects on Your Page
Free, no signup. The Page Speed Inspector detects missing preconnect hints, unpreloaded LCP images, and render-blocking resources — the specific issues that preload and preconnect are designed to fix.
Try the Page Speed Inspector Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.