Why Compress Images for the Web: Speed, SEO and Visitors

When a website feels slow, the pictures are the first place to look. A few hundred kilobytes of code and text can be dragged to several megabytes by a handful of photos uploaded straight from a phone. Visitors feel that as a blank hero area, text that jumps about while images arrive, and stuttering scrolling on a cheap handset.

Compressing those images is the fix with the best ratio of effort to result: it costs nothing, changes nothing a visitor can see at display size, and improves load time, Core Web Vitals and how long people stay. This article explains why you should compress images for web use, with figures from the HTTP Archive and Google rather than folklore, and ends with size targets for each kind of image.

Quick answer: images are the single heaviest part of a typical page (911 kB of a 2.6 MB median mobile home page, according to the 2025 Web Almanac), they are usually the element Google times for Largest Contentful Paint, and every extra megabyte costs mobile visitors time and data. Aim for roughly 200–300 kB for a full-width hero, 100–150 kB for a content image and under 50 kB for a thumbnail.

How Images Affect Page Load Time

The HTTP Archive crawls millions of pages every month, and its Web Almanac publishes the medians. For the July 2025 crawl, the median mobile home page weighed about 2.6 MB. Here is how those bytes were split:

Resource type	Median bytes on a mobile home page, July 2025
Images	911 kB
JavaScript	632 kB
Fonts	122 kB
CSS	77 kB
HTML	22 kB
Whole page	2,559 kB (about 2.6 MB)

Source: Web Almanac 2025, Page Weight chapter. Desktop is heavier still, at about 2.9 MB with roughly 1.06 MB of images. On both, images are the largest single resource type, about 36–37% of the bytes, and the same chapter reports that the median mobile home page has grown by about 200% since July 2015.

Faster connections do not remove the problem: every byte still crosses the network, and a browser cannot paint a photo until enough of it has arrived. HTTP/2 lets many files share one connection, which cuts per-request overhead, but does not shrink the files.

A worked example. A phone photo at 4000 × 3000 px is typically 3–4 MB; say 3.2 MB. Your theme shows it in a 1600 px wide hero. Resize it to fit within 1600 × 1200 px, compress to a 200 kB target, and you get a 196 kB file: a 94% saving that nobody can see at that display width. The same thinking applies to a product grid of 24 supplier photos at 1.2 MB each: nearly 29 MB untouched, 2.4 MB at 100 kB apiece.

Page Speed and SEO Rankings

Google is clear that speed matters for search, and equally clear about the limits. Its page-experience documentation says Core Web Vitals are used by its ranking systems, and in the same breath that relevance comes first: a highly relevant page can still rank with poor page experience. In short, fast pages win ties between equally helpful content.

Core Web Vitals are three measurements, taken at the 75th percentile of real visits, with “good” thresholds set by Google:

• Largest Contentful Paint (LCP): the time until the biggest element in the viewport is rendered. Good is 2.5 seconds or less; above 4 seconds is poor.
• Interaction to Next Paint (INP): responsiveness to taps and clicks. Good is 200 ms or less.
• Cumulative Layout Shift (CLS): how much the layout jumps around while loading. Good is 0.1 or less, per Google’s CLS guidance.

Images drive the first and the third. The 2025 Web Almanac Performance chapter found the LCP element was an image on 76% of mobile pages and 85% of desktop pages, mostly JPEG (57%) and PNG (26%). When a site fails LCP, the usual culprit is the big picture at the top. Only 62% of mobile pages reached a good LCP in that crawl, and just 48% passed all three vitals on mobile.

CLS has a related cause: an <img> without width and height attributes gives the browser no room to reserve, so text jumps when the picture lands. That is a markup fix, but a lighter file lands sooner and narrows the window for the jump.

Caching, a CDN and a fast server help repeat visitors, but a first-time visitor on a phone still has to download your 4 MB hero before seeing it. Shrink the file and every other optimisation works better.

User Experience Impact

You have probably read that most people leave a page after three seconds. We will not repeat such figures: the ones in circulation are old, come from very different kinds of sites, and rarely link to an original study. What we can say is that people notice waiting, notice it more on a phone, and act on it by tapping back or opening a competitor’s tab before they reach your form or Buy button.

