aiwebpageseo / SEO Tools / Image Optimisation Auditor / Image Optimisation Guide

Image SEO: Formats, Alt Text, Compression and Loading

Images are the most common cause of slow pages and one of the most overlooked SEO opportunities. Properly optimised images improve your Core Web Vitals, rank in Google Images, and make your pages load faster for every user.

🖼 Audit Images All Audit Tools →

How images affect your SEO

Images affect SEO in three ways: page speed, Google Images rankings, and content relevance signals. Large unoptimised images are the single most common cause of poor LCP scores. Missing alt text means your images are invisible to Google Images. Keyword-relevant alt text reinforces your page's topical focus.

IssueSEO impactFix
Large file sizeSlow LCP, poor Core Web VitalsConvert to WebP, compress
Missing alt textNot indexed in Google ImagesAdd descriptive alt attribute
No width/heightLayout shift increases CLSAdd explicit dimensions
No lazy loadingUnnecessary bandwidth on loadAdd loading="lazy"
Wrong format (BMP, TIFF)Unnecessarily large filesConvert to WebP or JPEG

How to optimise images step by step

  1. Run the Image Optimisation Auditor on your key pages
  2. Fix missing alt text — add descriptive alt to every image that conveys information
  3. Add width and height attributes to every img tag to prevent CLS
  4. Convert JPEG and PNG files to WebP using Squoosh.app or your build pipeline
  5. Add loading="lazy" to all images below the fold
  6. Add fetchpriority="high" to your main hero image to prioritise LCP
  7. Re-run the Page Speed Analyzer to confirm LCP improvement
Biggest impact: Converting your hero image to WebP and adding the correct dimensions typically improves LCP by 30-50% on image-heavy pages. Do this first before any other optimisation.

Why images dominate page weight

On a typical page, images account for the majority of bytes transferred — usually more than the HTML, CSS, JavaScript and fonts combined. They are also the easiest thing to fix, because unlike JavaScript, an over-sized image imposes no functional cost when you shrink it. Nothing breaks.

The reason it goes unfixed is that the cost is invisible to the person who created it. A designer exports a 3,000-pixel hero at full quality on a fast machine and a fast connection, and it looks perfect and loads instantly. The user on a mid-range phone on 4G downloads two megabytes to display an image 390 pixels wide, and waits.

This is not a marginal saving. On most sites, image work alone moves LCP more than every other optimisation combined — and LCP is the Core Web Vital most likely to be failing.

Formats: what to use and when

AVIF

The best compression available in wide browser support. Typically 30–50% smaller than WebP at equivalent quality, and dramatically smaller than JPEG. It encodes slowly, which matters for a build pipeline but not for a served asset. Use it as the first choice, with a fallback.

WebP

Smaller than JPEG and PNG, supported essentially everywhere, and faster to encode than AVIF. The safe default and the correct fallback for AVIF.

JPEG

The final fallback. Still perfectly serviceable for photographs, and a well-compressed JPEG at quality 75–80 is frequently indistinguishable from the original at a fraction of the size. The mistake is exporting at 100, which produces a much larger file and no visible improvement.

PNG

Correct for images requiring genuine transparency or sharp-edged graphics with few colours. Ruinous for photographs — a PNG photograph is routinely five to ten times the size of the equivalent JPEG, and this is one of the most common single causes of a slow page.

SVG

For logos, icons and anything vector. Infinitely scalable, tiny, and it renders sharply on every display. An icon exported as a 200KB PNG that should have been a 2KB SVG is a straightforward error.

The practical stack: serve AVIF, fall back to WebP, fall back to JPEG, using a <picture> element. The browser picks the best format it supports and you pay nothing for the ones it does not.

Responsive images: serving the right size

Format is only half the problem. The other half is dimension, and it is the half more commonly ignored.

An image displayed at 400 pixels wide on a phone does not need to be 2,400 pixels wide. Serving the desktop asset to every device means a phone downloads roughly six times the data it can use, then spends CPU time scaling it down — a cost paid twice, in bandwidth and in decode.

The srcset attribute lets you offer several sizes and have the browser choose. The sizes attribute tells it how large the image will actually be displayed, which it needs in order to choose correctly — and omitting sizes is why srcset so often fails to help. Without it the browser assumes the image fills the viewport and picks the largest file.

