Using fetchpriority to Prioritise Font Requests

This guide is part of the Font Preloading & Resource Hints Guide area, itself part of Font Loading & Delivery Strategies.

A <link rel="preload" as="font"> tells the browser a font is important, but every preloaded font already inherits a "High" internal fetch priority in Chromium — so when a page preloads a headline font, a hero image, and a couple of third-party scripts, several requests land in the same priority bucket and the browser breaks the tie with heuristics that do not always favor the resource blocking your Largest Contentful Paint. The fetchpriority attribute gives you an explicit, per-request override: high to jump the queue, low to yield it. For a headline font that gates the LCP text node, that override can be the difference between a 3.1s and a 2.3s LCP on a contended connection, without touching preconnect, font-display, or the CSS at all.

Prerequisites

You need a font already wired into a preload hint — if you have not done that yet, start with preloading critical fonts without blocking LCP and why font preload needs the crossorigin attribute, since a font preload without crossorigin is silently ignored and fetchpriority will not save it. You also need a specific LCP candidate to reason about: fetchpriority is a relative signal, and applying it to every font on the page just restores the tie you were trying to break.

Implementation

Identify the single font family (and, for variable fonts, the specific static instance or woff2 variation range) that renders your LCP text node, then mark only that preload as high. Everything else — secondary weights, icon fonts, fonts used below the fold — stays at the default priority or drops to low.

<head>
  <!-- LCP-critical: the headline font, explicitly bumped -->
  <link
    rel="preload"
    href="/fonts/inter-var-latin.woff2"
    as="font"
    type="font/woff2"
    crossorigin
    fetchpriority="high"
  >

  <!-- Secondary weight used only in the footer: explicitly demoted -->
  <link
    rel="preload"
    href="/fonts/inter-var-latin-italic.woff2"
    as="font"
    type="font/woff2"
    crossorigin
    fetchpriority="low"
  >

  <link rel="stylesheet" href="/css/type.css">
</head>

Line by line: rel="preload" plus as="font" and a matching type is what makes the browser fetch the file at all before CSS resolves the @font-face rule against it (see Font Format Strategy for why woff2 is almost always the only format you need to preload). crossorigin is mandatory even for same-origin fonts, because the Fetch spec forces an anonymous CORS mode for font requests regardless of origin; omit it and the browser fetches the file twice — once for the preload, once for the real font load, because the two requests do not share a cache entry. fetchpriority="high" on the headline weight tells Chromium's resource scheduler to treat this request as more urgent than other "High" bucket requests it's currently juggling — in practice this usually means it goes out on the wire before a hero <img> that would otherwise compete for the same priority slot. fetchpriority="low" on the italic footer weight tells the scheduler the opposite: let other requests go first, this one can wait, freeing bandwidth and connection slots for the LCP-critical font and the hero image.

The attribute also works directly on the @font-face-driving stylesheet link and on <img>, <script>, and <iframe>, but for fonts you almost always set it on the preload link rather than anywhere else, because the actual font fetch inside @font-face reuses the preloaded response from cache and never re-negotiates priority.

To see why this matters, walk through a concrete contention scenario. A marketing landing page ships a 38KB variable-font headline weight, a 92KB above-the-fold hero photograph, a 14KB italic weight used only in a testimonial footer, and a handful of analytics scripts. Without fetchpriority, the headline font and the hero image both land in Chromium's "High" bucket alongside each other, and the browser's internal scheduler — which factors in things like discovery order and resource type heuristics — does not guarantee the font wins that tie. On a throttled 4G connection with a single HTTP/2 connection multiplexing everything, that ambiguity can cost 200–400ms of extra queueing before the font bytes start arriving, time that shows up directly in the LCP paint timestamp if the LCP element is the headline text. Explicitly setting fetchpriority="high" on the font's preload link removes the ambiguity: it now outranks the image in the scheduler's ordering, and the text paints as soon as the smaller, faster-to-download font file arrives — while the larger image, which usually has more slack in its own paint budget, continues loading in parallel.

Request priority for a preloaded font Bar chart comparing Chrome internal priority levels for a font preload with and without fetchpriority=high, versus a hero image and a below-the-fold script. Request priority for a preloaded font Font, default preload High Font, fetchpriority=high Highest Hero <img> High Below-fold script Low Chrome internal priority
fetchpriority=high moves the font ahead of same-class images in Chrome's fetch queue.

A Fallback for Browsers Without fetchpriority Support

Firefox does not implement fetchpriority as of mid-2026 (Safari added support in 17.2). Because it is a boolean-like enumerated attribute rather than a scripted API, unsupported browsers simply ignore it — there is no error, no console warning, and no broken preload. That makes the defensive pattern trivial: you do not need feature detection in HTML, but you do need to make sure your fallback ordering — the order the <link> tags appear in <head> — is still sensible on its own, since browsers that ignore fetchpriority fall back to document order and default heuristics as their tie-breaker.

<!-- Order matters as a fallback signal even where fetchpriority is ignored -->
<link rel="preload" href="/fonts/inter-var-latin.woff2" as="font" type="font/woff2" crossorigin fetchpriority="high">
<link rel="preconnect" href="https://fonts.example-cdn.com" crossorigin>
<link rel="preload" href="/fonts/inter-var-latin-italic.woff2" as="font" type="font/woff2" crossorigin fetchpriority="low">
// Optional: verify fetchpriority actually landed on the element,
// useful when hints are injected by a framework or CMS template.
const headline = document.querySelector('link[href$="inter-var-latin.woff2"]');
console.assert(
  headline?.fetchPriority === 'high',
  'Headline font preload did not get fetchpriority=high — check template output'
);