Look at which pages carry the heaviest images: product pages on a shop, the work itself on a portfolio, posts with big featured images on a blog, the landing page with photos of the premises for a local business. These are the pages you most want people to finish, and the ones most likely to be slow.

Fast pages feel different. The hero is there when the page appears, the layout holds still, and attention stays on your words and products rather than on a spinner. None of that needs new hosting or a redesign; it needs images that are the right size for the job.

Mobile Users and Bandwidth Considerations

For most sites a large share of visitors now arrive on a phone, and a mobile network is a harsher place to load a page: signal drops on a train, speeds vary from one street to the next, and in much of the world data is bought in packs where every megabyte is paid for.

The arithmetic is simple. Suppose a visitor’s connection is delivering 5 Mbit/s, an unremarkable mobile speed. That is about 625 kB per second. A 3 MB image needs close to five seconds of transfer before decoding can even start. A 200 kB version of the same picture arrives in about a third of a second. On a slower 2 Mbit/s link, the gap becomes 12 seconds against under one.

Data cost is the other side. A gallery of twenty 3 MB images is 60 MB, a noticeable slice of a small prepaid plan. Twenty images at 150 kB are 3 MB in total, less than one of the originals. Data-saving modes on some phones and browsers may also hold back images on heavy pages, so the gallery looks half-finished to the very visitors who can least afford it.

How Much Compression Is Enough for Web Images?

The right file size depends on how large the image is displayed, not on how large the camera made it. These targets assume you have already resized the picture to about its display width (a 2× version for high-density screens is fine):

Image role	Display width	Target file size	Preset page
Hero or full-width banner	1600–2000 px	200–300 kB	200 kB or 300 kB
Blog or content image	800–1200 px	100–150 kB	100 kB or 150 kB
Product grid, card or thumbnail	300–600 px	30–60 kB	50 kB
Logo or icon	under 300 px	under 20 kB	keep as PNG or SVG

A simple rule of thumb for an existing site: any image over 500 kB deserves a second look, and anything over 1 MB has almost certainly never been processed at all. Opening your browser’s network panel sorted by size usually finds the offenders in a minute.

Format matters too. JPEG remains the safe default for photos, and WebP is better where you control the site: Google’s own measurements put lossy WebP 25–34% smaller than JPEG at the same SSIM score, and caniuse.com reported support in about 97% of browsers in use as of October 2026. Logos stay PNG or SVG, since JPEG smears sharp edges. Our guide to the best image formats for web performance covers AVIF and fallbacks, and JPEG vs PNG vs WebP is the plain three-way comparison.

Two tips from Google’s LCP optimisation guide: never lazy-load the hero image (the 2025 Almanac found about one page in six doing so, which delays LCP), and add fetchpriority="high" to it so the browser fetches it first.

Quick Guide to Compressing Images for Your Website

Here is the routine we follow for every image before it goes anywhere near a CMS:

1. Open the Mb2KbSizer compressor and drop in the photo, or paste it from the clipboard. It accepts JPG, PNG, WebP, GIF, BMP and, in browsers that can decode it, HEIC. Nothing is uploaded; the work happens on your own device.
2. Choose a target from the table above, by role. Use the “fit within” resize option to set the width too, for example 1600 px for a hero; the tool then finds the quality level that lands just under your number.
3. Download and check it at display size. The before/after slider shows the real difference. Look at the image in your page, on a phone, not zoomed to 300% in an editor.
4. If it looks soft, raise the target by 50 kB and run it again. Texture-heavy images such as foliage, fabric and crowds need more bytes than a portrait on a plain background.
5. Repeat for every image, or put a whole folder through the bulk image compressor, which takes up to 200 files at one target size and an optional maximum longest side, then hands back a ZIP.

After a dozen images you will have a feel for it. A typical phone photo of 2–8 MB lands around 150–250 kB at a sensible web width with no visible loss, because most of its bytes were paying for pixels the screen never shows. If a result looks worse than expected, reducing image size without losing quality explains what went wrong, and how image compression works covers the maths behind the slider.

The benefits add up quietly: a hero that paints inside Google’s 2.5-second LCP target, a layout that holds still, lower data bills for visitors on phones, and one less reason to lose a tie in search. For an hour’s work on an average site, that is a very good return.