If optimizing was only as simple as adding a few attributes. But this time, it really is and it's even easier to use than image preloading.
It's not often that one can improve performance with a single line of code. But since April 2022, there's another one. Actually, today's one-liner (or rather, single attribute) already is around for a while as I shared on LinkedIn. And you might even heard of it. But it also lead to confusion.
Meet the fetchpriority
attribute
That's all there is, just a fetchpriority
attribute. You might have heard of its predecessor, which was the fetchpriority
attribute. But after contemplating, the final attribute name became fetchpriority
. If this doesn't illustrate things yet, here's a coding example:
Browser support for the fetchpriority
attribute
The fetchpriority
attribute only is supported in a few browsers. So this means using this attribute will lead to progressive enhancement:
- it will improve image loading in browsers that are or will support this attribute in the future;
- other browsers will just behave the same as before.
It's currently Chrome and Microsoft Edge that started supporting this in version 101, both released in the end of April 2022. The Android Browser and Chrome for Android are supporting the fetchpriority
attribute as well.
How to implement the fetchpriority
attribute
The attribute can just be added to the <img>
element. No need to also add it to <picture>
or <source>
elements.
Successor of the importance
attribute
If you were an early bird, you might have started using the importance
attribute. That was its previous name though. You could say that the importance
attribute was the trial version. Naming was too generic/ambiguous. Importance could indicate it would be doing more than just boosting priority, while it's actually limited to changing fetching priority.
They even did a Twitter poll to get naming feedback from the community.
When everything is important, nothing is
I'm quoting Paul Lewis here. But yeah, not all images are as important.The fetchpriority
attribute should only be used for important images. Especially LCP candidates.
You might want to read my to lazyload or not to lazyload above the fold images. Basically, whenever you end up using the loading=lazy
attribute, you should not usefetchpriority=high
. And it often works the other way around, non-lazyloaded images could be a fetchpriority=high
candidate. Maybe not logo's, but the first or biggest visible hero or product image.
How fetchpriority
is improving image and LCP loading
Images always get a lower priority than, for example, stylesheets (which makes sense as CSS is needed to render larger parts of the page). But the image is basically communicating the following to browsers:
"hi there browser, now that you found me, boost me up" 🚀
So, images aren't boosted right away, the browser first has to detect the image element to know how to treat it. This means, the rest of the website #performance should be optimized as well to fully get the benefits.
Preload versus fetchpriority
Preload could lead to better results than the fetchpriority
attribute. However, in most platforms, it's quite cumbersome to create resource hints on the fly based on images in the source code. It involves much more coding, could add up to server response time and could easily lead to issues when forgetting about the image type or media queries.
When doing audits, I often see platforms or developers preloading unused images. For example preloading the PNG file while the website is using WEBP. Or both preloading mobile and desktop banner, without specifying the media attribute.
So, it's quite easy to mess things up when preloading images using resource hints. The fetchpriority
attribute isn't as likely to become a footgun, as you just add it to the original image element.
SPA's and fetchpriority
When using a SPA, chances are that using the fetchpriority
attribute will only come with benefits when serving a page where the image element containing such attribute has been server side rendered. Otherwise, the browser will only learn about an image once client side rendering or full hydration took place. Chances are that most other resources were done downloading, so there is no resource competition once an LCP image needs to be downloaded.
If you know exactly which image for which browsers and viewports is needed, you might be better of preloading an image, for example using the following:
<link rel="preload" href="mobile-banner.jpg" as="image" type="image/jpeg" media="(max-width: 768px)">