Short answer: The fetchpriority attribute is a hint that tells the browser how important a resource is compared with others of the same type. Its main use is fetchpriority="high" on the image that becomes the Largest Contentful Paint element, usually the hero image, so it downloads earlier. You can also use fetchpriority="low" for images and scripts that are not needed right away. Use it sparingly: if everything is high priority, nothing is.
Why loading order matters
A typical page asks the browser to download dozens of files: stylesheets, scripts, fonts, images and data. The network connection cannot fetch them all at full speed at once, so the browser assigns each request a priority and schedules them. Stylesheets in the head get high priority because they block rendering. Images usually start at a lower priority, because the browser does not yet know which ones will be visible.
That default works well in general but fails in one important case: the large image at the top of the page. The browser discovers the hero image, gives it a modest priority, and only raises it after layout shows that the image is in the viewport. Meanwhile, other files compete for the same bandwidth. The result is a slow Largest Contentful Paint, often the weakest of the Core Web Vitals on mobile.
Fetchpriority lets you share what you already know: this particular image is the most important thing on the page.
How the attribute works
The attribute accepts three values:
high: fetch this earlier than other resources of the same type.low: fetch this later than other resources of the same type.auto: the default; let the browser decide.
You can use it on images, on <link> elements such as preloads, and on scripts. The fetch() API in JavaScript has an equivalent priority option for data requests.
Two important details:
- It is a hint, not a command. The browser still makes the final decision, and the hint adjusts priority relative to similar resources rather than overriding everything else.
- It is safe to add. It is supported by all major current browsers, and older browsers simply ignore it.
For more background and examples, see the Fetch Priority article on web.dev.
The main use: your LCP image
For most websites, one line of HTML gives the benefit:
<img src="hero.webp" width="1200" height="600" alt="…" fetchpriority="high">To apply it correctly:
- Find the LCP element. PageSpeed Insights names it in the diagnostics under “Largest Contentful Paint element”. It is usually the hero image, a banner or the main product photo, but on text-heavy pages it may be a heading or paragraph, in which case fetchpriority on an image will not help.
- Check each template. The home page, product pages and blog posts may each have a different LCP element, and on mobile it can differ from desktop.
- Make sure the image is not lazy-loaded.
loading="lazy"on the LCP image delays it until layout; remove it for images in the first screen. Our guide to lazy loading images explains where it helps and where it hurts. - Keep the image discoverable in the HTML. If the hero image is set as a CSS background or inserted by JavaScript, the browser finds it late. A normal
<img>tag in the HTML is best. - Retest. Compare LCP before and after in several runs, because single measurements vary.
If the LCP image is a CSS background that cannot easily be changed, a preload link with high priority gives the browser an early hint instead:
<link rel="preload" as="image" href="hero.webp" fetchpriority="high">For responsive images, the preload link can use imagesrcset and imagesizes so the browser picks the same file as the image element. The difference between preload and other resource hints is covered in preload, preconnect and prefetch explained.
Using low priority well
Lowering priority is less famous but just as useful, because it frees bandwidth for what matters:
- Carousel slides that are not visible at first. The first slide may deserve high priority; slides two to five can be low. Carousels have other costs too, discussed in hero sliders and page speed.
- Images near the top that are not the main content. Logos of partners, small decorative images or icons that happen to be in the first screen.
- Non-essential scripts. An async analytics or widget script can be marked low so it does not compete with critical resources during the first seconds.
- Preloads for later. A resource preloaded for use after interaction can be low priority, so the preload does not delay the first view.
A typical page, before and after
Consider a common small business home page: a header with a logo, a large hero photo with a headline, three service images below it, a chat widget and an analytics script. Without hints, the browser downloads the stylesheet and scripts first, then discovers all five images at roughly the same time and gives them similar priority. The hero photo, which is the LCP element, shares bandwidth with the logo and the service images that the visitor cannot even see yet.
With a few changes, the order becomes much better:
- The hero photo gets
fetchpriority="high"and no lazy loading, so it starts downloading right after the critical CSS. - The three service images below the fold get
loading="lazy", so they wait until the visitor scrolls towards them. - The chat widget script is loaded with
asyncandfetchpriority="low", or only after the page has loaded. - The logo stays at the default priority, because it is small and quick anyway.
Nothing on the page changes visually, yet the most important image arrives earlier. That is exactly the kind of improvement Largest Contentful Paint measures.
Common mistakes
| Mistake | Why it hurts | Better approach |
|---|---|---|
| High priority on many images | They compete with each other, so the hint loses meaning | Mark one image, the LCP element, per page |
| High priority plus loading=”lazy” | Lazy loading still waits for layout | Remove lazy loading from above-the-fold images |
| High priority on an image below the fold | Takes bandwidth from what the visitor sees first | Use it only for the first screen |
| Expecting it to fix a huge image | A 2 MB image is still slow at top priority | Compress, resize and use modern formats first |
| Hard-coding it in a shared template | Every page gets high priority on the wrong image | Apply it per template, only to the real LCP image |
Fetchpriority is a fine-tuning tool. It works best on a page that is already reasonably optimised: a fast server response, a compressed image in the right size, and no render-blocking scripts in the way. See responsive images with srcset and sizes for serving the right image size to each screen.
Adding fetchpriority in WordPress and other platforms
You do not always have to edit HTML by hand:
- WordPress core automatically adds
fetchpriority="high"to an image it believes is the LCP candidate, usually the first large content image, and skips lazy loading for it. Check the page source to see whether it chose the right image. - Themes and page builders sometimes output hero images as CSS backgrounds, which bypasses that logic. Switching the hero block to an image element, or adding a preload, fixes this.
- Performance plugins often have a setting for preloading or prioritising the featured image or the first images.
- Other CMS and frameworks commonly provide an option on their image component, often called “priority” or similar, that adds the attribute and disables lazy loading.
After changing anything, view the page source and confirm that exactly one image, the right one, has the high priority hint.
How to check the result
Chrome DevTools shows priorities directly. Open the Network panel, right-click the column headers and enable “Priority”. Reload the page and check that the hero image shows as High and starts downloading early, instead of waiting behind scripts and other images.
Then compare Largest Contentful Paint in PageSpeed Insights before and after. Look at the median of several runs rather than one, and remember that field data from real users takes up to four weeks to reflect the change. If LCP does not improve, check the other parts of LCP: server response time, render-blocking CSS and the image size itself.
How Site AI Audit helps
Site AI Audit runs Google PageSpeed for mobile and reports Largest Contentful Paint alongside CLS and INP, server response time, compression and page weight. Every finding is ranked by impact and comes with a plain-language fix, so you can see whether a slow LCP needs a priority hint, a smaller image or a faster server. Re-checks after a change are part of the paid plans on the pricing page.
Related reading
- Image Optimization for Faster Websites: A Practical Guide
- Defer vs Async: How to Load JavaScript Without Slowing Pages
- Core Web Vitals Explained for Small Business Websites
The bottom line
Fetchpriority tells the browser what you already know: which resource matters most. Put fetchpriority="high" on the one image that is your LCP element, never lazy-load it, use low priority for things that can wait, and check the result in DevTools and PageSpeed Insights. It complements good image optimisation; it does not replace it.
DUK
What does fetchpriority=”high” do?
It tells the browser that this resource is more important than others of the same type, so it should be fetched earlier. It is most useful on the main image that becomes the Largest Contentful Paint element.
Is fetchpriority supported in all browsers?
It is supported by all major current browsers. Browsers that do not support it ignore the attribute, so adding it does not cause errors.
Should I add fetchpriority=”high” to all images?
No. If many images have high priority, they compete with each other and the hint loses its effect. Use it on one image per page, the one that matters most for the first view.
What is the difference between preload and fetchpriority?
Preload tells the browser about a resource early, before it would find it in the page. Fetchpriority changes how important a resource is once it is known. They can be combined for images set as CSS backgrounds.
Can fetchpriority improve my Core Web Vitals?
It can improve Largest Contentful Paint when the LCP image was being delayed by other downloads. It does not help if the image is too large, the server is slow or the LCP element is text.



