Most slow pages are not mysterious. They are carrying one or two assets that should never have been published at full camera or design-export size - a hero photo still at 13 MB, a PNG logo that should have been a few kilobytes, a product shot saved straight from a phone.
Those files are easy to miss because they still look fine in the browser. The browser simply downloads every byte. Visitors wait. Google notices the wait. Conversions fall off before the page has even finished painting.
This post walks through what oversized images actually cost, using a real anonymised scan example, and shows how to check whether the same problem is sitting on a page of your own site.
Scan a page of your site to check if you have this too
If you want the practical path first: run a free AuditCrow scan on any page. Oversized and uncompressed images are treated as a leading speed issue when they show up - they sit at the top of the prioritised list because fixing them usually unlocks more load-time improvement than polishing secondary items. The report then covers the rest of what is holding the page back (other speed blockers, on-page SEO, accessibility, security, and AI readiness), so you are not left guessing what to do after the image fix.
A real example: 13.6 MB down to 56 KB
On an anonymised site we scanned, one image was still sitting at 13.6 MB - the kind of accidental raw upload that happens when someone drops a camera file or an uncompressed export straight into the CMS.
After proper compression for the web, that same image came down to about 56 KB.
| Metric | Before | After |
|---|---|---|
| File size | 13.6 MB | ~56 KB (0.054 MB) |
| Space saved | - | 13.54 MB |
| Reduction | - | 99.6% smaller |
| Size factor | - | New file is about 248× smaller |
That is not a subtle tweak. That is the difference between a page that feels broken on mobile and a page that loads normally.
What that saves in load time
File size only matters if it translates into waiting. Here is the approximate download time for that single image alone, ignoring the rest of the page, based on typical connection speeds:
| Connection type | Speed | 13.6 MB image | 56 KB image | Time saved |
|---|---|---|---|---|
| Slow 4G (poor signal / congestion) | 5 Mbps | ~22.8 seconds | ~0.09 seconds | ~22.7 seconds |
| Typical broadband (standard UK home) | 100 Mbps | ~1.14 seconds | Instant (~0.004 s) | ~1.14 seconds |
On a congested mobile connection, one uncompressed image can burn nearly 23 seconds before the visitor has even finished downloading that asset. Under the familiar three-second patience window, that page has already failed. Google's own mobile research found that 53% of mobile visits are abandoned when a page takes longer than three seconds to load (Think with Google / Google Analytics benchmark data).
On home broadband the absolute numbers look smaller, but a 1+ second tax on a single image still stacks with scripts, fonts, and everything else - and LCP (Largest Contentful Paint) often is that hero image. If you want the broader business case for speed, see why website speed matters. For the fix order that usually moves PageSpeed scores, see how to improve your Google PageSpeed score.
Why large images wreck Core Web Vitals
Google's ranking systems use Core Web Vitals as part of page experience. That is not industry rumour - it is in Google's own documentation: Core Web Vitals are used by Google's ranking systems, with loading performance measured primarily through LCP (aim for under 2.5 seconds for a "good" experience).
A multi-megabyte hero image is one of the most common ways to blow LCP:
- The largest visible element on many marketing pages is the image.
- Until that file finishes downloading and decoding, LCP stays poor.
- Poor field LCP contributes to a weaker page-experience signal in Search, especially when competing pages are otherwise similar in relevance.
Call it what it is: not a manual "penalty" letter from Google, but a real ranking disadvantage baked into how Search evaluates experience. For the plain-English breakdown of LCP, INP and CLS, see what are Core Web Vitals.
The second hit: people leave, and Google can see the dissatisfaction
Slow pages do not only hurt measured vitals. They change behaviour.
Someone clicks your result, stares at a blank or half-loaded screen, hits back, and tries the next result. That pattern is often called pogo-sticking. It is different from Analytics bounce rate, which Google has long said is not a direct ranking factor (your Analytics bounce number is not fed into Search as a score). We cover that distinction in what is bounce rate.
What does have supporting evidence is that Google uses aggregated search click behaviour as part of ranking systems. In the US Department of Justice antitrust proceedings, Google engineers described Navboost as a major ranking system built on user interaction data - including distinguishing more useful clicks from weaker ones over a long lookback window. Industry coverage of those exhibits summarises Navboost as using click patterns (including short, unsatisfactory visits back to the results) as a strong signal (Search Engine Land on Navboost and related signals).
So the honest chain is:
- A huge image slows the page (especially on mobile).
- Visitors abandon or bounce straight back to Google.
- Core Web Vitals already reflect the slow experience as a ranking input.
- Separately, repeated unsatisfactory clicks are the kind of interaction pattern Google's systems are designed to learn from - even though "bounce rate" in GA is not itself the lever.
You do not need a conspiracy theory. A 22-second mobile wait is enough to lose the visitor and train Search that the result disappointed people.
How images end up that large
The usual path is accidental, not malicious:
- Uploading a phone photo or DSLR export at full resolution
- Exporting from design tools at print or retina sizes meant for mockups, not the live web
- Using PNG for photographic content that should be JPEG, WebP, or AVIF
- Relying on the CMS to "handle it" without checking the final file size in the browser Network tab
A photo displayed at 800px wide does not need a 4000px-wide, multi-megabyte original. The browser will shrink it visually and still download the full file unless you resize and compress first.
What "compress properly" actually means
Good web compression keeps the image looking sharp at the size it is shown, while cutting bytes ruthlessly:
- Resize to display size - if it renders at 1200px wide, do not ship 4000px.
- Choose the right format - photos usually belong in WebP/AVIF (or well-compressed JPEG); simple graphics and logos often suit SVG or optimised PNG.
- Compress - reduce quality only as far as the image still looks crisp at the size visitors see it.
- Replace the live file - upload the compressed version in place of the oversized original.
- Set width/height - so the layout does not jump while the image loads (helps CLS as well as perceived speed).
Done well, a 99% size cut does not have to look blurry. If the result looks soft, the quality setting was too aggressive. Format and quality matter more than raw "compress harder."
How AuditCrow finds it - and helps you fix it
When you scan a page with AuditCrow, we look for the speed problems that actually move the needle. Large, uncompressed images are treated as a priority finding when they appear - they lead the report because they are often the fastest win - then we surface the other issues underneath so you can work the list in order.
Each issue comes with a plain-language explanation and a clear next step, so you are not decoding Lighthouse jargon to work out whether that 13 MB hero is the real problem. The free scan is one page - a taste of how the wider AuditCrow platform thinks about what to fix first.
Finding the asset is only half the job. Once available to the public, app.auditcrow.com will compress the offending file for you and give you a download of the optimised version - ready to upload and replace the raw asset on your site. No hunting for a separate compressor, no guessing which settings to use. Spot it on the free scan today; the platform will handle the replacement file when that capability opens.
Scan a page of your site if you want to know whether an accidental raw upload is hiding in the first viewport. If the report leads with an oversized image, you already know what to fix first - and when app.auditcrow.com ships the compress-and-download step, replacing it gets simpler still. The load-time difference is rarely subtle.
Quick checklist
- Run an AuditCrow scan so oversized assets surface as a leading issue alongside the rest of the page's problems
- If a large image is flagged, once available to the public, app.auditcrow.com will compress it and download the replacement file for you
- Upload the compressed file in place of the original on your site
- Prefer modern formats (WebP/AVIF) where your stack supports them
- Re-scan after replacing the files - especially check mobile load feel and LCP
One careless upload should not cost you 23 seconds on mobile, a ruined first impression, and a weaker signal in Search. Spot it with the free scan, replace the oversized asset, and keep the next accidental upload from going unnoticed.