Understanding Browser Resource Priority Queues

Every network request a page makes enters a dynamic scheduler inside the browser — a priority queue that decides which bytes arrive first, which connections are allocated, and which assets sit idle while critical resources load. Getting this scheduler to work in your favour is the most direct lever for improving Largest Contentful Paint and eliminating the stall cascades that inflate time-to-first-byte across the waterfall.

This page covers the spec-level mechanics of how Chromium, WebKit, and Gecko assign, promote, and demote resource priorities; how fetchpriority and <link rel="preload"> interact with those heuristics; how to verify the changes are working using DevTools and PerformanceObserver; and the edge cases that silently break well-intentioned hints. The three engines agree on far less than most performance advice assumes, and Chrome vs Safari vs Firefox priority differences takes that divergence apart request by request once you have the model below.

The Scheduling Problem This Page Solves

When a browser encounters a page, it can issue dozens of network requests within the first 200 ms. It has, at most, 6 TCP connections per origin under HTTP/1.1 and one multiplexed connection under HTTP/2. The browser must decide which requests get those slots immediately and which wait. A wrong ordering — where analytics scripts, web fonts, or off-screen images consume connections before the LCP image or critical CSS — directly inflates paint timing and degrades Core Web Vitals scores.

The fix is not to load fewer resources; it is to teach the scheduler which resources matter.

That distinction matters because most pages that fail LCP are not oversized. They are correctly sized and badly ordered. A 1.4 MB page that loads its 240 KB hero image first paints faster than a 900 KB page that loads the hero twenty-seventh, on the same connection, every time. Byte budgets and scheduling are independent levers, and scheduling is the cheaper one: reordering a waterfall costs a few attributes in the markup, whereas removing a megabyte costs product decisions.

Concept Definition: How the Scheduler Assigns Priority

The browser’s resource scheduler operates during speculative pre-parsing (the preload scanner runs ahead of the main HTML parser) and again as the main parser constructs the DOM. Each resource receives an implicit priority tier based on resource type, DOM position, and render-blocking status. These tiers are not a web standard — they are engine-internal constants — but the fetchpriority attribute, which the Fetch specification defines as the request’s priority concept, exposes a hook to influence them.

Four inputs feed the initial decision, in roughly this order of weight:

1. Destination. What the resource is for — style, script, image, font, fetch — carries most of the signal. A stylesheet in the head is render-blocking by definition; an image is not.
2. Blocking semantics. A <script> with neither async nor defer halts the parser, so it outranks one that does not. A stylesheet behind a non-matching media query does not block rendering and drops a tier.
3. Document position and viewport intersection. Early markup is assumed more important than late markup, and Chromium additionally checks whether an image intersects the initial viewport at first layout.
4. The explicit hint. fetchpriority is applied last and moves the resource within the ordering the first three produced — it does not replace them.

The fourth input is the only one you control directly, which is why so much tuning work amounts to correcting a wrong guess made by the first three.

Engine Comparison Table

Key takeaway for cross-browser work: Do not rely on mid-flight LCP upgrades in WebKit or Gecko. Use an explicit fetchpriority="high" attribute on the LCP <img> so all three engines get the correct priority from the first scheduling pass.

The differences run deeper than the table can show. Chromium re-ranks requests during the load and holds back delayable ones while render-blocking work is outstanding; WebKit sets a value once at fetch creation and never revisits it; Gecko does not really use a single number at all below the fetch layer, instead attaching class-of-service flags — Leader, Follower, Unblocked, Speculative, and a tail family — and letting a class drain before the next one starts. The consequence is that a page tuned by trial and error in one engine can behave worse in another, because you have tuned against a heuristic the other two do not implement.

What the Queue Actually Is

“Priority queue” is a useful shorthand but it hides a two-stage mechanism, and the two stages fail differently.

Stage one is ordering. The scheduler keeps requests it has not yet dispatched in priority order. This is where fetchpriority acts. Reordering is cheap and instantaneous; nothing is on the wire yet.

Stage two is admission. A request only leaves the queue when the network layer has somewhere to put it. Under HTTP/1.1 that means one of six sockets per origin — Chromium’s socket pool limit per (scheme, host, port) group, with a global ceiling in the hundreds. Under HTTP/2 it means a stream on the single connection, bounded by the server’s SETTINGS_MAX_CONCURRENT_STREAMS, commonly 100 to 128. Chromium adds a third constraint of its own: while render-blocking resources are still outstanding, the loader holds delayable requests to a very small number in flight, so a gallery cannot starve a stylesheet.

