fetchpriority on 27 homepages: 217 values, and 129 of them say low

FIELD TEST · 2026-09-01 · 27 homepages · one request each · fetchpriority on img, link and script

Sample and method: 30 homepages fetched once each on 2026-09-01 with a desktop Chrome user agent, redirects followed, no JavaScript executed. Three dropped out — stackoverflow.com and medium.com returned 403, www.reddit.com returned an 8,393-byte shell — leaving 27. From the delivered HTML we pulled every <img>, <link>, <script> and <iframe> opening tag and matched fetchpriority= inside them.

On 27 homepages read on 2026-09-01, fetchpriority sits on 223 tags across 20 sites. 217 of those carry a value, and 129 of the 217 say low against 45 that say high. It lands on a <link> 153 times and on an <img> 61 times, in a batch that contains 1,556 images. The attribute most people write about as a way to pull the hero image forward is mostly being used to push other things back.

How we measured it

One GET per site, desktop Chrome user agent rather than Googlebot, redirects followed, one attempt each. Nothing was rendered, so every number below describes the HTML the server handed over. Our exit node sits in Osaka, Japan, which matters for any site that varies its markup by region.

Counting was a regular expression over opening tags rather than a full parse: pull every <img>, <link>, <script> and <iframe>, then look for fetchpriority= and read the value beside it. That gives two counts, and they differ by six: 223 tags carry the attribute, 217 of them carry a value, and 6 are empty. Every breakdown by value below is out of 217. The same pass counted 1,556 <img> elements, which is the denominator for everything below that talks about images.

# The same two counts on one of your own pages
curl -sL --compressed -A 'Mozilla/5.0' https://example.com/ > page.html
grep -oiE '<(img|link|script|iframe)[^>]*>' page.html | grep -ci 'fetchpriority='
grep -oiE '<(img|link|script|iframe)[^>]*>' page.html \
  | grep -oiE 'fetchpriority=.?[a-z]+' | sort | uniq -c

Two things this run cannot tell you. Anything a script inserts after load is invisible to us, so a page that sets the attribute at runtime counts as zero here. And we ran no performance measurement of any kind — no field data, no lab run, no LCP element identified on any of the 27 pages. We do not know whether these attributes made a single one of these sites faster.

Reading without rendering is a floor, not a verdict, because Google renders on its own schedule. Search Central states the sequence directly: "Once Google's resources allow, a headless Chromium renders the page and executes the JavaScript." (Understand the JavaScript SEO basics, read 2026-09-01.)

129 values say low, 45 say high

Split the 217 by element and by value and the shape shows up immediately. The low column is not a rounding error, it is the main thing this attribute is doing in the sample.

Those 129 are concentrated in very few hands. www.framer.com carries 99 occurrences and every one of them is low; github.com carries 12, all low; supabase.com carries 8, all low. Three sites, 119 of the 129. One habit: label the things that can wait.

The 45 high values sit somewhere else entirely. developer.mozilla.org has 20 of them, all on <link> elements, alongside 2 marked low. stripe.com has 4, all high. www.nytimes.com has 10 on images. What almost nobody in this sample looks like is a site that raised one hero image and left everything else alone.

fetchpriority lands on link far more often than on img

153 occurrences on <link> against 61 on <img> — two and a half times as many, in a sample where images outnumber every other element type by a wide margin. Of those 61 image occurrences, 43 say auto, which leaves 17 marked high and 1 marked low across all 1,556 images on all 27 homepages.

Per site the distribution behaves like most build-pipeline settings: a few sites do it everywhere, most do it nowhere.

Then techcrunch.com with 4, railway.com, webflow.com and www.theverge.com with 2 each, and nine more sites carrying exactly one. Seven of the 27 carry none at all: about.gitlab.com, news.ycombinator.com, react.dev, slack.com, www.bbc.com, www.notion.com and www.wikipedia.org.

43 values are auto, and 23 of them come from one site

auto is the default. Writing it puts the browser exactly where it would have been with no attribute at all, so those 43 occurrences are markup that is present and inert.

