The decoding attribute is a browser hint about how image decoding should relate to other presentation work. It is not a compression setting and does not reduce transferred bytes. Its visible impact can vary with image size, browser, device, cache state, and the rest of the page.
Decide whether an explicit decoding hint improves presentation for a defined image role without hiding a more important transfer or layout problem.
Repeatable method
1. Choose a stress case
Use a sufficiently large image and a controlled test page. Tiny icons may not make decode behavior observable.
2. Build equivalent variants
Create default, async, and sync markup variants with identical image bytes and layout. Change only the decoding attribute.
3. Record a performance trace
Use a cold cache and capture main-thread tasks, image decode activity, paint timing, and visual progression.
4. Repeat on relevant devices
A desktop workstation can hide decode cost that matters on a lower-powered phone. Treat browser behavior as implementation-specific.
Build an illustrative comparison fixture
Use one page with two otherwise identical image blocks: one image carries decoding="async"; the other omits the attribute. Give both a stable width and height, the same source file, identical CSS, and labels that do not change layout. This is a fixture for observation, not evidence that either choice is faster.
| Field to register | Illustrative value or note |
|---|---|
| Image candidate | hero-1600.jpg (replace with your file) |
| Viewport / DPR | 1440 × 900 / 1× (record actual) |
| Cache state | Cold or warm; do not mix runs |
| Comparison | Async attribute versus omitted attribute |
| Observed effect | Trace, screenshots, and visual notes; no assumed winner |
Repeat only after changing one condition at a time. If decoding behavior is not visible in a trace or the image is not relevant to the rendering path being studied, record that limitation rather than inferring a performance result.
What to record
Record device, operating system, browser version, image dimensions and bytes, cache state, decoding value, trace markers, paint timing, and any visible blank or partial state.
A result belongs to the source file, encoder, settings, browser, viewport, cache state, and date that produced it. Repeat the test on representative files before changing a production workflow.
Common mistakes
- Claiming async reduces file size
- Changing image format between variants
- Testing only on a powerful desktop
- Using sync broadly without evidence
Verification checklist
Repeat traces, compare screenshots or recordings, ensure intrinsic dimensions reserve space, and verify the likely LCP image still starts early. Prefer the simplest markup if no repeatable difference appears.
Primary references
Related lab notes
About this guide
We distinguish documented platform behavior from our workflow recommendations. See the testing methodology, editorial policy, and corrections log.