Almost every “the hint did not work” report is a stage-two problem misdiagnosed as a stage-one problem. The resource was correctly promoted and then waited anyway, because six slots were already committed to requests issued 40 ms earlier.

Work the arithmetic on a concrete page. A product page on an HTTP/1.1 origin, throttled to 1.6 Mbps and 150 ms round-trip, requests 31 subresources: one 46 KB stylesheet, three scripts totalling 310 KB, two 28 KB WOFF2 fonts, a 240 KB AVIF hero, and 24 gallery images averaging 40 KB. With no hints, the hero sits 27th in document order. The six sockets are claimed by the stylesheet, the scripts, and the first two gallery images before the parser has even reached the hero tag. Each 40 KB image occupies a socket for roughly 200 ms of link time, so the 24 gallery images represent about four full waves of socket occupancy — near 800 ms — queued in front of a request the page cannot paint without.

Moving the hero to the front does not make the page smaller. It makes the 800 ms happen after the paint instead of before it. That is the entire trick, and it is why byte-level optimisation and scheduling optimisation should be measured separately: shrinking the gallery by 30% saves 240 ms of total load, while reordering it saves 800 ms of LCP.

Spec and API Reference

The fetchpriority Attribute

fetchpriority is valid on <img>, <link>, <script>, and in the fetch() API’s Request init dictionary.

fetchpriority is a hint. The browser may ignore or partially honour it if connection pressure makes honouring it impractical.

The attribute is also relative, not absolute. There is no numeric scale exposed to authors: high means “above what this resource would otherwise have been”, so marking every image high produces the same ordering as marking none of them, minus the head-room you would have had for the one image that mattered. Two or three high hints per document is the practical ceiling.

Browser Support Matrix

An unsupported fetchpriority attribute is inert, not harmful: older engines parse it as an unknown attribute and schedule the resource by their default heuristic. That makes the hint safe to ship unconditionally, and it means a browser-support gap shows up as “no improvement on Safari 16” rather than as a regression.

<link rel="preload"> Directive

Preload forces the browser to fetch a resource at high priority before the parser would naturally discover it. It does not execute or apply the resource — a preloaded script still needs a <script src> tag to run, a preloaded CSS file still needs a <link rel="stylesheet">.

Preload interactions with the scheduler in Core Browser Loading Mechanics & Priority Queues:

• A preloaded resource with as="image" gets VeryHigh priority in Chromium if it is also marked fetchpriority="high".
• Without the as attribute, the browser fetches the resource at High but cannot optimise MIME type handling or CORS preflight caching.
• The preload scan runs before the DOM is ready, meaning <link rel="preload"> in <head> reaches the scheduler ~100–400 ms earlier than a same-resource <img> deep in the body would on a slow connection.

It helps to separate the two effects a preload has. It changes when the request is created — that is the preload scanner running ahead of the parser — and it changes what band the request is created in, via as plus any fetchpriority. A resource already visible to the preload scanner in the initial HTML gains only the second effect from a preload link, which is usually a reason to put fetchpriority="high" on the element itself and skip the extra tag entirely.

Step-by-Step Implementation

Before writing any attributes, decide what each candidate resource actually is: something the first paint depends on, something the next navigation depends on, or something neither depends on. Those three answers map onto exactly four markup outcomes, and the branch that decides between the first two is whether the preload scanner can already see the resource in the initial HTML response.

Step 1: Prioritise the LCP Resource

Add fetchpriority="high" directly on the <img> element that is your LCP candidate. If the LCP image is used as a CSS background, you must use a preload link instead — CSS background images are invisible to the preload scanner.

<!-- LCP foreground image: hint the scheduler from the first parse pass -->
<img
  src="/assets/hero.webp"
  alt="Product hero image"
  width="1200"
  height="630"
  fetchpriority="high"
  decoding="async"
>

<!-- LCP background image: preload with srcset so responsive variants are covered -->
<link
  rel="preload"
  as="image"
  href="/assets/hero.webp"
  imagesrcset="/assets/hero-800.webp 800w, /assets/hero-1200.webp 1200w"
  imagesizes="(max-width: 800px) 100vw, 1200px"
  fetchpriority="high"
>
<!-- The scheduler receives this in the preload-scan phase, before the CSS is parsed -->

