One image that slows the whole page down
When someone asks me why their website "feels sluggish", the first place I look is the images — and in the vast majority of cases, that is exactly where the problem sits. The typical pattern: a large hero image right at the top, straight from the camera, several megabytes heavy. On most pages that very image is the Largest Contentful Paintelement — the one whose load time Google uses as its metric for "perceived speed". If it is too big, the page is slow. Not a little: measurably, in the range of full seconds, right where visitors start to get impatient.
Worked example: a 4 MB photo on a phone
Take a single, perfectly ordinary photo: 4 MB, straight off a smartphone. 4 MB is roughly 32 megabits that have to travel down the wire. Depending on the connection, this one transfer alone takes:
| Connection | Real usable rate | Transfer of 4 MB |
|---|---|---|
| Fast fiber | ~200 Mbit/s | ≈ 0.16 s |
| DSL / cable (average) | ~50 Mbit/s | ≈ 0.6 s |
| 4G mobile (realistic) | ~10 Mbit/s | ≈ 3.2 s |
| Throttled / packed train | ~2 Mbit/s | ≈ 16 s |
And that is oneimage. Google's LCP target is 2.5 seconds for the entire page. A hero image that takes 3.2 seconds to load on mobile alone blows that budget single-handedly — before any text, fonts or interactivity even get their turn. As a properly sized WebP, those 4 MB would have shrunk to around 200 KB, and those 3.2 seconds to about 0.16.
The bounce happens in the first few seconds
What happens next is well documented: the longer a page takes to appear, the more people have already left. On desktop you forgive a second or two — on a phone, on the move, with half a signal bar, you do not. And on mobile a second factor comes into play: data usage. A 9 MB page view (three images at 3 MB each) takes a noticeable bite out of the data plan. Anyone browsing while traveling or on a tight allowance remembers which pages are "data hogs" — and does not come back.
Google sees the slow images
Ever since Core Web Vitals became a confirmed ranking signal, this stopped being merely a matter of courtesy toward the visitor. Two of the three metrics hang directly on images: LCP (usually an image) and CLS (layout shifts, often caused by images without fixed dimensions). Score badly here and you hand visibility to faster competitors. How to prepare images specifically for search engines is covered in the post Image SEO.
CLS: the image that shoves the text aside
An underrated side effect of unoptimized embedding: images with no declared width and height. The browser does not know how much room the image needs until it loads — and pushes the text you were already reading downward the moment it arrives. That jolt is the Cumulative Layout Shift, and it is not just annoying: it counts toward your score too. The fix costs nothing: fixed width/height attributes, or an aspect-ratio in CSS.
Scaled up across a whole project
A single oversized image is annoying — across an entire website the effect multiplies. What "three images per page, a few megabytes each" turns into over 1,200 pages, in storage and traffic, I worked through in a dedicated example: How big does a website get from unoptimized images? The short answer: double-digit gigabytes, with an optimization lever of roughly a factor of 15.
How I tell that images are the problem
The diagnosis takes less than five minutes, and you need no expensive tool for it:
- Open the Network tab(in the browser's developer tools), load the page, sort by file size. If images of several MB sit right at the top, you have found the cause.
- Check the individual image. Drop a suspicious image into the Image Info tool — it shows dimensions, format and file size locally, with no upload at all. A 4000-pixel image in an 800-pixel slot is a sure sign.
- Identify the LCP element. Lighthouse or the Web Vitals overlay flags the slowest element — strikingly often, it is the hero image.
The way out — in three moves
Once you have found the cause, fixing it is usually trivial: resize it to its display size, convert it to a modern format, and compress it. At JNRT Pixel everything runs locally in the browser, without a single image ever leaving your device. The full workflow, including how to embed the results, is described in the compression guide.
Sources
web.dev — Web Vitals · web.dev — Largest Contentful Paint (LCP) · web.dev — Cumulative Layout Shift (CLS) · Google Search Central — Page Experience.