default to decoding: async

[sanjaiyan-dev]

Hi, this PR aims to achieve a minor performance improvement by implementing the following changes:

1. Making the decoding attribute in the image tag asynchronous (similar to Next.js - https://nextjs.org/docs/app/api-reference/components/image#other-props):
   • This change improves performance by allowing images to be decoded asynchronously, similar to how it's done in Next.js. As a result, the browser can continue rendering the page without waiting for all images to be fully loaded, leading to faster initial page rendering.

[danielroe]

note that there is already a PR open for fetchpriority implementation: #989

[sanjaiyan-dev]

note that there is already a PR open for fetchpriority implementation: #989

Hi @danielroe, and I apologize for adding fetchpriority I have now removed it. Sorry for the inconvenience :)

[Tragio]

@sanjaiyan-dev @danielroe I wonder if an image that has the preload prop shouldn't have decoding: sync 🤔

[sanjaiyan-dev]

@sanjaiyan-dev @danielroe I wonder if an image that has the preload prop shouldn't have decoding: sync 🤔

@sanjaiyan-dev @danielroe I wonder if an image that has the preload prop shouldn't have decoding: sync 🤔

Hi @Tragio,

Sorry for the late response.

Actually, the preload attribute is related to speeding up the loading of the response, while the decoding attribute helps in handling image rendering by the browser. So, using decoding: async in conjunction with preload is okay.

I believe you may have confused it with the loading="lazy" attribute.

[pi0]

Thanks for this PR. Is there any benchmark reference btw that enabling async decoding enables overall performance? I like to see it because changing browser defaults should usually have strong reasons specially for a default.

[sanjaiyan-dev]

Thanks for this PR. Is there any benchmark reference btw that enabling async decoding enables overall performance? I like to see it because changing browser defaults should usually have strong reasons specially for a default.

I'm extremely sorry, but currently, I don't have any benchmark results. However, this is set as the default in Next.js and Astro js.

Here is an article about deciding asynchronously: link for the article.
Next js Documentation-: https://nextjs.org/docs/pages/api-reference/components/image#other-props

[pi0]

Thanks for the links. I think i remember the article by addy from past from few years ago and i guess we also made an experiment with @farnabaz that at least ~2 years ago it wasn't a positive improvement for images that are expected to be in the initial viewport with async decoding.

I will check this with chrome team in this week.

[Tragio]

@sanjaiyan-dev @danielroe I wonder if an image that has the preload prop shouldn't have decoding: sync 🤔

Hi @Tragio,

Sorry for the late response.

Actually, the preload attribute is related to speeding up the loading of the response, while the decoding attribute helps in handling image rendering by the browser. So, using decoding: async in conjunction with preload is okay.

I believe you may have confused it with the loading="lazy" attribute.

Yes, my question is if we are preloading an image is because we want to to render it as fast as possible, for example, to reduce LCP. So how would it be affected? If we are preloading and saying to the browser it is not very important to render?

If I'm not mistaken, Firefox is the only one that defaults to async. Safari only sets to async in some specific scenarios.

[sanjaiyan-dev]

@sanjaiyan-dev @danielroe I wonder if an image that has the preload prop shouldn't have decoding: sync 🤔

Hi @Tragio,
Sorry for the late response.
Actually, the preload attribute is related to speeding up the loading of the response, while the decoding attribute helps in handling image rendering by the browser. So, using decoding: async in conjunction with preload is okay.
I believe you may have confused it with the loading="lazy" attribute.

Yes, my question is if we are preloading an image is because we want to to render it as fast as possible, for example, to reduce LCP. So how would it be affected? If we are preloading and saying to the browser it is not very important to render?

If I'm not mistaken, Firefox is the only one that defaults to async. Safari only sets to async in some specific scenarios.

Hi @Tragio,

The decoding attribute in HTML instructs the browser to decode images in parallel with content, in a separate thread. Currently, images are decoded along with the main thread, causing small disruptions in the UI. By using the decoding="async" attribute, it helps to render both content and images simultaneously, improving performance and reducing lag.

For more references, please visit: https://cloudinary.com/blog/guest_post/asynchronously-load-and-decode-images#html_code_lt_img_gt_code_decoding_attribute

[rylanharper]

Hey everyone! Just checking in to see if this be implemented next release?

I actually posted an issue about page rendering issues with nuxt-img and nuxt-picture due to the :sizes attribute exceeding ~2400 here (there is literally a visual rendering issue). It seems by adding decoding="async" the issue is resolved on both local and live environments.. It is still somewhat finicky on pages with a lot of images (with a larger srcset values) since the v1.0.0 release, but the issue seems to be connected to decoding the image in parallel with the other page content. I know not many devs have their srcset sizes going past ~640, but its pretty common to have have srcsets going up to ~2400.

Anyways, I hope this can be merged next release

[rylanharper]

Hey @pi0, just checking on updates for this. Thanks!:)

[danielroe]

we've decided not to default to decoding=async, but thank you for this PR 🙏