One unoptimized hero image can add 2+ seconds to your load time and cost you ranking positions. Here's the exact process we use to cut image weight by 95% without losing quality.
One of our own case study images was 2.06 MB. It looked fine on a fast laptop connection. On a mobile device, or anywhere with a variable connection, it was adding two to three seconds to the page load. We fixed it in an afternoon and the page went from failing Core Web Vitals to passing them. This is what we did, and why it matters for your rankings.
Google's Core Web Vitals are three specific measurements it uses to score the experience of loading your page. They directly influence where you rank. A slow page with great content will consistently rank below a fast page with decent content. The three metrics are:
LCP measures how long it takes for the largest visible element on the page to load, usually a hero image or a large heading. Google wants this under 2.5 seconds. A 2MB hero image on a mobile connection will blow that budget immediately.
CLS measures how much the page jumps around while it's loading. When a large, unoptimised image takes time to load, the browser doesn't know its dimensions upfront. It reserves no space. When the image finally arrives, everything below it shifts down: text, buttons, navigation. Google scores this as a bad experience and so do your users, who just tried to click something that moved.
INP measures how quickly the page responds to user input. Heavy images don't just slow the visual load. They also block the browser's main thread and make the entire page feel sluggish to interact with.
Google wants LCP under 2.5s, CLS under 0.1, and INP under 200ms. Miss any of these consistently and you're handing ranking positions to competitors whose sites load faster.
The image we were carrying on our case studies page was 2,068 KB, which is over two megabytes for a single JPEG. Here's what that means in practice:
One image. Four problems. This is not unusual. It's the default state of most websites that haven't been audited for performance.
Most images are uploaded at the size they came off a camera or out of a design tool, often 4000×3000 pixels or larger. But your website might display that image at 800×500. The browser downloads all 4000×3000 pixels and then scales it down. You're paying the bandwidth cost for resolution no one ever sees.
Check the actual rendered dimensions using browser DevTools (right-click → Inspect, then hover over the image element. It shows intrinsic vs rendered size). Resize the image to match the rendered size, or slightly larger for retina displays (2x rendered width maximum).
JPEG and PNG are legacy formats. WebP typically reduces file size by 25–35% compared to JPEG at equivalent visual quality. AVIF goes further, cutting 40–50% compared to JPEG, but browser support, while wide, is slightly less universal.
The same case study image at 2,068 KB as a JPEG came down to 94 KB as a WebP, a 95% reduction with no visible quality difference. That is not a typo. This is the normal result when you start from an oversized, unoptimised JPEG.
Tools for conversion: Squoosh (free, browser-based, excellent), ImageOptim (Mac), Sharp (Node.js, for build pipelines).
Adding explicit width and height attributes to every <img> tag tells the browser exactly how much space to reserve before the image loads. This eliminates layout shift (CLS) entirely for that element. It's a two-second code change per image.
<!-- Before: causes layout shift -->
<img src="hero.webp" alt="Hero" />
<!-- After: browser reserves space, no shift -->
<img src="hero.webp" alt="Hero" width="1200" height="630" />Images the user hasn't scrolled to yet should not be downloaded on page load. Adding loading="lazy" to any image that isn't in the initial viewport defers its download until the user is about to see it. This reduces initial page weight and improves LCP because the browser can focus bandwidth on what's actually visible.
<!-- Hero image: load eagerly, it's above the fold -->
<img src="hero.webp" alt="Hero" width="1200" height="630" loading="eager" />
<!-- Content images: defer until needed -->
<img src="team.webp" alt="Team" width="800" height="500" loading="lazy" />Here's exactly what the audit and fix looked like on our own site:
| Image | Before | After | Saving |
|---|---|---|---|
| Excel Kids case study | 2,068 KB JPEG | 94 KB WebP | −95% |
| Tusome Coffee case study | ~400 KB JPEG | 94 KB WebP | −76% |
| Logo asset | 179 KB PNG | 179 KB PNG | Already small |
The case studies page went from carrying over 2.5MB in images to under 400KB. Page weight dropped by more than 80% from images alone. LCP on mobile went from failing to passing. CLS went to zero once width/height attributes were added.
Run your homepage through PageSpeed Insights on mobile. Look for:
Any of these showing up in the red or orange band means your images are actively costing you ranking positions on mobile searches, which is where the majority of your potential clients are searching from.
Google has been using Core Web Vitals as a ranking factor since 2021. It's already here, already affecting your position, and your competitors who've done this work are sitting above you because of it. The fix is not complex. It's mostly a one-time audit and a few hours of asset work.
Don't have the time to audit your site's speed? Our web design studio builds lightweight, high-performance web products with technical SEO baked in by default. Image pipelines, Core Web Vitals scores, all of it is built into the delivery spec, not bolted on afterwards. Let's talk about your site →
// ready to grow?
Book a 30-minute call. Tell us which service you need: design, dev, automation, SEO, content or brand. We'll come back with scope, timeline and price. One service or several, your call.