2026-07-27
Why images are usually the reason your website feels slow — and what to do about it
If your website feels sluggish to load, the first place to look isn't your hosting plan or your JavaScript bundle — it's usually your images. Across the web, images are the single biggest thing loading on the average page, and Google now measures page speed directly as part of how it evaluates a site. Here's what's actually being measured, why images are almost always the biggest lever, and what to do about it.
Images are the heaviest thing on most web pages
HTTP Archive's 2025 Web Almanac, which crawls millions of real web pages, found that the median desktop home page weighs 2,862 KB in total — and images alone account for 1,058 KB of that, more than any other resource type, ahead of JavaScript (697 KB), fonts (139 KB), and CSS (82 KB) combined with HTML. On a typical page, images aren't just "a factor" in load time — they're the largest single factor, by a wide margin.
What Google actually measures: Largest Contentful Paint
"Feels slow" used to be subjective. It isn't anymore. Google's Core Web Vitals include a metric
called Largest Contentful Paint (LCP) — the time it takes for the biggest visible element on the
screen to finish rendering when someone opens your page. Google's own guidance is specific: a page
needs an LCP of 2.5 seconds or less, measured at the 75th percentile of real visits, to count as
"good." On a huge number of pages, that biggest visible element is a photo, a product shot, or a
hero banner — an <img>, a CSS background image, or a video's poster image are
all things Google explicitly counts as LCP candidates. If that one file is unnecessarily large, it
can single-handedly push a page out of "good" territory.
Does this actually affect search ranking?
Yes, but with an honest caveat. Google's own Search Central documentation states that Core Web Vitals, as part of page experience, "align with what our core ranking systems seek to reward," and Google explicitly recommends site owners hit "good" Core Web Vitals scores for search success. It isn't a magic lever that outranks weak content — Google has also been clear that content relevance still comes first. But between two pages with comparable content, the faster one has a real, acknowledged advantage, and a bloated image is one of the most common, most fixable reasons a page misses the threshold in the first place.
The three things that actually move the needle
None of this requires a developer or a rebuild. It requires getting the images themselves under control before they ever reach the page:
- Compress before you upload. A photo straight off a phone or camera is usually far larger than a web page needs. NearIMG's Compress tool lets you dial in a quality setting and see the resulting file size before you commit to it — for ordinary photos, a quality setting in the 80–90% range is usually visually indistinguishable from the original at a fraction of the size.
- Resize to the size it's actually displayed at. A 4000px-wide photo sitting in a 600px-wide content column is pure waste — every one of those extra pixels still has to be downloaded before the browser throws them away. NearIMG's Resize tool sets an exact target width or height (or a percentage) before export, so the file matches where it's actually going to be shown.
- Convert to WebP where you can. Google's own compression study found WebP produces files 25–34% smaller than JPEG at equivalent visual quality. NearIMG's convert-to-WebP tool does this conversion entirely in the browser, alongside the existing JPG/PNG converters, so switching formats doesn't require re-uploading anything anywhere.
What image optimization won't fix
To be fair about the limits: images are the biggest single line item in that Web Almanac chart, but they're not the only one. JavaScript alone is 697 KB on the median desktop page, and a slow server, an unoptimized font strategy, or render-blocking scripts can all hurt Core Web Vitals independently of anything happening to your images. Shrinking your photos won't fix a slow backend or a bloated JavaScript bundle. What it reliably does fix is the single largest, most common, and most mechanical source of page weight on the modern web — the part that's usually the easiest to fix first, because it doesn't require touching any code at all.
A quick pre-publish checklist
- Is this image actually sized for where it's displayed, not the original camera resolution?
- Is the compression quality set high enough to look good, but not needlessly at 100%?
- Would WebP save meaningful size here without a visible quality trade-off?
- Is this the image most likely to be the page's LCP element (a hero image, banner, or the first large photo above the fold)? If so, it's worth the extra thirty seconds to get right.