Most people running a website have no idea how much speed is costing them. Not because they do not care, but because the metric never makes its way to a dashboard they look at. The site loads fine on their laptop, the homepage looks good in screenshots, job done.
Then you look at the numbers. Google's own research on mobile sites found that going from a one second load time to three seconds increased the bounce rate by 32 per cent. At six seconds the bounce rate was 106 per cent higher. Most of the sites I look at sit closer to six than one. And most of the time, the reason is the same: oversized images.
What you are actually paying for slow images
Slow images cost you in three places at once, and none of them show up as a line item.
The first is bounce rate. A visitor who waits four seconds for your hero image to render is a visitor who is already opening another tab. Akamai measured this at 53 per cent of mobile users leaving any page that took longer than three seconds. That is not "engagement". That is half your traffic gone before they have seen anything.
The second is conversion. The Aberdeen Group ran the numbers on retail and found a one second delay in page response can cause a seven per cent drop in conversion. If you sell anything, host any kind of form, or care whether people actually finish the thing they came to do, that is direct money on the table.
The third is search. Google has been using Core Web Vitals as a ranking signal since 2021. The metric most affected by oversized images is Largest Contentful Paint, the time taken for the biggest visible element on your page to actually render. That biggest visible element is, in almost every case, an image. If your LCP is above 2.5 seconds, you are losing search visibility you can measure but rarely investigate.
If you monetise with ads on top of all that, slow pages mean fewer impressions per session and lower ad viewability scores, which directly affects what advertisers will pay to be on your pages.
Why images keep winning the blame game
Page weight has been creeping up for years. The HTTP Archive has the average web page sitting around 2.5MB on desktop in early 2026, with roughly half of that being images. So when a page is slow, the question is not really "why is the page slow"; the question is "which of the eleven photos on the homepage is doing most of the damage".
Usually it is one of three things, all easily fixed:
- The file is straight out of a camera or phone, at full resolution. A 4032 pixel wide photo on a layout that displays at 1200 pixels wide is wasted bandwidth on every visit.
- The file is in the wrong format. PNG photos can be ten times larger than the same image in JPG. JPGs are 25 to 35 per cent larger than the equivalent WebP.
- The file was uploaded at the camera's maximum quality setting, which is fine for printing and gross overkill for a screen.
Multiply any one of those by the number of images on your homepage and you are quickly looking at a page weight measured in many megabytes for what should be a couple of hundred kilobytes.
How to find out if you have this problem
Two free tools. Five minutes.
Run PageSpeed Insights on your homepage. It will give you a score, but the more useful bit is the opportunities list. "Properly size images" is the one we are interested in. If it lists three or more files with potential savings of 500KB or more, you have an image problem. Pretty much everyone does.
Open the Chrome DevTools Network tab on your slowest page, refresh, and sort by size. Anything over 200KB on a single image is worth looking at. Anything over 1MB needs fixing today.
The fix is unsexy and very effective
For most sites, the playbook is the same:
- Resize so the longest edge matches the largest size the image will actually be displayed at, with a bit of headroom for high-resolution screens. 1920 pixels works for hero images, 1280 for in-content, 600 for thumbnails.
- Save photos as JPG quality 80, or WebP at the same setting. The visual difference between quality 80 and quality 95 is invisible on screens. The file size difference is enormous.
- Use WebP where you can. Every browser released since 2020 supports it, including Safari. The 25 to 35 per cent file size saving is free quality.
- Add explicit width and height attributes to every image element. The browser uses them to reserve layout space, which prevents the page from jumping around as images load.
If you control the CMS, set up automatic optimisation at the platform level. Most modern hosts and CDNs include it. For WordPress, ShortPixel and Imagify both do the job well. For Shopify and Webflow it is built in. For a one-off marketing site, doing it manually with our free image compressor takes maybe twenty minutes for a typical homepage.
The mistake nobody talks about
Compression is not a one-off. The minute someone uploads a new image at full camera resolution, you are back where you started. This is how sites that were fast at launch quietly turn slow over six months.
Two ways to handle it. Either set up the automatic optimisation properly at upload, or build a habit of running every new image through a compressor before it goes live. Both work. Neither happens by accident.
I have seen plenty of sites where the homepage is well-optimised because someone cared at launch, but the blog has slowly accumulated 5MB hero images because the editor was never told the workflow. The performance hit is exactly the same either way.
It is not about the perfect score
Nobody is going to give you a medal for a 100/100 PageSpeed score. But moving from a 40 to a 75 is the difference between visitors who immediately leave and visitors who actually see your content. That gap is measured in real revenue. The work to close it is mostly resizing photos.
If you only do one thing this week, run our compressor over your homepage hero. That single file is doing more damage to your conversion rate than any other change you could make.