On a typical web page, images make up the largest share of the bytes the browser has to download — often more than the HTML, CSS, and JavaScript combined. That makes them the number-one lever for page speed, and page speed feeds directly into Google's Core Web Vitals, which influence both user experience and rankings. The good news: image optimisation is a solved problem with a clear order of operations. Work through it and a slow, image-heavy page becomes fast.
Why images decide your Core Web Vitals
Two of Google's headline metrics are dominated by images:
- LCP (Largest Contentful Paint) measures how long until the biggest element appears — on most pages, that is the hero image. A heavy, un-optimised hero is the most common reason a page fails LCP.
- CLS (Cumulative Layout Shift) measures unexpected movement. Images that load without stated dimensions let the page reflow as they arrive, shoving content around and tanking CLS.
Fix your images and you usually fix both. Here is the playbook, in the order that gives the biggest wins first.
1. Resize to the size actually displayed
The most wasted bytes on the web are images served far larger than they appear. A 4000-px phone photo shown in an 800-px column is downloading ~5× more data than the user will ever see. Resize every image to (at most) the largest size it is displayed at before anything else — this alone often halves page weight. (See resizing without losing quality and the resize tool.)
2. Compress with the right format
Then compress. Choosing the format is half the battle (full detail in the format guide):
- Serve photos as WebP (or AVIF with a fallback) — typically 25–50% smaller than JPG at the same quality.
- Keep logos, icons, and screenshots as PNG/SVG (lossy would smear them).
- Target quality ~80 for photos — no visible loss, big savings.
Our Compress tool and WebP converter do this in the browser; there is a focused walkthrough on optimising images for website speed.
3. Serve responsive images (srcset)
One size does not fit all devices. A phone should not download a desktop-sized hero. Use responsive images so the browser picks the right one:
<img
src="photo-800.webp"
srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1600.webp 1600w"
sizes="(max-width: 600px) 100vw, 800px"
width="800" height="500" alt="…">
The browser downloads only the size it needs for the current screen — a large saving on mobile.
4. Always set width and height
Every <img> should declare its width and height (or an aspect-ratio in CSS). This lets the browser reserve the space before the image arrives, so nothing jumps as it loads — which is exactly what CLS rewards. It is a one-line fix with an outsized effect.
5. Lazy-load below the fold — but not the hero
Add loading="lazy" to images below the fold so they only download as the user scrolls near them, freeing bandwidth for what is visible. Crucially, do the opposite for your LCP/hero image: never lazy-load it (that delays the very thing LCP measures). For the hero, prefer loading="eager" and consider a <link rel="preload"> so it starts downloading immediately.
6. Do not forget alt text
alt text is not a speed lever, but it is part of image optimisation and it is free SEO + accessibility. Describe what the image shows (not "image123.jpg"); screen readers announce it, and Google uses it to understand and rank the image in Google Images. Decorative images get an empty alt="" so screen readers skip them.
7. Name files descriptively
red-leather-office-chair.webp tells Google (and you) far more than IMG_4823.webp. Descriptive, hyphenated filenames are a small, legitimate image-SEO signal — worth doing as you export.
A quick pre-publish checklist
Before an image goes live, ask:
- Resized to (at most) its display size?
- Compressed in a modern format (WebP/AVIF for photos) at ~80 quality?
- width/height set so it does not shift the layout?
- Lazy-loaded if below the fold (and not if it is the hero)?
- Descriptive filename + alt text?
Tick those five and your images will be fast, stable, and search-friendly.
Serve next-gen formats with a fallback
You can use AVIF and WebP and still support the rare browser that cannot read them, using the <picture> element. The browser walks the list top to bottom and uses the first format it understands:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" width="1600" height="900" alt="…">
</picture>
Modern browsers get the tiny AVIF; slightly older ones get WebP; anything else falls back to the universal JPG. You ship the smallest format each visitor can actually display, with zero risk of a broken image — the best of both worlds.
Measure it — do not guess
Optimisation without measurement is guesswork. Two free tools tell you exactly where you stand:
- Chrome DevTools → Lighthouse runs a local audit and reports your LCP, CLS, and a list of "properly size images" / "serve images in next-gen formats" / "efficiently encode images" opportunities, each with the estimated saving in KB.
- PageSpeed Insights (Google) runs the same audit on Google's servers and adds field data — how real visitors experienced your page.
Run one before and after optimising the same page and you will see the LCP number drop as the hero image shrinks. If a specific image is flagged, that is your next task; work down the list until the opportunities are gone.
A realistic performance budget
Targets keep you honest. Sensible rules of thumb for 2026:
- Total page weight: aim under ~1 MB for a content page; under ~2 MB for an image-heavy one.
- Hero/LCP image: ideally under ~150 KB after compression, and it must not be lazy-loaded.
- Individual content images: typically 30–150 KB each once resized and compressed.
- LCP: under 2.5 seconds; CLS: under 0.1. These are Google's "good" thresholds.
If a single image blows the budget, revisit the order of operations above — nine times out of ten it is either oversized dimensions or an un-converted JPEG/PNG that should be WebP.
The privacy angle still applies
You can do every step above without uploading a thing — resizing, compressing, and converting all run in your browser here, so optimising a client's private product shots never puts them on someone else's server. (More in how in-browser tools work.)
Key takeaways
- Images are the heaviest part of most pages and the main driver of LCP and CLS.
- Optimise in order: resize to display size → compress in a modern format → serve responsive srcset.
- Set width/height on every image (kills layout shift) and lazy-load below the fold (never the hero).
- Add descriptive filenames and alt text for accessibility and image SEO.
- All of it can be done locally in the browser — no uploads required.