Image Optimisation Example: Alt Text, WebP and Dimensions
This example shows the aiwebpageseo Image Optimisation Checker for an e-commerce category page with 34 images. The report finds 8 missing alt texts, 12 JPEG/PNG images that could be WebP, 6 images without width/height causing CLS and estimates 340KB of potential savings.
| # | Image URL | Dimensions | Issue |
|---|---|---|---|
| 1 | /products/trainer-blue-800.jpg | 800×600 | ❌ No alt text |
| 2 | /products/trainer-red-800.jpg | 800×600 | ❌ No alt text |
| 3 | /banners/sale-banner.png | 1200×300 | ❌ No alt text |
| 4-8 | 5 more product images... | — | ❌ No alt text |
12 images served as JPEG/PNG — convert to WebP
Estimated saving: ~280KB (avg 23KB per image). All modern browsers support WebP. Use an image CDN or build step to serve WebP with JPEG fallback using <picture> element.
6 images missing width and height attributes
Browsers cannot reserve layout space for images without explicit dimensions, causing Cumulative Layout Shift when they load. Add width and height matching the actual display size to all img elements.
Hero image not preloaded (LCP element — 124KB)
The largest image on the page (124KB JPEG, 1200×800) is the LCP element but is not preloaded. Add <link rel="preload" as="image" href="/hero.jpg"> to reduce LCP by approximately 0.8–1.2 seconds.
A report listing 34 images with three categories of defect invites you to work through it evenly. Do not. On almost every page, one image dominates the metrics and the rest are rounding errors — and the report above already tells you which one it is: the 124KB hero that is the largest contentful paint element.
Largest Contentful Paint measures when the biggest visible thing in the viewport finishes rendering. On a category page with a hero, that is the hero, and every millisecond it takes to arrive is a millisecond of LCP. Converting twelve below-the-fold thumbnails to WebP saves 280KB of bandwidth, which is worth having and which will move LCP by approximately nothing, because those images were never on the critical path.
So the order is: fix the hero, fix the layout shift, then do the bulk conversion as housekeeping. The report is sorted by count. Sort it by consequence instead.
It is common to see alt text justified as an SEO signal. That framing is both weak and misleading, and it produces bad alt text — keyword-stuffed strings written for a crawler that a blind user then has to listen to.
Alt text exists so that someone who cannot see the image can still use the page. A screen reader announces it in place of the image; when it is missing, the reader typically announces the filename instead, which is how a customer ends up hearing "IMG underscore 4471 dot jpeg". That is a WCAG failure with a compliance dimension, and it is a real person being shut out of your shop. Search engines do use alt text to understand images, which matters for image search — but that is a secondary benefit, not the reason.
Informative images get a description of what they show
"Navy waterproof jacket, front view, hood up" tells a listener what a shopper can see. It is not a keyword slot and it does not need your brand name in it.
Purely decorative images get alt=""
An empty alt is not an omission — it is an instruction to skip. A background flourish announced as "decorative-swoosh-3.png" is worse than silence.
Images that act as links or buttons describe the action
The alt on a magnifying-glass icon that opens search should be "Search", not "magnifying glass". Describe what it does, not what it depicts.
Six images without width and height attributes is a layout-shift problem waiting for a slow connection. The mechanism is simple: with no dimensions, the browser cannot reserve space, so it lays out the page as though the image were not there and then reflows everything when it arrives. The reader experiences that as the paragraph they were reading jumping down the screen, or the button they were about to tap moving out from under their thumb.
Cumulative Layout Shift is the metric that measures this, and it is the one Core Web Vital that is genuinely about respect for the reader rather than raw speed. Supplying width and height — or an aspect-ratio in CSS — lets the browser reserve the correct box before the bytes arrive. The attributes do not need to match the display size; they establish the ratio, and CSS scales from there.
This is an hour of work with an immediate, visible improvement for every visitor on a phone, and it is the item on this report with the best ratio of effort to benefit.
These two techniques do opposite things and applying either to the wrong image undoes the benefit of both.
Preload tells the browser that a resource matters more than whatever the parser would otherwise fetch first. It is worth spending on exactly one image: the LCP element. Preloading a dozen images restores the original bandwidth contention and adds overhead, which is why "preload everything" performs the same as preloading nothing, only with more markup.
Lazy loading defers off-screen images until the reader approaches them, which removes them from the initial load entirely. Applied below the fold it is free performance. Applied to the hero it is an own goal of the purest kind: you have instructed the browser to delay the exact element that LCP is timing, and the metric gets worse.
The rule is one line long. Above the fold: eager, sized, and preloaded if it is the LCP element. Below the fold: lazy. Anything else is guessing.
WebP is smaller than JPEG at comparable quality and is supported by every current browser, so the conversion is worth doing. It is also the least interesting part of image optimisation, because the biggest wins on most sites are not about codecs at all.
The most common defect in e-commerce imagery is a picture that is enormously larger than the box it is displayed in — a 2400-pixel product photograph rendered into a 400-pixel thumbnail, shrunk by the browser after every one of those bytes has crossed the network. No format change fixes that. Serving appropriately sized variants, via srcset and sizes so that a phone gets a phone-sized image, routinely beats a codec swap by an order of magnitude.
Do both, in the right order: right-size first, re-encode second, and measure the LCP element before and after so you know which of the two actually paid.
Right-size and preload the hero
It is the LCP element and the single largest lever on this page. Serve it at the dimensions it is actually displayed at, re-encode it, preload it, and make sure nothing has lazy-loaded it by accident. Measure LCP before and after so you know what the change bought.
Add width and height to the six images missing them
An hour of work that removes the layout shift a reader feels most acutely on a phone. Cheapest fix on the report.
Write the eight missing alt attributes
Accessibility first, image search second. Describe what a shopper would see; use an empty alt for anything decorative.
Serve responsive variants with srcset
Stop sending desktop-sized product photographs to phones. This usually saves more bytes than the format conversion does.
Convert the remaining twelve to WebP
Housekeeping. Genuine bandwidth saving, negligible effect on the metrics, and the easiest item to automate in a build step or at the CDN.
A final note on measurement, because it decides whether any of this was worth it. The score in a lab tool is a simulation on a synthetic device. What Google uses for ranking is field data — what real Chrome users on real networks actually experienced. The two diverge routinely, and a page can post an excellent lab score while your customers on mobile networks suffer. When you check whether these changes worked, check the field data.
Why should I use WebP images?
WebP images are typically 25–35% smaller than equivalent JPEG or PNG files at the same visual quality. Smaller images mean faster page loads, lower LCP scores and less bandwidth usage. All modern browsers support WebP. The Image Optimisation Checker identifies every image not yet served in WebP format.
What is lazy loading?
Lazy loading defers loading of off-screen images until the user scrolls near them. It reduces initial page weight and speeds up First Contentful Paint. Add loading='lazy' to all images below the fold. Never add lazy loading to above-the-fold images as this delays LCP.
How does missing alt text affect SEO?
Alt text exists first for people who cannot see the image: it is what a screen reader announces, and omitting it on an informative image is an accessibility failure under WCAG before it is anything else. Search engines do also use it to understand what an image depicts, which matters mainly for image search — but the effect on a page's ranking for ordinary text queries is marginal, and alt text is not a place to repeat keywords. Describe the image accurately for someone who cannot see it. If an image is purely decorative, give it an empty alt attribute so screen readers skip it rather than announcing a filename.
Will converting to WebP actually improve my Core Web Vitals?
It will reduce bytes, and whether that improves your score depends on where the bytes were. If the largest contentful paint element is an image, shrinking it directly improves LCP, which is the metric most sites fail. If the 280KB saving is spread across twelve product thumbnails below the fold, the effect on LCP is close to zero — you have saved bandwidth, which is worth having, but you have not moved the metric. Check which element is actually your LCP before optimising anything, because the single hero image usually matters more than every other image on the page combined.
Does adding width and height really fix layout shift?
It fixes the cause of it, yes. Without explicit dimensions the browser does not know how much vertical space to reserve, so it lays out the page without the image and then reflows everything when the image arrives — which is what a reader experiences as the paragraph jumping away as they start reading it. Supplying width and height, or an aspect-ratio in CSS, lets the browser reserve the box in advance. It is one of the cheapest and most reliable Core Web Vitals fixes available, and unlike most performance work it makes the page immediately better for a human on a slow connection.
Should I preload every image?
No — preloading everything is the same as preloading nothing, because you have simply restored the original competition for bandwidth while adding overhead. Preload is a way of telling the browser that one specific resource is more important than what the parser would otherwise discover first, and it earns its keep on exactly one image: the LCP element. Preload the hero, leave everything else to normal discovery, and lazy-load what is below the fold. Lazy-loading the hero, incidentally, is the classic own goal — it delays the very element the metric is timing.
Do images affect rankings directly?
Barely, and it is worth being clear about the mechanism rather than implying one. Core Web Vitals are a genuine ranking consideration and a small one — Google has consistently described them as a tie-breaker between pages of comparable relevance rather than something that lifts a weaker page above a stronger one. Images affect rankings only through that channel, plus image search itself, where alt text and file context do matter. The larger and more certain returns from image work are elsewhere: people abandon slow pages, and a page that shifts under a reader's thumb loses them. Optimise images for those reasons and let the ranking effect be a bonus.
Related Demo Reports
Run Image Optimisation Checker on Your Own Site
Get your real audit report with specific issues, fixes and actionable improvements — free to start.