Repository navigation
Fetchpriority - add a fetchpriority=high attribute to the non-lazy image(s) #477
Description
Overview
- Proposed module name: Fetchpriority
- Proposed module slug: fetchpriority
- Proposed module owner GitHub username(s): pbearne, adamsilverstein
About the module
Adding the fetchpriority attribute high attribute to the LCP (or first large) image on the page should improve the page's LCP, because it tells the browser to prioritize loading that image.
We can build this as a module (possibly experimental), then measure its impact on performance. Note: as of this writing, fetchpriority is only supported in chrome and edge.
Purpose
Scope
WordPress already determines which image is most likely to be the "LCP" image in wp_get_loading_attr_default, excluding the loading=lazy attribute. We can leverage this to add fetchpriority=high to those same images, which should cause the browser to prioritize their load.
Rationale
fetchpriority is a new approach to priority hinting that improves on features like preload. Adding this module will let the performance team test this feature as a potential improvement for core.
Other
Read this document for the details: https://web.dev/priority-hints/#the-fetchpriority-attribute
Activity
mxbclang commentedon Aug 17, 2022
To be discussed in August 23 performance chat.
gilbertococchi commentedon Aug 22, 2022
+1 about this experimentation.
I believe this would be a game changer for most of the WP sites using Render Blocking resources where the main page content is an image.
Below a small image showing the effect of
fetchpriority=highadded to a Featured image on a WP site, Image starts to be downloaded way earlier, increasing the chance to deliver the image quickly to sites also on Budget hosting.eugene-manuilov commentedon Aug 23, 2022
Just want to say that we need to make sure we add the
fetchpriority=highattribute based on presence of theloading=lazyattribute in an image. We can't use thewp_get_loading_attr_defaultfunction to determine wether an image has lazyloading or not.mehigh commentedon Aug 23, 2022
Here’s where I read about this, and then tried it out
https://web.dev/priority-hints/#using-preload-after-chrome-95:~:text=Priority%20hints%20can%20complement,with%20fetchpriority%20%3D%20%22high%22.
In short -> if an image preload is added, it’s added to the queue early, but with a low priority -> and that’s because of the type of resource it is (an image).
If the preload tag receives this extra attribute fetchpriority="high" - as it should be used on a LCP image, that switches the priority levels (not on every browser) and maintains a high priority in the network queue (and wouldn’t be pushed for later by render blocking resources for example).
This is a nice to have, but rather granular, advanced type of optimization when there’s a high certainty that the image is the LCP for the particular page.
Since preload is a mandatory fetch and not a hint, using it wrong can negatively impact performance (like slowing down things when preloading with a fetchpriority of high a ton of resources).
Outside of this exact specific context -> the LCP image using a responsive preload + fetchpriority high, I didn’t encounter a scenario that mandated using it in production for a performance gain.
A preload for a style tag or script tag automatically received a high priority, so setting the fetchpriority of high made no difference.
So as with everything web performance 🙂 it depends.
But yes, it’s a clear use-case where this attribute can benefit.
I didn’t see it yield such a big difference in my tests when placed on an image tag though, while the preload made a bigger impact.
Grain of salt addition - my experiment was limited to sites with large HTMLs (300KB+) - so not specifically 'smack' in the middle of an average WP site, and the conclusion drawn was going towards the preload approach as the go-to strategy.
tunetheweb commentedon Aug 23, 2022
FYI, more guidance on it here: https://web.dev/optimize-lcp/#optimize-the-priority-the-resource-is-given.
In short, adding it to the LCP
<img>tag should allow Chromium-based browsers to start fetching it early (as shown in the waterfall example in #477 (comment)). It can also be added topreloadlinks for images that are not immediately discoverable from the raw HTML.You are correct it's not needed for script or CSS tags in the head (with or without preload) since they are already high priority, so one of the main benefits is for LCP images which are low-priority until the initial layout and render as they have, in the past, been considered less important as not render-blocking. LCP has bumped the importance of this for LCP images from that past thinking.
It's also possible to lower the priority of less-important resources (e.g. some scripts), but will leave that aside as that's not what is being proposed here.
And yes, should avoid overusing this: If you prioritise everything, then you're basically prioritising nothing!
gilbertococchi commentedon Aug 24, 2022
Hi Mike, as Barry correctly said, the
fetchpriority=highattribute could be simply added on theIMGtag without need to add a Link Preload in the Head.That's the first real benefit in my opinion, because if a Wordpress Website may have a Render Blocking JS in the Head (like jQuery that is pretty common in my experience) by simply adding
fetchpriority=highto the post largerIMGtag the Image Network Request would start earlier at a similar time of the Render Blocking JS Network Request in the Head (see my screenshot on comment #issuecomment-1221997449).mehigh commentedon Aug 24, 2022
Agree, the adding on the img tag is a positive. What I'm hoping is that it won't over-extend: for a bunch of images to not intentionally receive fetchpriority=high when they're not lazy loaded, but rather for the specific first / featured image or whatever logic we want to add here.
pbearne commentedon Aug 24, 2022
If no one what to code this I will do it
its just a few lines of code with new filter wp_content_img_tag
gilbertococchi commentedon Aug 25, 2022
@mehigh I agree with your concerns, it should be ideal that only one image to have fetchpriority=high.
While it's true that this feature is way less dangerous than a misuse of Link Preload IMGs in the Head, it should be controlled somehow, that's why the experiment phase is so important.
I can see that in case of Blog Listing pages (depending by the layout) it may be interesting to have more but it should be up to the theme developer to implement this in my opinion.
Achieving the result to apply the attribute to the first Post Image Thumbnail should be sufficient to increase the chance to deliver the image in a good amount of time.
Gil
gilbertococchi commentedon Aug 29, 2022
@pbearne Thanks for your feedback, it would be great!
It's a great idea to use the wp_content_img_tag filter to detect that and experiment this out.
@adamsilverstein, WDYT?
mxbclang commentedon Sep 12, 2022
Thank you, @pbearne! Assigning this to you for now and moving to To Do.
@adamsilverstein Please see @gilbertococchi's comment above when you get a moment.
felixarntz commentedon Sep 13, 2022
@pbearne I've added you as a module owner here as discussed earlier today, also pushed the corresponding
CODEOWNERSchange to your PR in 280f11d.[-]Module Proposal: Fetchpriority - add a `fetchpriority=high` attribute to the non-lazy image(s)[/-][+]Fetchpriority - add a `fetchpriority=high` attribute to the non-lazy image(s)[/+]mxbclang commentedon Sep 14, 2022
@pbearne @felixarntz Heads up that I've updated this issue and #528 to remove the module proposal labels/title (since we're now using this for the module implementation itself) and I've created and added a new label for this new module.
felixarntz commentedon Sep 14, 2022
@bethanylang Fair point. I was thinking that we can also use the module proposal to code the first piece of the module against it once it's approved, but probably cleaner indeed to have a more targeted issue. Maybe for next time I'd suggest we then open an entirely new one so that we keep the module proposal as is for history.
mxbclang commentedon Sep 14, 2022
@felixarntz Yep, that's what we usually do, but y'all got started without me! Will do for next time.
felixarntz commentedon Sep 14, 2022
@bethanylang Sorry! 🤣
adamsilverstein commentedon Nov 17, 2022
Note that based on this comment Gecko (Mozilla) plans to implement this in Q1 of 2023.