What does the `priority` prop on a next/image `<Image>` change about how the browser loads that image, and why is putting it on every image on the page counterproductive?
answer
- opposite of the lazy default
- the preload scanner starts it early
- a relative signal, not a speed dial
- one per route, and only in the first viewport
- changes timing, not bytes
basics
~20 spriority turns off lazy loading for that image, marks the fetch high priority, and preloads it from the document head. Reserve it for the LCP image, because preloading everything makes requests compete and helps nothing.
solid answer
~50 sBy default `next/image` renders `loading="lazy"`, so the browser defers the fetch until the image is near the viewport — good for a long page, bad for the one image that *is* the first thing you see. `priority` flips that: the image loads eagerly, is marked as a high-priority fetch, and Next emits a preload link in the document head so the request starts as the HTML is parsed rather than after layout discovers the element. The point is the Largest Contentful Paint element — usually a hero or the first product photo. It is a relative signal, though, not a speed setting: if you mark eight images priority, they all preload, compete for the same connection and bandwidth, and the real LCP image finishes later than if you had marked only it. Next's dev server even logs a warning when it detects an LCP image without `priority`, which is the cue to add exactly one.
go deeper
Know that images are lazy by default and that priority is the opt-out you add to the one big image visible on first load, not to every image.
Explain all three effects — eager loading, high fetch priority, and a preload emitted in the head — and why the head preload lets the download start before layout finds the element.
Demonstrate that you pick the image from measurement rather than intuition, check mobile and desktop separately, and pair priority with a right-sized file so you are not just accelerating a bloated asset.
Own the guardrail: a convention or lint rule capping one priority image per route, plus field LCP monitoring, so the prop does not spread through the codebase until it means nothing.
## The default and why it exists Every `next/image` renders with `loading="lazy"` unless told otherwise. Native lazy loading means the browser holds the request until the element comes near the viewport. On a long page this is a large win: images below the fold cost nothing until scrolled to. It is a loss for exactly one image — the one already on screen at first paint. Lazy loading it means the request cannot start until the browser has parsed the HTML, built layout, and worked out that the element is in view. Those milliseconds land directly on **Largest Contentful Paint**, the metric that measures when the biggest above-the-fold element finishes rendering. ## What `priority` actually changes Three things, and it is worth naming all three: 1. **Eager loading.** The rendered `<img>` no longer carries `loading="lazy"`, so the fetch is not deferred. 2. **A high fetch priority.** The image is marked high priority so the browser schedules it ahead of ordinary images rather than behind them. 3. **A preload in the head.** Next emits a `<link rel="preload" as="image">` carrying the responsive candidate list, so the preload scanner can start the download while the HTML is still being parsed — before the `<img>` element is even constructed. That third item is the one candidates usually miss, and it is the biggest part of the win. ```jsx <Image src={hero} alt="Trail running shoe on a rock" priority sizes="(max-width: 768px) 100vw, 1200px" /> ``` ## Why "priority everywhere" backfires Priority is **relative**. A browser has finite bandwidth and a scheduling queue; telling it that everything is urgent is the same information as telling it that nothing is. Concretely: - Every preloaded image starts downloading immediately, including the ones the user will never scroll to. They compete with the HTML, the CSS, the fonts and the actual LCP image for bandwidth. - The high-priority marking loses its discriminating power once every image carries it — the browser can no longer tell which one the page is judged on. - You have also disabled lazy loading wholesale, so a page with forty product photos fetches forty photos on load. The measurable outcome is usually a *worse* LCP than the default, plus a much heavier initial load. This is the mistake the question is really probing for. ## Choosing the right image The LCP element is whatever renders largest in the initial viewport, and it is often not what a developer assumes. Determine it rather than guessing: - Next's development server logs a warning naming an image it detected as the LCP element without `priority` — a direct hint. - A performance panel recording or a field-data tool reports the actual LCP element per page, which may differ between mobile and desktop layouts. As a rule of thumb: at most one `priority` image per route, and only when it is genuinely inside the first viewport. A carousel counts as one — the first visible slide, not all of them. A logo in the header is usually small enough that it is not the LCP element, so it does not need it. ## Related traps **Priority does not shrink the file.** It changes *when* the request happens, not how many bytes come back. A 1.8 MB hero preloaded early is still 1.8 MB in the way of your LCP. Pair `priority` with an accurate `sizes` and a sane `quality`, or you have just made the wrong thing arrive sooner. **A priority image that is not in the viewport is pure waste.** The browser downloads it at high priority, then it sits unused. Some browsers will also warn in the console that a preloaded resource was not used soon after load. **It cannot help what it cannot start.** If the image URL only becomes known after client-side data fetching, no head preload exists at parse time — the fix there is to get the URL into the server-rendered HTML, not to add more props. ## The interview-shaped summary `priority` = eager + high fetch priority + head preload, for the single LCP image, and its value comes precisely from being scarce. Anyone who answers "it makes the image load faster" has said what it does but missed why applying it broadly is self-defeating.
- Why does the head preload matter more than simply removing `loading="lazy"`?Because the browser's preload scanner reads the head while the HTML is still being parsed, so the download can begin before the `<img>` element exists and before layout runs. Eager loading alone still waits for the element to be constructed and discovered. On a document with a lot of markup above the hero, that gap is a meaningful slice of LCP.
- How would you identify which image on a route is actually the LCP element?Measure rather than assume. Next's dev server logs a warning naming an image it detected as LCP without `priority`, and a browser performance recording or field data reports the LCP element directly. Check mobile and desktop separately — a layout that stacks on mobile often promotes a different image, and the largest element can even be a text block, in which case no image needs `priority`.
- Does `priority` do anything for an image that never enters the viewport?Nothing useful, and it costs. The browser preloads and downloads it at high priority alongside genuinely critical resources, then it goes unrendered — wasted bandwidth competing with your real LCP asset. Browsers may also warn that a preloaded resource was not used. Off-screen images should keep the lazy default.
It is a fast-track lane at an airport: useful because most passengers are not in it. Issue everyone a fast-track pass and you have simply rebuilt the ordinary queue.
saying these in an interview costs you the question
- Says priority compresses or shrinks the image
- Adds priority to every image as a blanket optimization
- Thinks it only sets loading="eager" with no preload
- Assumes the LCP element is always the topmost image
- Believes lazy loading is a Next feature rather than a native img attribute