In HTML, how do fetchpriority="high" on an <img> and a <link rel="preload" as="image"> in the head differ in what they ask the browser to do for a page's main hero image?

## Two different problems When a hero image arrives late, the cause is one of two things, and the fix differs: 1. **Discovery** — the browser did not know about the resource early enough to request it. 2. **Urgency** — the browser knew, but scheduled it behind other requests. `<link rel="preload">` addresses the first. `fetchpriority` addresses the second. Diagnosing which one you actually have is most of the skill here. ## fetchpriority `fetchpriority` takes `high`, `low`, or `auto` (the default) and appears on `<img>`, `<link>`, and `<script>`, among others. It adjusts the relative priority of a fetch that is going to happen regardless. ```html <img src="/img/hero.jpg" width="1600" height="900" fetchpriority="high" alt="…"> ``` The reason it helps is a scheduling detail worth being able to state: browsers generally cannot tell, at parse time, which images are visible, so images start at a relatively low priority and are boosted only after layout shows they are in the viewport. For the one image that dominates the initial screen, that ordering is backwards, and `fetchpriority="high"` corrects it without waiting for layout. The corollary is that priority is a *relative* signal in a finite budget. Marking every image high is the same as marking none of them high, and it can starve genuinely blocking resources. The honest usage is one image per page — the largest one in the initial viewport — plus, occasionally, `fetchpriority="low"` on things you know are not urgent. ## rel="preload" ```html <link rel="preload" as="image" href="/img/hero.jpg" fetchpriority="high"> ``` This tells the browser: fetch this now, with this destination type, because something later in the page will need it. `as` is not optional cosmetics — it sets the request's destination, which determines the priority the browser assigns and how the response is matched to the eventual consumer. A preload with a wrong or missing `as` commonly results in the file being downloaded twice. For a responsive image, a plain `href` preload would fetch the wrong candidate, so the preload accepts `imagesrcset` and `imagesizes` — the counterparts of the `<img>` element's own candidate attributes — so the preload and the element can agree on which file is wanted. ## When each is the right tool - **Hero `<img>` present in the initial HTML.** The preload scanner finds it almost immediately; the problem is priority, not discovery. Use `fetchpriority="high"` on the element, and make sure nothing has marked it lazy. - **The image is not discoverable from the initial HTML** — referenced from a stylesheet, or added by script after the page loads. Now discovery genuinely is the bottleneck, and a preload in the head is the tool that helps. - **Markup is server-rendered but the image sits deep in the document behind large amounts of content.** Discovery is fast enough with the scanner in most cases; measure before adding a preload. The two are frequently combined, and a preload can carry `fetchpriority="high"` so it is both discovered early and scheduled first. ## The double-download trap A preload only helps if the response it fetches is actually reused by the element that needs it. It is not reused when the two disagree — an `href` that does not match the candidate the `<img>` ends up selecting, missing `imagesrcset`/`imagesizes` for a responsive image, a wrong `as`, or a `crossorigin` mismatch between the preload and the element (this one bites hardest with fonts, but applies to images fetched cross-origin too). The symptom is unmistakable in a network waterfall: the same image, twice. A second trap is the stale preload. Preloads are hand-written in the head and the markup they support changes; a preload for an image the page no longer uses is a wasted download that competes with the ones it does use. Because they are separate from the element, they rot silently. ## The order to apply things For a hero image, the useful ordering is: make sure it is not lazy-loaded, give it intrinsic `width` and `height`, then add `fetchpriority="high"` to the single largest image. Reach for a preload only when you can show the image is discovered late, and verify in the waterfall that it is fetched once, not twice. Everything past that — a decode hint, more preloads — is smaller than those first moves. ## Answers that fall down Saying "just preload it" for an image already sitting in the HTML misses that discovery was never the problem. Saying "mark the images high priority" without the word *one* misses that priority is zero-sum. And a candidate who cannot describe how they would confirm the change — the same request, earlier, and only once — is describing a hope rather than a fix.