If you've ever analyzed your website with Lighthouse or PageSpeed Insights, you've probably come across a recommendation similar to this:
The LCP image should have fetchpriority="high"
The first time I saw this warning, I was confused.
The website was already well optimized. It was running LiteSpeed Cache, images were compressed, WebP was enabled, lazy loading was configured correctly, Critical CSS was working, and LiteSpeed was even generating preload tags for my hero image.
So why was Lighthouse still complaining?
This question led me to spend several hours researching how modern browsers prioritize resources, what fetchpriority actually does, and why preloading an image is sometimes not enough.
I first encountered this issue while optimizing one of my client's production websites. During the optimization process, I was documenting performance improvements, Core Web Vitals tests, and SEO experiments on one of my own projects. That real-world testing environment helped me compare different optimization techniques and better understand how browsers handle resource prioritization. If you're curious, you can take a look at one of those production projects: Esenyurt Korsan Taksi. It's one of the websites I use to test real-world SEO and Core Web Vitals optimizations.
This article brings together everything I learned about fetchpriority="high"- what it is, when you should use it, when you shouldn't, and why such a small HTML attribute can make a measurable difference to your Largest Contentful Paint (LCP) and overall Core Web Vitals.
What is fetchpriority?
fetchpriority is an HTML attribute that allows developers to give the browser a hint about how important a particular resource is during page loading.
Modern browsers are incredibly intelligent.
Whenever someone visits your website, the browser immediately starts downloading dozens of different resources:
- HTML
- CSS
- JavaScript
- Fonts
- Images
- Icons
- Videos
- API requests
Since all of these resources compete for bandwidth, the browser needs to decide what should be downloaded first.
Usually, it does a pretty good job.
But browsers don't actually know which image is the most important for your visitors. That's where fetchpriority comes in.
For example:
<img src="hero.webp" alt="Hero Image" fetchpriority="high">
This simple attribute tells the browser:
This image is extremely important. Please prioritize downloading it before less important images.
It doesn't make your internet connection faster. It simply helps the browser make better decisions.
Why was fetchpriority introduced?
For many years, browsers relied entirely on their own algorithms.
They looked at things like:
- Is the image visible?
- Where does it appear in the HTML?
- Has the page layout already been calculated?
- Is it inside the viewport?
Most of the time those guesses were correct. Sometimes they weren't.
Imagine a landing page containing:
- one large hero banner
- twelve product images
- several SVG icons
- partner logos
- background decorations
- social media icons
Without any priority hints, the browser has to decide which image deserves attention first. Sometimes it starts downloading gallery images before the hero image.
Sometimes decorative assets compete with the image that users actually see first.
Every unnecessary delay affects Largest Contentful Paint. Google introduced fetchpriority to solve exactly this problem.
Understanding Largest Contentful Paint (LCP)
Largest Contentful Paint, commonly known as LCP, is one of Google's Core Web Vitals.
Instead of measuring how fast your entire website loads, it measures something much more important:
How long does it take until the largest visible content appears on the screen?
That content is often:
- a hero banner
- a featured article image
- a landing page illustration
- a large promotional image
Google recommends keeping LCP below 2.5 seconds. A slow LCP doesn't necessarily mean your server is slow.
Very often it means the browser simply didn't download the most important image early enough.
Preload and Fetch Priority are NOT the same thing
One of the biggest misconceptions I found while researching this topic is that many developers believe image preloading automatically gives an image high priority.
It doesn't. Let's compare both.
Image Preload
<link rel="preload" as="image" href="/hero.webp">
This tells the browser:
You will need this image soon.
The browser starts downloading it earlier.
Fetch Priority
<img src="/hero.webp" fetchpriority="high">
This tells the browser:
Among all images on this page, this one matters the most.
These are two completely different signals.
One starts the download earlier. The other influences download priority.
Using both together provides the strongest possible hint.
Why Lighthouse still complains
Many people believe preload is enough.
Technically, preload only tells the browser that a resource will probably be needed.
It does not explicitly say:
This resource should receive higher priority than other images.
Once the HTML parser reaches multiple <img> elements, the browser still has to prioritize them internally.
Without fetchpriority, it continues relying on its own heuristics.
That's why Lighthouse recommends adding both.
How browsers actually prioritize resources
Think about an airport. There are dozens of passengers waiting to board.
Without special instructions, everyone joins the queue.
Now imagine one passenger is told:
Please board first.
Nothing else changes.
The airplane doesn't become faster.
The runway doesn't become longer.
The order simply changes.
That's exactly how fetchpriority works.
It changes priority—not speed.
This tiny change can reduce waiting time for your most important content.
Should every image use fetchpriority="high"?
Absolutely not.
One of the most common mistakes developers make is adding:
fetchpriority="high" to every image.
For example:
<img fetchpriority="high">
<img fetchpriority="high">
<img fetchpriority="high">
<img fetchpriority="high">
This defeats the entire purpose. If everything is important...
Nothing is important.
The browser ignores excessive priority hints because they stop being meaningful.
When should you use it?
fetchpriority="high" is ideal for:
- Hero banners
- Landing page images
- Featured article images
- The image identified as your Largest Contentful Paint element
- Above-the-fold content
These are the images users are waiting to see.
When should you NOT use it?
Avoid using it on:
- Gallery images
- Product thumbnails
- Team member photos
- Logos
- Icons
- Decorative illustrations
- Images below the fold
- Footer graphics
These resources don't need to compete with your hero image.
Can it improve performance?
Yes.
But it's important to have realistic expectations.
Adding fetchpriority="high" won't suddenly make your website one second faster.
Performance optimization rarely works that way.
Instead, it helps the browser make slightly better scheduling decisions.
During my own testing, I noticed:
- Faster hero image rendering
- Slightly lower LCP values
- Better Lighthouse reports
- More consistent loading on slower mobile devices
The improvements were usually measured in milliseconds rather than seconds.
But in Core Web Vitals, milliseconds matter.
My solution
Since LiteSpeed Cache wasn't adding the attribute automatically to the actual LCP image, I decided to create a small WordPress plugin for my own projects.
The plugin has one simple responsibility.
Whenever LiteSpeed preloads the main hero image, the corresponding <img> element also receives:
fetchpriority="high"
No settings.
No configuration.
No database tables.
No unnecessary features.
Just one tiny improvement that complements LiteSpeed's existing optimization.
Is LiteSpeed doing something wrong?
Not necessarily.
LiteSpeed Cache already provides an impressive amount of automatic optimization.
Every website has a different layout, different themes, and different methods of rendering images.
Determining which image is truly the Largest Contentful Paint element isn't always straightforward.
That's probably one of the reasons why LiteSpeed doesn't automatically add fetchpriority="high" to every preloaded image.
It leaves that decision to developers.
Final thoughts
One thing I've learned after optimizing many websites is that performance isn't always about installing more plugins or buying a faster server.
Sometimes it's about understanding how browsers think.
fetchpriority="high" is a perfect example.
- It's a tiny HTML attribute.
- It doesn't compress images.
- It doesn't reduce file sizes.
- It doesn't improve your hosting.
Yet it helps browsers identify the single most important image on your page and prioritize it accordingly.
If your Lighthouse report recommends adding fetchpriority="high", don't ignore it.
Take a few minutes to identify your LCP image, verify whether it's already preloaded, and make sure the browser also knows that it's your highest-priority visual element.
When combined with proper image optimization, modern formats like WebP or AVIF, responsive image sizes, caching, and intelligent preloading, this small attribute becomes another piece of the performance puzzle.
And as every performance engineer eventually discovers, websites rarely become faster because of one huge optimization.
They become faster because dozens of small optimizations work together.
Top comments (0)