Keep imagesrcset and imagesizes byte-identical to the srcset and sizes on the consuming element. If they differ, the browser may select a different candidate URL for the preload than for the render, and you have paid for a 240 KB image twice at the worst possible moment in the load.

Step 2: Deprioritise Non-Critical Scripts

Analytics and tag manager scripts routinely load at High by default. Downgrading them frees connection slots for render-critical assets during the first few seconds.

<!-- Analytics: low priority + deferred execution — no scheduler contention -->
<script
  src="/analytics.js"
  fetchpriority="low"
  defer
></script>

<!-- Third-party chat widget: load after interactive, deprioritised -->
<script
  src="https://example-chat.com/widget.js"
  fetchpriority="low"
  async
></script>

fetchpriority="low" and defer do different jobs and you generally want both. defer moves execution to after the document has parsed; fetchpriority="low" moves the download behind the render-critical band. A deferred script without a low hint still competes for a socket during the first paint window, and a low-hinted script without defer or async still blocks the parser when it eventually arrives. The distinction between download order and execution order is worth internalising before touching third-party tags; script loading with async, defer and execution order covers the execution half in full.

Step 3: Preload Cross-Origin Fonts Correctly

Cross-origin fonts require a crossorigin attribute on the preload link that matches the attribute on the eventual @font-face rule. A mismatch causes a double-fetch: one wasted preload request and one real request when the CSS parser reaches the @font-face declaration.

<!-- Font preload: crossorigin is mandatory for cross-origin fonts -->
<link
  rel="preload"
  as="font"
  href="https://fonts.example.com/inter-var.woff2"
  crossorigin="anonymous"
  type="font/woff2"
  fetchpriority="high"
>
<!--
  Matching CSS must also use crossorigin-compatible fetch semantics.
  If you omit crossorigin here but the @font-face fetch uses CORS,
  the browser treats them as different resources and fetches twice.
-->

Fonts deserve care for a second reason: they are the classic case where the right answer is not the high band. A preloaded font at VeryHigh competes directly with the LCP image, and if your text is already visible through a fallback face thanks to font-display: swap, winning that race buys you a slightly earlier reflow at the cost of a later paint. Preload the one font that renders above-the-fold text, leave the rest at their default, and measure both LCP and layout shift before deciding you have improved anything.

Step 4: Use rel="prefetch" for Likely-Next-Page Resources

Cache interaction and stale-while-revalidate patterns work best when prefetch deposits resources into the HTTP cache before the user navigates. Prefetch runs at Low (VeryLow in some Chromium versions) and only starts after the current page’s high-priority resources have loaded.

<!-- Prefetch the likely next page's critical CSS — runs at idle priority -->
<link rel="prefetch" href="/checkout/checkout.css" as="style">
<!-- No fetchpriority="high" here — you want this at the back of the queue -->

Worked Example: One Product Page, Two Waterfalls

The 31-request product page from earlier is worth carrying all the way through, because the numbers show which lever did the work. Nothing about the page changed except four attributes: fetchpriority="high" on the hero <img>, fetchpriority="low" plus defer on the tag manager, loading="lazy" on the 24 gallery images, and the removal of a fetchpriority="high" that had been sitting on a decorative logo since a previous optimisation pass.

Read the last two rows together. Total load barely moved, because the same bytes still crossed the same link — the gallery simply arrives after the paint instead of before it. That is the signature of a pure scheduling fix, and it is why judging this work by load or by total transferred bytes will always make it look like nothing happened. Judge it by when the LCP element’s bytes start arriving.

The removed high hint on the logo is the least obvious of the four changes and contributed roughly 180 ms of the improvement. A 6 KB logo at VeryHigh costs almost nothing in bandwidth, but it occupied a socket during the exact window in which the hero was trying to get one. High-band hints are a budget spent in slots, not in bytes.

Verification Workflow

DevTools Priority Column

1. Open Chrome DevTools, switch to the Network tab.
2. Right-click any column header and enable Priority.
3. Reload the page and locate the LCP resource in the waterfall. Confirm it shows Highest (Chromium’s display label for VeryHigh) or High.
4. Hover over the LCP resource’s waterfall bar. Read the Queued at and Started times. The gap is queue wait time. Anything above 50 ms on a Fast 3G profile indicates the scheduler assigned the resource a lower tier than expected, or connection slots were exhausted by earlier requests.
5. Click the resource row, open the Timing sub-tab. Stalled time is queue wait plus TCP socket wait. Long Stalled with low Content Download time means the bottleneck is scheduling, not bandwidth.

