fetchpriority="high": one line of code to speed up your site

Reviewing Lighthouse on a client project, the hero image was taking too long to load despite being visible from the very first render. The browser was treating it exactly like the footer icons. There was no misconfigured lazy loading — nor a heavy image payload. Simply put, the browser assigns priorities using heuristics. And those heuristics can fail when the critical image appears in the HTML after other resources. The fetchpriority="high" attribute exists exactly for this: you explicitly tell the browser that this resource is the most important one on the page. No JavaScript. No preload links. No extra configuration. Just a single line of HTML. The impact on LCP varies between 50ms and 200ms depending on the device, but on slow connections in Latin America, it can mean the difference between green and red in a Core Web Vitals audit.

The snippet#

Pure HTML

<!-- Before: the browser guesses -->
<img src="/hero.avif" alt="View of Itapúa from the river" width="1200" height="630" />

<!-- After: you decide -->
<img src="/hero.avif" alt="View of Itapúa from the river" width="1200" height="630" fetchpriority="high" />

In Astro, the <Image /> component accepts the attribute directly:

src/pages/index.astro

---
import { Image } from "astro:assets";
import heroImg from "../assets/hero.avif";
---

<Image
  src={heroImg}
  alt="View of Itapúa from the river"
  width={1200}
  height={630}
  fetchpriority="high"
/>

When to use it and when not to#

fetchpriority="high" is strictly for the above-the-fold hero image and nothing else. Do not put it on icons, carousel images, avatars, or below-the-fold content. Inflating the priority of everything is the same as having no priorities at all.

If you want more granular control (for example, for fonts or scripts), <link rel="preload"> is the alternative. But it comes with a cost: you have to keep the preload in the <head> perfectly synced with the actual src of the <img>. In SSG with Astro, fetchpriority directly on the component is less fragile because it lives right next to the image itself.

fetchpriority vs preload: when to use which?

fetchpriority="high"

A single line on the element. No risk of desync between attribute and src.
Lives right next to the image: if the path changes, the hint changes with it.
Zero extra configuration in the head.

link rel=preload

Full control over crossorigin, as, type, and media queries.
Works for any type of resource: fonts, scripts, CSS.
More granular if you need to load a resource before the parser finds it.

To validate that the hint works, open DevTools → Network → filter by Img → Priority column. The hero image will appear as Highest. If it didn’t change, verify that there are no other resources marked with fetchpriority="high" competing on the same page.

If you already have a CI pipeline with Lighthouse, this measures itself. The TIL on how to set up Lighthouse CI explains how to capture the LCP metric automatically. And if you want broader context on performance in Paraguay, the post on how to reduce CPU consumption in production has the real benchmarks.

Sometimes improving performance doesn’t mean optimizing more bytes, but helping the browser make better decisions.

…g CO₂