How the image decoding attribute affects LCP

The decoding attribute on an image is one of the most widely copied and most widely misunderstood image hints on the web. It does not defer the network fetch, and it does not control lazy loading. It only tells the browser when decoding the image can happen relative to the rest of the render, which is a subtle effect with a smaller impact on page speed than loading or fetchpriority.

What it controls

Every image the browser displays must be decoded from its compressed format to the pixels that get painted. The decoding attribute is a hint about when that decode happens. It has three values, and the browser is allowed to treat it as a hint rather than a command because different engines implement their defaults differently.

• sync asks the browser to decode synchronously and present the image atomically with surrounding content, so the image and the text appear together rather than the image popping in afterwards.
• async asks the browser to decode asynchronously, letting other content paint first and freeing the main thread from the decode work.
• auto is the default and signals no preference, in which case the browser chooses, with Chromium historically leaning toward sync and Firefox toward async.

Crucially, decoding does not touch the network request. An image tagged decoding="async" is still fetched at the same time the browser decides to fetch it. Only loading="lazy" and fetchpriority affect when and how a request is made, and loading and decoding are separate knobs.

The three values

The choice is really a trade between a perceptual stall and a brief main-thread decode.

With sync, the browser holds the rendering back until the decode finishes so the image does not appear as an empty box. The downside is a small main-thread stall during which the rest of the frame waits. With async, the rest of the content renders first and the image appears when its decode completes, which can look like a pop-in if the image is large and slow to decode.

The HTML spec defines auto as the missing-value default, but implementations disagree on what it maps to, which is why advice about this attribute often sounds contradictory. None of the three values affects whether the image loads; they only affect the frame in which the decoded result appears.

Effect on LCP

Because the attribute does not change when the image is fetched, its effect on largest contentful paint, LCP, is small and mostly cosmetic. For the LCP element, sync is the common choice because an atomic paint keeps the hero in step with the surrounding text and looks more correct to users, even though this can delay the metric fractionally. The web community is split on which value nets the better LCP score, and the measured difference is small enough that different browsers disagree on the best default.

The far larger wins come from the attributes alongside it. For an above-the-fold LCP candidate, keep it eager with fetchpriority="high" so it is fetched promptly and with high priority. For below-the-fold images, use loading="lazy" so the fetch itself is deferred, and decoding="async" so the decode never stalls the main thread. Set explicit width and height or a CSS aspect-ratio on every image so the layout does not shift while it loads.

Treat decoding as the micro-optimisation it is. When an LCP image is slow, first question image size, format and whether it is fetched eagerly, before reaching for the decode hint. See improve LCP, lazy load images and fetchpriority and LCP.