Enable the Priority column permanently rather than per-session, and add the Protocol column beside it. Reading the two together answers the first diagnostic question immediately: a long stall on an h2 row cannot be socket exhaustion, so it is either server-side stream ordering or a browser-side hold-back, whereas the same stall on an http/1.1 row almost always is. Diagnosing request queueing and stalled time walks through separating those causes from the Timing panel alone.

Auditing Priority Inversion

Priority inversion occurs when a Low or Medium resource consumes a connection slot while a High or VeryHigh request sits in Stalled state. To detect it:

1. In DevTools Network, set throttling to Fast 3G and CPU slowdown to 4x.
2. Sort the waterfall by Start Time.
3. Look for High or Highest priority rows with long light-grey (Stalled) bars that begin after Low or Medium rows with active dark-blue (Content Download) bars.
4. Export the HAR file and calculate the Priority Inversion Ratio: low-priority bytes downloaded while a high-priority request was stalled, divided by total bytes transferred. A ratio above 0.15 indicates a scheduling misconfiguration worth fixing.

The ratio matters more than any single stalled bar, because one long stall on a slow connection is normal and unavoidable. What is not normal is low-band bytes moving while a high-band request waits. That is the definition of the fault, and it is the only quantity in the HAR that cannot be explained away by bandwidth.

PerformanceObserver Snippet for Real-User Queue Measurement

The PerformanceResourceTiming interface exposes fetchStart, connectStart, and requestStart. The gap between fetchStart and whichever of connectStart or requestStart comes first is the resource’s time spent waiting in the priority queue.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.entryType !== 'resource') continue;

    // Queue wait: fetchStart is when the browser decided to fetch.
    // connectStart (or requestStart if connection was reused) is when
    // the network stack actually began work. The gap is scheduler delay.
    const networkStart = entry.connectStart > 0
      ? entry.connectStart
      : entry.requestStart;
    const queueWait = networkStart - entry.fetchStart;

    // Flag resources where the scheduler held them back for over 100 ms —
    // these are candidates for fetchpriority tuning.
    if (queueWait > 100 && entry.transferSize > 0) {
      console.warn('Priority queue stall detected', {
        url: entry.name,
        protocol: entry.nextHopProtocol,
        queueWaitMs: Math.round(queueWait),
        ttfbMs: Math.round(entry.responseStart - entry.startTime),
      });
    }
  }
});

// buffered: true captures resources that loaded before the observer was registered
observer.observe({ type: 'resource', buffered: true });

Two cautions when this graduates from the console to a real-user monitoring pipeline. First, cross-origin entries report zero for every timestamp between fetchStart and responseEnd unless the origin sends Timing-Allow-Origin, so a third-party asset will silently report a queue wait of zero rather than a large one — filter on entry.connectStart > 0 before aggregating, or your worst offenders vanish from the data. Second, report percentiles rather than means. Queue wait is bimodal: a resource either gets a slot immediately or waits for a whole wave, so the mean sits in a valley where almost no real request lands. Track p75 and p95 per resource initiatorType and alert on the p95.

Lighthouse Audit Checks

• “Preload key requests” — Lighthouse flags High-priority resources discovered late in the waterfall. Fix by adding <link rel="preload"> in <head>.
• “Avoid chaining critical requests” — Lighthouse highlights dependency chains where resource A must finish before B starts. Flatten chains by preloading B alongside A.
• “Efficiently encode images” — Lower file size reduces Content Download time, making the queue wait portion of total load time proportionally larger and more worth fixing.

Treat all three as pointers rather than verdicts. Lighthouse runs one synthetic load on one throttling profile, and priority faults are load-order faults, which means they are sensitive to timing jitter that a single run cannot characterise. Confirm anything Lighthouse flags against field data before you act on it, and confirm anything it does not flag against your own HAR analysis, because none of these audits look at the priority column at all.

Edge Cases and Gotchas

CORS and MIME Type Mismatches Cause Double Fetches

Every <link rel="preload"> must specify an as attribute that matches the resource’s actual MIME type, and the crossorigin mode must match the mode the consuming element will use. Mismatches cause the browser to treat the preload and the actual fetch as different cache keys, loading the resource twice.

Preload Scanner Limitations in Single-Page Applications

