Image attributes cheat sheet
Image attributes that affect speed or search: width, height, alt, srcset, sizes, loading, fetchpriority and decoding, plus how Chrome ranked a hero image.
In this guide
The attributes
| Attribute | What it does | Use it when | Watch out |
|---|---|---|---|
| `src` | The address of the image. Needed even with srcset | Always | Keep the real address in the HTML. Do not hide it in data-src for the main image |
| `width` and `height` | The image's intrinsic size in pixels, with no unit. The browser uses the ratio to reserve space before the file arrives | Always, on every img | CSS may scale the picture. The attributes still set the ratio |
| `alt` | Text that stands in for the image. alt="" marks a decorative image | Always. Describe the content or the job. Empty for decoration | A missing alt is different from an empty one |
| `srcset` | A list of image files with their real widths (w) or pixel densities (x) | The image is shown at different sizes or on different screens | A w value must match the file's real width. Do not mix w and x |
| `sizes` | How wide the image will be in the layout. Used with w descriptors. Defaults to 100vw | You use srcset with w values | Describes the layout, not the viewport. MDN also lists an auto keyword |
| `loading` | eager (default) loads now. lazy waits until the image is near the viewport | lazy for images below the first screen | Never lazy for the main image. Only works with JavaScript on |
| `fetchpriority` | A hint of the priority relative to other images: high, low or auto | high for the likely LCP image, one or two per page | If everything is high, nothing is. low for off-screen carousel slides |
| `decoding` | A hint about when to decode: sync, async or auto (the default) | Rarely | MDN says the effect is hard to perceive on static images |
| `<picture>` and `type` | Lets the browser pick the first format it understands | Offering AVIF or WebP with a JPEG fallback | The inner img is required and carries alt |
See responsive images, lazy loading and image width and height.
A complete example
<img src="/img/hero-1200.avif"
srcset="/img/hero-600.avif 600w, /img/hero-1200.avif 1200w"
sizes="100vw"
width="1200" height="675"
alt="The shop front on a sunny morning"
fetchpriority="high">For an image below the first screen, change fetchpriority="high" to loading="lazy".
How Chrome ranked the main image
I loaded ten small test pages in Chrome for Testing 153 and recorded the priority of the image request when it was made, and any change after. These are observations of one browser build, not rules, and other browsers differ.
| How the image was written | Priority when requested | Later |
|---|---|---|
<img>, nothing added | Medium | High, once it was seen to be in the viewport |
<img fetchpriority="high"> | High | |
<img fetchpriority="low"> | Low | |
<img loading="lazy"> | Low | stayed Low |
<img loading="lazy" fetchpriority="high"> | High | |
<img> far below the first screen | Medium | |
<picture> with an img inside | Medium | High |
A CSS background-image | Low | High |
| An image inserted by a script | Low | High |
<link rel="preload" as="image"> with nothing else | Low | High, once the page used it |
Three things stand out. A plain img starts at Medium and rises, so fetchpriority="high" mainly changes where it starts. Background images, script-inserted images and a bare preload all start at Low. And loading="lazy" starts at Low and stays there, which is why it hurts the main image. The 2025 Web Almanac makes the same point about preload, saying that it should be combined with fetchpriority="high" to ensure the image is fetched at high priority. See how to fix slow LCP.
Choose in two questions
| Question | Answer |
|---|---|
| Is this the main image at the top of the page? | Put it in the HTML as an img, add fetchpriority="high", never loading="lazy" |
| Is it below the first screen? | Add loading="lazy", and keep width and height |
Mistakes to avoid
- No
widthandheight, so the page jumps. loading="lazy"on the main image.fetchpriority="high"on many images.- A
wdescriptor that does not match the file. - Missing
alt, or the file name asalt. - The main image as a CSS background, which starts at a low priority and is found late.
Check your own page
Run the free audit and find the Largest Contentful Paint element. Look at its markup against the first table, and in the Network panel add the Priority column to see what Chrome gave it.
Sources
- The img element on MDN:
width,height,srcset,sizes,loading,fetchpriorityanddecoding. - Optimize Largest Contentful Paint on web.dev: discoverability, priority and
fetchpriority="high"for one or two likely LCP images. - Performance chapter, Web Almanac 2025: preload combined with
fetchpriority.
Start here
Free website audit
Live Google data for any public page: mobile and desktop.
Mobile + desktop · Lighthouse lab test · Real-user Chrome data when Google has it
Rather have this done for you? Speed optimization · Book a call