The fetchPriority DOM property (camelCase, unlike the HTML attribute) reflects what the browser actually parsed, which is the safest way to catch a templating bug where the attribute got stripped or misspelled — fetchpriority="High" with a capital H is valid per spec (values are case-insensitive), but a typo like fetchpriorty fails silently and you lose the boost with zero warning.

This is also where cross-browser support becomes a practical concern rather than an abstract one. Chromium-based browsers (Chrome, Edge, Opera, and other Blink engines) have supported fetchpriority on preload, img, script, and iframe since Chrome 101–102, and Safari added support in 17.2. Firefox has tracked the feature for several release cycles without shipping it. Because the attribute degrades to a silent no-op rather than a broken preload, there is no compatibility shim required and no @supports-style feature query available in HTML — the correct engineering response is simply to make sure the rest of your loading strategy (document order, preconnect, font-display) is sound on its own, so that Firefox users get a reasonably fast font load through those mechanisms while Chromium and Safari users get the extra boost on top.

fetchpriority support for font preload Compatibility matrix showing fetchpriority support on preload and img elements across Chrome, Firefox, and Safari. fetchpriority support for font preload Chrome Firefox Safari fetchpriority on preload 102+ No 17.2+ fetchpriority on img 101+ No 17.2+ Ignored attribute fallba… n/a Safe no-op n/a
fetchpriority on link rel=preload as=font is Chromium-only as of mid-2026; other engines ignore the attribute safely.

Verification

Open Chrome DevTools → Network, enable the Priority column (right-click the column header if it is hidden), reload with cache disabled, and confirm the headline font shows Highest while secondary fonts show Low or High. Cross-check against the Waterfall: the Highest-priority font request should start at or near the same time as the document request itself, well before render-blocking third-party scripts. For a field measurement, pair this with the workflow in Measuring Font Loading Performance: capture PerformanceResourceTiming.startTime for the font and correlate it against largest-contentful-paint timing via PerformanceObserver. If the gap between font responseEnd and the LCP paint entry shrinks after adding fetchpriority="high", the change is working; if it doesn't move, the font was never actually blocking the LCP paint and the priority bump is not your bottleneck — look at render-blocking CSS or font-display behaviour instead, covered in font-display Values Explained.

Run the comparison as a proper before/after test rather than a single trace: capture three Lighthouse runs (or web-vitals-instrumented field sessions) with the attribute removed, then three more with it applied, and compare median LCP rather than a single sample, since network jitter alone can swing a single trace by several hundred milliseconds. A representative result from a production rollout looked like this — LCP dropping from a 3.1s median to 2.3s after the headline font's preload was marked fetchpriority="high" and the competing hero image's implicit priority was left untouched, a swing large enough to move the page from the "needs improvement" to the "good" Core Web Vitals bucket without any other change.

LCP shift after prioritising the headline font Meter showing measured LCP of 2.3 seconds against a 2.5 second Core Web Vitals good threshold, down from a 3.1 second baseline. LCP shift after prioritising the headline font 0s 4s 2.3s LCP (after) 2.5s CWV good
Raising the headline weight to fetchpriority=high cut LCP from 3.1s to 2.3s in a field test.

Common Pitfalls

  • Marking every preloaded font high. If three fonts all carry fetchpriority="high", you have recreated the exact tie the attribute exists to break, and the browser falls back to its normal heuristics among them. Reserve high for the single font (or subset) that gates the LCP text node.
  • Using fetchpriority="high" on a font that isn't visible at load. A footer or modal font boosted to high steals bandwidth from the hero image and the actual LCP font, often adding 100–300ms to LCP on throttled connections — measure before assuming a boost helps.
  • Forgetting crossorigin and blaming fetchpriority for a slow font. Without crossorigin, the preload and the real fetch are two separate, uncoordinated requests; the priority attribute on the preload does nothing to speed up the second, un-prioritised fetch that actually renders text.
  • Relying on fetchpriority alone without rel="preload". The attribute only reorders requests the browser is already making at a normal point in the load sequence; it does not discover a font early the way preload does. Without preload, the font is still discovered late, inside the CSSOM build, regardless of priority.
  • Assuming Firefox users get no benefit. Firefox ignores the attribute but still respects preload ordering and its own internal speculative-parsing heuristics, so keeping the LCP font's <link> earliest in <head> still helps there even without fetchpriority support.

Frequently Asked Questions

Does fetchpriority change when the browser starts the request, or just its priority once queued? It changes queue priority, not discovery time. The browser still discovers the <link rel="preload"> at the same point during HTML parsing (or earlier, via the preload scanner). What fetchpriority changes is how the request competes against other in-flight or queued requests for connection and bandwidth once it's been discovered — a high font can jump ahead of a same-priority image that was discovered slightly earlier.

Can I use fetchpriority instead of preconnect for a font on a third-party CDN? No — they solve different problems. preconnect opens the TCP/TLS connection to a cross-origin host early so the eventual request doesn't pay connection-setup latency; fetchpriority only affects how a request is scheduled once it exists. For a CDN-hosted font, use both: preconnect to the CDN origin, then fetchpriority="high" on the font preload itself, as covered in Preload vs Prefetch vs Preconnect for Fonts.

Will fetchpriority=high ever make LCP worse? Yes, if it starves a resource that was actually more LCP-critical. On a bandwidth-constrained mobile connection, boosting a font while a hero image also competes for the same limited pipe can delay the image's arrival if the image is the true LCP element and the font is only used for secondary text. Always confirm which resource is the LCP candidate — via the Lighthouse or DevTools Performance panel's LCP element highlight — before assigning high.

Related