The preload scanner only reads the initial HTML response. In a client-rendered or hydrated SPA, resources inside components that are dynamically imported or rendered after hydration are invisible to the scanner. Render-blocking resource identification patterns can help you move critical resources back into the initial HTML, but for resources that genuinely cannot be in the HTML, use the JavaScript fetch() API with priority: 'high' as early as possible in the module execution graph:

// In the app entry point — not inside a component lifecycle hook —
// fetch the critical resource before any rendering work starts.
const criticalData = await fetch('/api/above-fold-content', {
  priority: 'high', // maps to fetchpriority="high" semantics
});

loading="lazy" Overrides Your High Hint

Lazy loading and priority hints are evaluated at different moments and the lazy attribute wins. An <img loading="lazy" fetchpriority="high"> is not requested at all until the intersection check runs, which happens after layout — so the hint applies to a request that starts hundreds of milliseconds late, and Chromium’s in-viewport promotion never fires because the image was never in the initial batch. This is the single most common way a hero image loses its priority in a component library that applies loading="lazy" by default, and the fix is to exempt the first image rather than to strengthen the hint. Fixing lazy-loaded LCP image regressions covers the framework-level variants of the same mistake.

A Service Worker Can Silently Reset Priority

When a service worker handles a fetch event, the request that reaches the network is the one the worker issues, not the one the page created. fetch(event.request) forwards the original Request with its priority intact. Constructing a fresh request — fetch(event.request.url), or new Request(url, { headers }) — discards fetchpriority along with mode, credentials and destination, and the outgoing fetch is scheduled at the default for its type, which for an image is Low. The symptom is distinctive: the hint works on a first, uncontrolled load and stops working on every subsequent load once the worker is active.

self.addEventListener('fetch', (event) => {
  // Correct: the original Request carries destination, mode and priority.
  event.respondWith(
    caches.match(event.request).then((hit) => hit || fetch(event.request))
  );
  // Wrong: fetch(event.request.url) drops fetchpriority and re-defaults it.
});

Redirects Cost a Round Trip the Queue Does Not Refund

Chromium preserves the assigned priority across a 3xx redirect, so the resource does not lose its band — but the redirected request re-enters the socket pool as a new request, and on a cold connection to a new origin it pays DNS, TCP and TLS again. A fetchpriority="high" hero served through a redirecting image CDN can therefore be first in the queue twice and still arrive after an unhinted image on an already-warm origin. Resolve hero URLs to their final location in the markup; hints cannot compensate for an extra round trip.

Speculative Loads Sit in a Band of Their Own

Prerendered pages, speculation-rules prefetches and Early Hints preloads all enter the queue with different assumptions. A prerender runs an entire document’s request graph in the background at the bottom of the ordering, and its internal priorities are relative to each other, not to the foreground page. An Early Hints 103 preload, by contrast, arrives before the HTML and takes its band from as alone — there is no element yet to carry a fetchpriority attribute, so getting as right is the only control you have over it.

HTTP/2 Stream Prioritisation Is Not a Substitute

HTTP/2 multiplexes streams over one connection, which removes the HTTP/1.1 six-connection limit — but it does not automatically schedule streams by browser priority. The browser sends priority signals to the server via PRIORITY frames (deprecated in RFC 9218, now replaced by the Priority request header). Server support is inconsistent. Many CDN edge nodes honour browser priority hints only partially, or ignore them entirely. This means client-side fetchpriority tuning remains essential even on HTTP/2 and HTTP/3 connections.

Head-of-line blocking at the TCP level — where a single dropped packet stalls all streams — is a further reason to audit scheduling under packet-loss conditions. HTTP/3 over QUIC eliminates TCP HOL blocking, but stream scheduling between high- and low-priority requests is still affected by the server’s implementation of RFC 9218. See mitigating head-of-line blocking for protocol-level remediation.

<link rel="preload"> Without a Matching Consumer Triggers a Warning

If you preload a resource but no element ever consumes it within a few seconds of page load, the browser emits a warning in the DevTools Console: “The resource was preloaded but not used within a few seconds from the window’s load event.” This wastes bandwidth and occupies a high-priority slot. Audit with the Lighthouse “Preload key requests” audit and cross-check every preload against its consuming <img src>, <script src>, <link rel="stylesheet">, or font-face declaration.

FAQ

Does fetchpriority guarantee the browser loads a resource first?

No. fetchpriority is a scheduling hint, not a command. The browser balances it against available connections, bandwidth estimates, and render-blocking constraints. A VeryHigh hint is respected under normal conditions but can still stall if all connection slots are occupied by earlier High-priority requests.

