Add option for fetchpriority attribute within "image loading" area on image field formatter

Would it be better to add a selector with three options?

• Priority: high
• Priority: normal (no attribute added; default)
• Priority: low

Would it be better to add a selector with three options?

I could see that, although I'm not sure of a regular use case for the fetchpriority to be low.

I think a common scenario would be where you have multiple items in a carousel where only one item would be visible until the visitor specifically selected it to show the next slide. Of course this would be completely implementation-specific, e.g. it could cause complications if the carousel automatically rotated.

@damien

There is also a discussion here: 📌 Add image preload option to help boost actual and perceived performance Needs work on adding extra options to this list.

With Lighthouse transitioning to "insights" instead of legacy "audits", fetchpriority is a new key signal for image delivery and LCP optimization. I hope this will stoke renewed interest and forward momentum on this issue.

Seems to me that theres not really a use case for specifying anything other than fetchpriority="high" because the default would be no explicity fetch priority and therefore fallback source order. Images located earlier in source order that should be set explicitly "low" seems like an anti-pattern and a true edge case, since Accessibility best practices dictate that the DOM order should match rendered order.

I think it would be good to have all options available. Although we see it as an edge case, it may be useful for others.

Here is an article with a section about using the `low` option on above the fold images (as @damien already said a carousel is one of the scenarios).

The data model and schema should support all fetchpriority values — no question there. But I’d question the utility of exposing them at the image field formatter level.

Take the carousel example: there are (at least) two common patterns in Drupal:

1. A multi-cardinality image field used as the image source, or
2. A series of entities (e.g. paragraphs, ECK) each with a single image field.

In both cases, there's no reliable context at the field formatter or view mode level to determine which images are visible at page load. Exposing fetch priority there risks encouraging awkward architectures — e.g., splitting fields just to differentiate high vs low.

The complexity only increases with variations like random first slides or responsive carousels showing N slides. Handling these correctly almost always requires custom logic (alter hooks, preprocess).

A UI trying to cover this would have to offer nuanced options like:

• Unspecified (let browser decide)
• High (for LCP-critical images)
• Low (for images above the fold but not visible initially)

For multi-cardinality:

• First is high, others unspecified
• First is high, others low
• First N are high, rest low/unspecified

…which quickly gets unwieldy and still doesn’t address entity-based carousels.

In short, this might be better solved downstream (e.g., in preprocess) where real context exists.