Open your favourite “why is my site slow” report and, nine times out of ten, the top offender is images. They are easy to add and easy to forget about — a single un-optimised phone photo can weigh more than all your HTML, CSS and JavaScript combined. The good news: it is also the easiest thing to fix, and the payoff shows up in both speed and search.
Why images dominate page weight
A modern phone shoots 12–50 megapixel photos at 4–12 MB each. Drop three of those onto a page and you have a 20 MB page before a single word of text loads. Even “web-sized” JPEGs at full quality are often 1–3 MB. Multiply by every image and every visitor — especially on mobile data — and the cost is enormous.
Core Web Vitals, in plain English
Google's Core Web Vitals are three real-user measurements of page experience. Images touch all three, but dominate the first:
| Metric | Measures | “Good” | Image impact |
|---|---|---|---|
| LCP | Time to render the largest element | ≤ 2.5s | Huge — the LCP element is usually an image |
| CLS | Visual stability (layout shift) | ≤ 0.1 | Images without width/height cause shifts |
| INP | Responsiveness to input | ≤ 200ms | Indirect — heavy pages block the main thread |
LCP is the one to obsess over. If your largest element is a hero image (it usually is), its byte size and how early the browser fetches it decide whether you pass or fail.
Does this actually affect rankings?
Yes — Google uses page experience, including Core Web Vitals, as a ranking signal. It is a tie-breaker rather than a magic wand: great content still wins, but between two comparable pages the faster one has the edge. And there is a more direct effect that matters even more than rankings: speed drives conversions. Study after study shows bounce rate climbing sharply for every extra second of load time. Compressing images improves the metric Google watches and the revenue you care about.
The fix, in priority order
- Compress and convert to WebP/AVIF. The fastest single win. See which format to use.
- Serve images at the right dimensions. Don't ship a 4000px image into an 800px slot. Read resize vs compress.
- Set explicit
widthandheight(or an aspect-ratio box) so images don't shift the layout — that protects your CLS. - Lazy-load below-the-fold images with
loading="lazy", but never lazy-load your LCP hero — it should load eagerly, even with high priority. - Use responsive images (
srcset) so phones download small versions and desktops download large ones.
A quick target to aim for
Keep in-content images under ~150 KB and heroes under ~250 KB. Those are comfortably achievable with a modern format at quality 80 and correct dimensions — with no visible quality loss. Batch-run your existing library through the compressor and you'll typically strip more than half your total page weight in a single pass.
Frequently asked questions
Does image compression help SEO? +
Indirectly but meaningfully. Google uses page experience signals — including Core Web Vitals — as a ranking factor. Images are the most common cause of a poor Largest Contentful Paint (LCP) score, so compressing and correctly sizing them is one of the highest-leverage speed fixes, which supports rankings and, more importantly, conversions.
What is a good LCP score? +
Google considers LCP "good" at 2.5 seconds or less (at the 75th percentile of real visits). Since the LCP element is very often a hero image, its file size and load priority directly determine whether you pass.
How much faster will my site be after compressing images? +
It depends on how heavy your images are now, but on image-heavy pages that have never been optimised, cutting image weight by 60–80% commonly shaves one to several seconds off load time — the single biggest win available without touching code.
What image size should I aim for on the web? +
As a guideline, keep most in-content images under ~150 KB and hero images under ~200–300 KB. Combine a modern format (WebP/AVIF), correct dimensions, and quality around 80 to hit those numbers with no visible loss.