What happens if I add fetchpriority="high" to a preloaded font without crossorigin?

The browser performs two separate fetches: one from the preload link (no CORS headers) and one from the @font-face rule (which requires CORS for cross-origin fonts). The preload is wasted and the font loads late. Always pair cross-origin font preloads with crossorigin="anonymous".

Can HTTP/2 multiplexing eliminate the need for fetchpriority hints?

Not reliably. HTTP/2 multiplexes streams over one connection but relies on server-side priority trees to order them correctly. Many CDNs and servers do not implement RFC 9218 stream prioritisation faithfully, so explicit fetchpriority hints remain necessary to signal intent to the browser’s own scheduler.

Why do High-priority requests sometimes show long Stalled times in DevTools?

Stalled time accumulates when all available connection slots are occupied. Under HTTP/1.1 the limit is 6 per origin; under HTTP/2 it is the server’s MAX_CONCURRENT_STREAMS setting. Even a VeryHigh priority request must wait in the queue until a slot frees. Reducing low-priority asset count or switching to HTTP/2 eliminates most stall bloat for origins that currently use HTTP/1.1.

Does Chromium automatically upgrade LCP image priority mid-flight?

Yes, but only after the LCP candidate is identified, which may happen after the initial queue assignment. If the image is discovered late — injected via JavaScript or loaded inside a lazily-rendered component — it misses the early boost. An explicit fetchpriority="high" attribute on the <img> tag or a <link rel="preload"> in <head> ensures the upgrade applies from the very first scheduling pass.

Does fetchpriority="low" stop an image from downloading?

No. A low hint reorders the request; it does not cancel it. The bytes still arrive, just later and behind everything in a higher band. If you want the request not to happen at all until the user scrolls, that is loading="lazy" or an IntersectionObserver. The two attributes solve different halves of the problem and are usually correct together: lazy loading decides whether to request, fetchpriority decides when among the requests you have decided to make.

How many resources can I mark fetchpriority="high" before the hint stops working?

Two or three per document, in practice. Priority is a relative ordering, so twelve high hints recreate the original queue with a new label on it. Worse, on an HTTP/1.1 origin those twelve requests fill the six sockets and then stall each other, which is measurably worse than no hints at all because the browser’s own heuristics would at least have interleaved a stylesheet in there. Reserve the band for the LCP resource and, at most, one or two assets that must arrive alongside it.

Does resource priority survive a service worker?

Only if the original Request object is passed through. fetch(event.request) preserves the priority the page assigned. Building a new request from event.request.url discards fetchpriority along with the rest of the request’s state, and the outgoing fetch is scheduled at the default for its destination — Low for an image. The giveaway is a hint that works on the very first load and never again.

Is fetchpriority the same thing as the HTTP Priority request header?

No, though they are related. fetchpriority controls the browser’s own internal ordering: which request gets a socket or a stream, and when. The RFC 9218 Priority header is what the browser subsequently tells the server about that decision, as an urgency value and an incremental flag. The first always takes effect because the browser implements it; the second only matters if your origin or CDN reorders responses, and many do not.

Why does DevTools show Highest when Chromium’s enum says VeryHigh?

They are the same tier under two names. Blink’s ResourceLoadPriority enum uses VeryHigh, High, Medium, Low and VeryLow; the Network panel displays Highest, High, Medium, Low and Lowest. HAR exports use the DevTools spelling in the _priority field, so any script that parses HAR files should match on Highest and Lowest rather than the enum names.

Should I preload the LCP image if it is already an <img> in the initial HTML?

Usually not. A preload link buys two things — earlier discovery and a higher band — and an <img> already in the initial HTML has been discovered by the preload scanner at essentially the same moment the <link> would have been. All that remains is the band, and fetchpriority="high" on the element itself provides that with one attribute instead of a second tag that has to be kept in sync with srcset, sizes and any URL change. Preload earns its place when the image is a CSS background, is chosen by JavaScript, or lives below a large block of blocking markup.

Related

• Chrome vs Safari vs Firefox: priority differences
• How browser fetch priority affects LCP
• Diagnosing request queueing and stalled time
• Script loading: async, defer and execution order
• Fixing lazy-loaded LCP image regressions
• Render-blocking resource identification
• Cache interaction and stale-while-revalidate
• Mitigating head-of-line blocking

Up: Core Browser Loading Mechanics & Priority Queues