Lesson 5 of 14
The browser's default loading order is a good guess, not a plan — resource hints and fetchpriority let you override that guess for the handful of requests that actually determine when the page feels loaded, and overusing them is a real, common way to make things slower.
12 min read
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.
Be interviewed on this →Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
A browser parsing HTML builds its own priority queue for every resource it discovers — stylesheets and fonts near the top, below-the-fold images near the bottom, third-party scripts somewhere in between based on heuristics it invents from tag position and type. Most of the time that default ordering is a reasonable guess. But the browser doesn't know which image is your Largest Contentful Paint (LCP) candidate, or that a <link> tag references a domain you're about to fetch a font from — it finds those out only once it actually reaches that line in the HTML, or worse, only after a render-blocking stylesheet finishes and reveals a background-image reference buried in CSS.
Resource hints are <link> tags that tell the browser to act before it would otherwise discover a need — and fetchpriority tells it how to re-rank a resource it already knows about:
rel="preconnect" does the DNS lookup, TCP handshake, and TLS negotiation for an origin before you request anything from it — so when the real request fires, it skips straight to the request itself instead of paying that full round-trip cost first.rel="dns-prefetch" does only the DNS lookup — cheaper than preconnect, useful for origins you'll need eventually but not on the critical path (an analytics or chat-widget domain), where opening a full connection now would be wasted work if the resource never loads.rel="preload" tells the browser "fetch this specific resource now, at high priority, because you'll need it soon" — the canonical use is a hero image or web font referenced only inside CSS that the browser wouldn't otherwise discover until it parses that stylesheet.rel="prefetch" is the low-priority, next-navigation cousin — fetch this now, cache it, because the user will probably need it on the next page, not this one.fetchpriority="high"|"low"|"auto", settable on <img>, <link>, and <script>, re-ranks a resource the browser already knows about within its own type. Critically, <img> elements are deprioritized by the browser's default heuristics — pairing your LCP image with fetchpriority="high" is what actually gets it fetched early, because preload alone fetches it early but doesn't change the image's inherently low default priority once fetched.<head>
<!-- LCP image referenced later in the body — fetch it now, at high priority -->
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high" />
<!-- Third-party origin on the critical path: full connection, ready before the request fires -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<!-- Origin needed eventually, not urgently: DNS only -->
<link rel="dns-prefetch" href="https://analytics.example.com" />
</head>
<body>
<img
src="/hero.avif"
alt="Product hero shot"
fetchpriority="high"
width="1200"
height="600"
/>
</body>
The fetchpriority="high" on the <img> tag itself matters even with the preload in place — it's what overrides the browser's default "images are usually not urgent" heuristic at the moment the image element is actually laid out, not just at fetch time.
preload fetches early; it does not change an image's runtime fetch priority. Images are deprioritized by browsers by default — a preloaded image without fetchpriority="high" can still lose the race to render-blocking CSS and fonts that get preferential treatment automatically.preconnect is expensive per-origin and has a real ceiling — each one opens a full DNS+TCP+TLS handshake. Limit it to the handful of origins the current page genuinely needs immediately (a font CDN serving a render-blocking @font-face, the API host the page's first paint depends on), not every third party the page eventually touches.dns-prefetch and preconnect aren't redundant safety nets — pick one per origin. dns-prefetch is the lighter hint for origins needed later or opportunistically; stacking both on the same origin doesn't add benefit and just adds hint overhead the browser has to process.fetchpriority="high" beyond the browser's own render-blocking CSS/fonts — usually the LCP image. Marking several images "high" collapses back to no prioritization at all, because relative priority only works if most things stay at the default."How would you make sure the browser fetches your hero image first?" is a common probe for whether a candidate understands loading order as something they can actively steer rather than something that just happens — and the honest, complete answer requires naming both preload and fetchpriority="high" together, since either alone is an incomplete fix. Interviewers also listen for the overuse caveat unprompted: a candidate who reaches for preconnect on every domain without discussing the connection-budget tradeoff is demonstrating pattern-matching, not understanding of why the browser's default ordering exists in the first place.