Account for device pixel ratio. A retina phone displaying a 400-pixel image wants roughly 800 physical pixels. Serving exactly 400 produces a visibly soft image; serving 2,400 wastes most of it. The right answer is around double the display size, no more.

Lazy loading — and the one image you must never lazy-load

loading="lazy" defers images until they approach the viewport. On a long page with twenty images, this is a large and free saving: the browser fetches the two the user can see and leaves the rest.

There is exactly one image it must never be applied to: the LCP element. The largest visible element in the initial viewport — usually the hero image — is what LCP measures. Lazy-loading it tells the browser to delay the very thing the metric is timing, and it directly and severely worsens the score.

This mistake is extremely common, because lazy loading is applied globally by a plugin or a template with no exception for the hero. It is a one-line fix and it frequently takes a full second off LCP on its own.

The opposite treatment for the LCP image

Dimensions, and the layout shift you are causing

An <img> with no width and height attributes occupies zero space until it loads, then abruptly occupies several hundred pixels and pushes everything beneath it down the page. That is cumulative layout shift, and images without dimensions are its single largest cause.

Set both attributes on every image. The browser uses them to compute the aspect ratio and reserve the correct space before the file arrives — the layout is built once and nothing moves. CSS can still control the displayed size; the attributes are not a styling instruction, they are information the browser needs early.

This is the cheapest fix in the whole of web performance: two attributes, no visual change, and it frequently takes a failing CLS score to passing on its own.

Alt text: written for people, useful to machines

Alt text exists so that someone who cannot see the image can still understand the page. That is its purpose, it is a legal requirement in many jurisdictions, and everything useful it does for SEO follows from doing it properly for that purpose.

What good alt text does

It describes the image in the context of the page. Not exhaustively — usefully. "Bar chart showing organic traffic falling 40% after the June migration" tells a screen reader user exactly what a sighted reader takes from it. "Chart" does not. "SEO chart graph analytics traffic seo audit" is keyword stuffing, it is useless to the person it exists for, and it is treated as spam.

Decorative images take empty alt

alt="" — explicitly empty, not omitted — tells a screen reader to skip the image entirely. This is correct and desirable for a divider, a background flourish or an icon that merely repeats adjacent text. Omitting the attribute is different: the screen reader then announces the filename, which is worse than saying nothing.

Do not begin with "image of"

The screen reader has already announced that it is an image. Starting the description with "image of" is redundant, and it happens on a great many sites.

Ranking in Google Images

Image search is a substantial traffic source that most sites ignore entirely, and the signals it uses are largely ones you are already meant to be getting right.

The most common failure is that images are decorative. Stock photographs of people shaking hands rank for nothing, because nobody searches for them. Original images of the actual thing — the product, the work, the result — are the ones that earn image traffic, and they are also the ones that demonstrate first-hand experience.

Frequently asked questions

Which image format should I use?

AVIF first, WebP as fallback, JPEG as final fallback, served through a <picture> element. Use PNG only for genuine transparency or sharp-edged graphics — a PNG photograph is routinely five to ten times larger than the equivalent JPEG and is a common cause of slow pages. Use SVG for logos and icons.

Should I lazy-load all my images?

All except one. Never lazy-load the LCP element — the largest image in the initial viewport. Doing so delays the exact thing the metric is timing and severely worsens the score. It should be eager, with fetchpriority="high".

Do I really need width and height attributes?

Yes. Without them the browser cannot reserve space, so the page reflows when the image arrives. Images without dimensions are the single largest cause of cumulative layout shift, and adding two attributes fixes it with no visual change.

Does alt text help SEO?

It helps image search and it helps Google understand the page. But it exists for accessibility, it is a legal requirement in many jurisdictions, and stuffing it with keywords makes it useless to the people it is for and is treated as spam. Write it for a person who cannot see the image.

What alt text should a decorative image have?

An explicitly empty one: alt="". That tells a screen reader to skip it. Omitting the attribute entirely is worse — the reader will announce the filename instead.

🖼 Audit Images Now

Run the Image Optimisation Auditor and get actionable results in minutes. Pay as you go — no subscription needed.

Audit Images →

Related tools

About aiwebpageseo

aiwebpageseo.com is a data-driven SEO and AEO (Answer Engine Optimisation) platform providing a free suite of technical website tools. Rather than relying on AI-theorised assumptions, the platform analyses live URL performance, delivering objective diagnostics, page speed metrics, CLS debugging, and site crawl data alongside actionable technical tutorials.