www.netlify.com accounts for 23 of them, and the pattern is total: all 23 of its images carry fetchpriority="auto". The other 20 are on www.nytimes.com, which also ships 10 images marked high. A value applied identically to every image on a page reads as a template emitting its default rather than as a per-image decision. There is nothing broken about that — it is bytes that change no behaviour, and it costs less than the CSS on the same page.

The six tags left out of the 217 are the same story one step earlier. All six are on webflow.com, all six read fetchpriority="", and every one of them sits on an <img> that also carries an empty loading="". A template printed the attribute names and never reached the values. Netlify's 23 filled in the default; these 6 did not get that far.

Only four of 27 sites put high on the first image

The textbook use of this attribute is the large image at the top of the page: mark it high and the browser goes after it before the rest. Four sites in this sample have fetchpriority="high" on the first <img> in their delivered HTML — arstechnica.com, astro.build, www.cloudflare.com and www.nytimes.com. Twenty-three do not.

That first-image test is a rough proxy and we want to be exact about how rough. The first <img> in source order is a candidate for the largest painted element, not the same thing as it. A page can put its real hero in CSS, inside a <picture>, or halfway down the document. We did not identify the LCP element on any of these 27 pages and we ran no speed test on any of them. Four is a count of a markup pattern. It is not a scoreboard.

116 image preloads, and eight of them carry a priority

The 27 homepages ship 116 <link rel="preload" as="image"> elements between them. Eight also carry a priority value: stripe.com with 4, then one each on substack.com, webflow.com, www.theverge.com and www.wired.com.

The three sites that preload the most images write none. react.dev has 30 image preloads, www.notion.com has 24 and supabase.com has 22 — 76 preloads, zero priorities. Whatever reasoning produced those preload lists, priority was a separate conversation that did not happen.

Preloading an image and prioritising it are two different decisions. On these 27 homepages, 108 of 116 preloads make only the first one.

What this means for your site

Four moves, in the order that pays. The first is free and most people skip it.

1. Count what your framework already emits before you add anything. The two largest per-site numbers here, 99 and 23, both look like a build tool writing the attribute on every element of a type.
2. If you want one image early, put high on that one image and nowhere else. A value repeated across every image ranks nothing against anything.
3. Delete auto wherever you find it. It is the default, so removing it changes behaviour by exactly zero and shrinks the HTML.
4. If you already preload an image, treat the priority as a separate call. In this sample the two attributes travel together eight times out of 116.

Same panel, same day, different attributes: the several-sizes side of image markup is in srcset on 1,664 homepage images, and load timing is in loading lazy versus eager. Whether any of it moves search results is an older and much messier question, handled in does page speed affect SEO. To see what an engine receives from your own pages with no script running, see how QueryWin reads a page.

Common questions

How did you measure this?

One GET per homepage on 2026-09-01, desktop Chrome user agent, redirects followed, bodies written to disk, then a regular expression over every <img>, <link>, <script> and <iframe> opening tag looking for fetchpriority= and its value. 223 tags had the attribute, 217 had a value, 6 were empty; the value tables are out of 217. No JavaScript ran. Exit node in Osaka, Japan.

Does fetchpriority="auto" do anything?

It is the default value, so it leaves the browser exactly where no attribute would have left it. In this sample 43 of the 217 occurrences are auto, and 23 of those come from one site that wrote it on all 23 of its images.

Should preload and fetchpriority go together?

They answer different questions and most sites here answer only one of them. Of 116 image preloads counted on 2026-09-01, eight also set a priority. We have no measurement of which arrangement loads faster, and getting one would need a lab run we did not do.

Does this attribute affect rankings?

Nothing in this survey speaks to that. We counted attributes in delivered HTML on a single day, with no speed measurement, no LCP element and no search position anywhere in the data set. Anyone claiming a direction is not getting it from numbers like these.

Why count link and script at all?

Because that is where the attribute mostly lives. Restricting the count to <img> would have returned 61 occurrences and missed the other 156, including all 125 of the low values on <link> that make this survey say what it says.