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

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: #3309016: Add image preload option to help boost actual and perceived performance 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 as affected by large images above-the-fold. 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 explicit fetch priority and therefore fallback to 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, explicitly setting "low" on some images might be better solved downstream (e.g., in preprocess) where real context exists, whereas setting "high" on a single hero image field is an easy and common use case that can and should be exposed at the field formatter level.

The challenge here is coming up with any other real world scenarios where setting "low" is actually beneficial. The carousel use case seems to be the only one where you have images above the fold that are intentionally hidden at page load time.

Add an option for fetchpriority attribute on image field formatter with multiple options
Version 10.5.3

Thanks! I'm test it. All works good.

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

Thanks for working on this and for creating a patch. Before we can review this, we need a merge request against 11.x, so that we can see the results of the pipeline. See Using GitLab to contribute to Drupal for extensive documentation on the development process, if needed. Also, the patch is at least missing an update of the config schema, I think, and maybe it would be better to add the option to ImageFormatterBase. We'd probably also need tests for the new option. But we can look into all of that more once we have the MR ready. Setting to Needs work for that.

I applied the patch successfully to Drupal 11.3 on PHP 8.4

When editing the display options for an article, I see PHP warnings regarding the responsive image field:

Warning: Undefined array key "fetchpriority" in Drupal\responsive_image\Plugin\Field\FieldFormatter\ResponsiveImageFormatter->settingsForm() (line 185 of /app/web/core/modules/responsive_image/src/Plugin/Field/FieldFormatter/ResponsiveImageFormatter.php)

The responsive image patch does show the fetchpriority properly when rendering.

It would be nice to also have the fetchpriority option on the image field.

Agreed with #9 there's no use case for setting 'low' in the UI, if one shows up we could add that later as long as the initial schema supports it.

One other thought here - this only makes sense when loading is set to eager, but also when loading is set to eager it's very likely you also want fetchpriority=high for images that are shown via a field formatter. So could probably use states to conditionally show the checkbox and maybe set a default value to match the loading attribute setting?

use states to conditionally show the checkbox and maybe set a default value to match the loading attribute setting?

Totally makes sense to me. fetchpriority="high" is pointless and contradictory when combined with loading="lazy", so it should be discouraged via #states API hiding.

Still makes a lot of sense to finish this for the reasons given. Next step should be a MR. Maybe this could even become a novice "learning" issue?

Just found this in contrib: https://www.drupal.org/project/image_fetchpriority

Reopened this with a fixed version of the patch attached in #10.

The previous patch used `$item_attributes` as the variable name in [viewElements()](cci:1://file:///core/modules/responsive_image/src/Plugin/Field/FieldFormatter/ResponsiveImageFormatter.php:211:2-279:3),
which no longer matches current core (the variable is now `$attributes`), so it
failed to apply cleanly against 11.4.4 with a "Cannot apply patch" error. Rebased/fixed
the patch and opened an MR:

https://git.drupalcode.org/project/drupal/-/merge_requests/16561

Thanks for working on this.

Issue summary needs an update to use the standard template. Seems like a feature that we probably want test coverage around too.

Problem/Motivation
------------------
There's currently no way to set the `fetchpriority` attribute on images rendered
by the Responsive Image field formatter. This is useful for marking LCP-critical
images (e.g. a hero image) with `fetchpriority="high"`, improving perceived
performance without custom preprocessing.

Steps to reproduce
-------------------
N/A (feature request)

Proposed resolution
--------------------
Add a "Fetch Priority" select option to the "Image loading" settings of the
Responsive Image field formatter (alongside the existing "Lazy loading attribute"),
with options: Unspecified, High, Low. When set, the `fetchpriority` attribute is
added to the rendered `` element.

Remaining tasks
----------------
- Review and commit the MR: https://git.drupalcode.org/project/drupal/-/merge_requests/16561
- Add/verify automated test coverage (added in the MR)

User interface changes
------------------------
Adds a new "Fetch Priority" select field to the Responsive Image field formatter's
"Image loading" settings, next to the existing "Lazy loading attribute" field. The
formatter's settings summary also shows a "Fetch Priority: ..." line when set.

API changes
------------
None.

Data model changes
--------------------
The `image_loading` formatter setting gains a new `fetchpriority` key
(string, nullable, defaults to NULL).

Generated with the help of an LLM.

Thanks but the summary needs to be in the summary :)

It looks like this is ready for review, so changing status.