Web image optimisation: how to cut kilobytes and improve your site's SEO

Why images decide your Core Web Vitals

Three metrics make up the Core Web Vitals, and images are implicated in all three. Largest Contentful Paint measures how long it takes for the biggest visible element to render — on an article that is the hero image, on a product page the main photograph. Cumulative Layout Shift measures unexpected movement, and the classic cause is an image without declared dimensions pushing the text down when it finally loads. Interaction to Next Paint measures responsiveness, and while it is mostly a JavaScript story, decoding a stack of oversized images competes for exactly the same main thread.

What Google actually rewards

It is worth being precise, because this area attracts a lot of overstatement. Page experience is not a strong ranking factor and a fast page will not outrank a more relevant one. What speed does is act as a differentiator between results of comparable relevance, and — far more consequentially — determine how many of the people who click actually stay. A three-second delay before the main image appears produces measurable abandonment, and abandonment is a signal that needs no algorithmic subtlety to hurt you.

Field data, not your laptop

The Core Web Vitals used in Search come from the Chrome User Experience Report: real measurements from real Chrome users. Lighthouse, running in a controlled lab on your machine, is a diagnostic tool, not the score that counts. A site can score 98 in Lighthouse and still fail its field vitals because actual visitors are on mid-range Android phones on congested mobile networks. Optimise for that visitor and the lab score follows automatically.

The four levers, in order of payoff

Almost all image weight comes from four decisions. They are listed here in the order that returns the most kilobytes per minute of effort — which is not the order most guides use.

1. Stop shipping pixels nobody sees

This is the big one, and it is almost always present. A photograph straight from a phone is 4000 × 3000 pixels. Displayed in an 800-pixel-wide content column, even accounting for a 2× retina display, it needs 1600 pixels of width. The other 2400 are downloaded, decoded and thrown away — around 84% of the pixel data wasted before a single byte of compression is considered. No format or quality setting recovers from that; resizing does, and it is the single most effective change available.

2. Use a modern format

WebP typically produces files 25–35% smaller than a JPEG of equivalent visual quality, and is supported by every browser in current use. AVIF goes further — often 40–50% smaller than JPEG — with support now broad but not universal, which makes it a progressive enhancement rather than a wholesale replacement. Neither requires you to abandon JPEG: served through a picture element, modern browsers take the smaller file and older ones fall back.

3. Tune quality per image, not per site

Quality settings are not linear in perceived value. For most photographs, JPEG quality 75–82 or WebP 75–80 is visually indistinguishable from the original at normal viewing size, while quality 95 costs two to three times the bytes for a difference nobody can see. The exceptions are images with large flat areas, hard edges or text, which show artefacts far earlier — screenshots, logos and diagrams need either a higher quality setting or a lossless format.

4. Load them in the right order

The remaining wins are about scheduling rather than size. The hero image should be discovered and fetched immediately; everything below the fold should wait. Getting this backwards — lazy-loading the LCP image is a genuinely common mistake — can cost a second of LCP on a page whose images are otherwise perfectly optimised.

Formats: the short version

• AVIF — smallest files for photographic content, excellent at low bitrates, slower to encode. Use as the first source in a picture element.
• WebP — the sensible default in 2026. Universally supported, meaningfully smaller than JPEG, and it also handles transparency and animation.
• JPEG — the fallback that always works. Fine for photographs; never use it for screenshots, logos or anything with text.
• PNG — lossless, for flat colour, sharp edges and transparency. Correct for logos and UI screenshots, wasteful for photographs.
• SVG — vector, so it is resolution-independent and usually tiny. The right answer for logos, icons and simple diagrams; strip editor metadata before shipping, as it often doubles the file.

The markup that finishes the job

Optimised files still need to be requested well. Five attributes do most of the work, and none of them require a build step.

• Always set width and height. The browser reserves the correct space before the image arrives, which eliminates the layout shift. Aspect-ratio CSS keeps it responsive; the attributes are still required.
• loading="lazy" on everything below the fold. Native, one attribute, no library. It defers requests for images the visitor may never scroll to.
• Never lazy-load the LCP image. Give the hero fetchpriority="high" instead, and make sure it is in the initial HTML rather than injected by script.
• Use srcset and sizes for responsive images. A phone should not download the desktop-sized file. Three or four widths cover almost every layout.
• Write real alt text. It is an accessibility requirement first and an SEO signal second — describe what the image conveys, not a keyword list. Decorative images take an empty alt attribute so screen readers skip them.

Filenames and context still count

For image search, the filename, the alt text, the caption and the surrounding paragraph are what identify the image. “oak-dining-table-140cm.webp” tells a crawler something; “IMG_20260714_113255.webp” tells it nothing. This costs no bytes and takes no time, and it is the part of image SEO most often skipped entirely.

Budgets worth adopting

• Hero / LCP image: under 200 KB. This is the one that decides your LCP. Treat the number as a hard limit.
• In-article images: under 100 KB each. At 1200–1600 pixels wide in WebP, that is comfortably achievable for most photographs.
• Thumbnails and avatars: under 30 KB. If a 150-pixel thumbnail weighs 400 KB, it is a full-size image being scaled by the browser.
• All images on a page: under 1 MB total. Above this, mobile visitors on a slow connection start abandoning before the page is usable.

Measuring the change

1. 1 Record the current state: PageSpeed Insights for the URL, noting both the lab score and the field data if the page has enough traffic to have any.
2. 2 Open DevTools, filter the Network panel to images, and sort by size. The three largest files are your work list.
3. 3 Fix those three: resize to the displayed dimensions, convert to WebP, compress, and check the rendered result at full size.
4. 4 Re-measure in the lab immediately, then wait 28 days for the field data to reflect the change — CrUX reports a rolling 28-day window, so nothing moves overnight.
5. 5 Add the budgets above to your publishing checklist, so the improvement does not decay with the next batch of uploads.

Why a browser-based workflow suits this

Image optimisation is repetitive, batch-oriented work that does not need a server: resizing and re-encoding are exactly what the Canvas API and Web Workers are for. Doing it locally means no upload wait on a folder of fifty photographs, no queue, no size cap, and no copies of unreleased product imagery sitting in a third party's temporary storage. It also means you can run the whole process on a train with no connection, which is more often useful than it sounds.