SnapSiteScan verdict

Images are your bottleneck

When images are the largest measured cause, the page is slow for a reason that can be fixed in an afternoon without touching application code — usually by a handful of oversized files.

Ownership

Content or design

This is a content and asset problem more often than an engineering problem. In most cases the fix is uploading different files, not writing different code.

What happens if you do nothing?

On a mobile connection the hero image alone can delay the visible page by several seconds, and the visitor is paying for those megabytes out of their own data allowance before they have seen anything.

Do this first

1
Fix the largest image in the first screen — only that one
The LCP image sets the number visitors and Google both react to. Resize it to the size it is actually displayed at, and export it as WebP or AVIF.
2
Stop serving desktop images to phones
A 2400 px file rendered in a 380 px column wastes roughly 97% of its bytes. Responsive sources fix this once, permanently.
3
Lazy-load everything below the fold — and nothing above it
Lazy-loading the hero image is the most common self-inflicted speed regression on the web. It delays the exact element being measured.
4
Put a limit into the upload process
If images are uploaded by non-technical editors, the fix only lasts if compression happens automatically on upload.

How do you know this verdict is yours?

Total page weight dominated by a few image files.
'Properly size images', 'serve images in modern formats' or 'efficiently encode images' report savings measured in megabytes.
Largest Contentful Paint points at an image element.
The same page is acceptable on desktop and painful on mobile.

Not worth your time given this verdict

Server upgrades — the server is delivering these bytes as fast as anyone could.
JavaScript bundle tuning while a multi-megabyte image is still on the page.
Micro-optimising icons and logos measured in kilobytes.

Deprioritising a finding is a prioritisation call, not a claim that it never matters.

When to stop

When should you stop working on this?

Stop when no single image above the fold exceeds roughly 200 KB and the LCP element loads in under 2.5 seconds. Further compression is invisible to the eye and to the score.

Send this to your team

The message that ends the discussion

Our page speed issue is images, not hosting or code. A few oversized files are doing most of the damage. Fastest fix is resizing and converting the hero image, then everything above the fold.

Quick answer

My website is slow because of images — what is the fastest fix?

When images are the largest measured cause, the page is slow for a reason that can be fixed in an afternoon without touching application code — usually by a handful of oversized files. This is a content and asset problem more often than an engineering problem. In most cases the fix is uploading different files, not writing different code.

Owner: Content or design
First action: Fix the largest image in the first screen — only that one

What to do next: The LCP image sets the number visitors and Google both react to. Resize it to the size it is actually displayed at, and export it as WebP or AVIF.

Not sure which verdict is yours?

Run a scan and SnapSiteScan will name the dominant cause, the owner and the first action for your page — using the same model as this page.

Scan your site

Content or design

What happens if you do nothing?

Do this first

Fix the largest image in the first screen — only that one

Stop serving desktop images to phones

Lazy-load everything below the fold — and nothing above it

Put a limit into the upload process