Images Are Why Your Site Is Slow

Why this is worth your time

Largest Contentful Paint is one of the Core Web Vitals, and Core Web Vitals are a ranking signal. Google's own threshold is 2.5 seconds; past that, the page is classified as needing improvement, and the effect compounds with the ordinary consequence of a slow page, which is that people leave.

The comparison that makes it concrete: a 3 MB page on a mid-range mobile connection takes several seconds before anything useful appears. The same page at 800 KB feels instantaneous. Same content, same design, same server.

Step one: resize (this is the big one)

A phone camera produces images around 4000 pixels wide. Your article column is 800 CSS pixels wide. On a high-density screen the browser wants roughly 1600 physical pixels for it — so about 84% of the data in that photograph is downloaded and immediately discarded.

Export at twice the display width and no more. For most sites that means 1600-2000 pixels for hero images and 1600 for in-article images. Nothing else on this list saves as much, and everything else on this list is cheaper if you do this first.

Step two: convert to WEBP

WEBP produces files 25-35% smaller than JPG at visually identical quality, and roughly the same saving over PNG for graphics. Every browser in current use supports it. This is a free 30% off the images you have already resized.

If you want to go further, AVIF is roughly 50% smaller than JPG, at the cost of slower encoding and patchier support in the tools around your site. Serve it with a WEBP fallback rather than instead of one.

Step three: compress to the right level, once

Quality 80-85 is where you want to be for photographs. Above 90 you are shipping bytes nobody can perceive; below 75 the artefacts start showing on gradients and skin tones.

Compress from the original, never from an already-compressed copy — the damage from repeated lossy encoding accumulates and it is not recoverable. Aim for in-article images under 150 KB and hero images under 300 KB.

• Hero: 1600-2000 px wide, WEBP quality 82, under 300 KB.
• In-article: 1600 px wide, WEBP quality 80, under 150 KB.
• Thumbnails: 600 px wide, WEBP quality 75, under 30 KB.

Step four: the markup that costs nothing

Three attributes do a surprising amount of work, and all three are one-line changes.

Set explicit width and height on every image. Without them the browser does not know how much space to reserve, so the page jumps as images arrive — that is Cumulative Layout Shift, another Core Web Vital, and it is entirely avoidable.

• width and height on every img — eliminates layout shift.
• loading="lazy" on images below the fold — they do not download until needed.
• fetchpriority="high" on the hero image only — it tells the browser which image is the LCP.
• Never lazy-load the hero. Doing so delays the exact element LCP is measuring.

What to measure afterwards

Test on a throttled mobile connection, not on your desktop over office wifi. Chrome DevTools can simulate Slow 4G, and PageSpeed Insights does it by default — which is why its score is always worse than what you see locally, and why its score is the one that matters.

Then look at your real users rather than the lab. Search Console's Core Web Vitals report shows field data from actual visitors, on actual devices and connections. That is the data Google ranks on, and it is free.