Optimize Images for Website Speed and Core Web Vitals

A site loads slowly, and the first suspect is usually the hosting or a "heavy" theme. In most cases, though, the culprit is mundane: images. A single photo straight off a camera can weigh as much as the entire code of a page, and just a few of them on the home page are enough to leave a visitor waiting several seconds for something that should appear instantly.

This isn't a purely cosmetic problem. Image weight feeds directly into Core Web Vitals — the set of metrics Google uses to measure the real-world experience of using a page. Those metrics influence search rankings and, even more tangibly, whether a visitor sticks around at all. Let's look at why images weigh the most and how to slim them down without spoiling the look.

Why images are what slow a site down

The average page today is, in large part, images. The HTML, the stylesheets and even the scripts are usually counted in kilobytes, while a single phone photo runs into megabytes. The proportions can be dramatic: the text and layout come to 200 KB, and the gallery underneath — eight megabytes.

There's a second issue: images often block what the user sees first. A big header photo, a banner or a product shot at the top of the page is usually the largest element the browser has to download and paint before the page starts to look ready. While that file is downloading, the visitor stares at emptiness or a shifting skeleton.

And finally — there are usually a lot of images. One heavy file is a problem, but twenty product thumbnails at half a megabyte each is ten megabytes to download before the customer even sees the offer.

LCP, or how images wreck Core Web Vitals

The most important metric images affect is LCP (Largest Contentful Paint) — the time it takes for the largest visible element to appear on screen. On the vast majority of pages, that element is an image: the header photo, the main banner, the first picture in an article.

The mechanism is simple. The heavier that key image, the longer it takes to download and display, and the later the page "snaps" into shape. Google treats an LCP under 2.5 seconds as good, between 2.5 and 4 seconds as needing improvement, and above 4 seconds as poor. A single unoptimized banner weighing several megabytes is enough to land in the red zone even on a fast connection — and on a phone out in the field, all the more so.

Images can also worsen CLS (Cumulative Layout Shift) — the metric that measures how much content jumps around while loading. When an image has no space reserved in advance, the text settles first and then lurches downward once the photo arrives. That's irritating and scored against you. The fix here is in the layout rather than the weight, but it's worth remembering, since the two problems tend to travel together.

Image weight versus Google rankings and conversion

Page speed is one of the factors Google weighs when ordering results, and Core Web Vitals are the concrete, measurable signals of that speed. It isn't a magic switch that will lift a page to the top on its own — content and relevance to the query matter more — but between two pages of similar quality, performance can tip the balance. A slow, image-heavy page starts from a worse position.

The second, often underrated side of the coin is conversion. Here the numbers speak for themselves: each extra second of loading noticeably raises the share of people who give up before they see anything. On a phone, on a weaker signal, patience runs out faster still. A store that shows a product after five seconds loses customers to one that does it after one — regardless of price.

From what we see: slimming images down is usually the cheapest performance optimization there is. It needs no code rewrite or change of hosting, and the effect on the metrics shows up immediately.

The three pillars of image optimization

The whole craft comes down to three moves, performed in the right order. Each one cuts weight, and together they can shave off 80–90 percent with no visible difference on screen.

Pillar 1: the right dimensions for the layout

The most common mistake is uploading images at camera dimensions — 4000, 6000 pixels wide — into a slot that's 800 or 1200 pixels at most. The browser will shrink such an image on the fly, but the visitor still downloads the full, enormous version. Pure wasted bandwidth.

The rule is simple: an image should have as many pixels as it actually occupies on screen (with a margin for high-density displays — usually a factor of two is enough). A photo inside an article rarely needs more than 1600 px on the long edge, a product thumbnail 600–800 px, a full-screen background around 1920 px. Just going from 4000 to 1600 px can cut the weight by two thirds before you even touch compression. With a lot of photos, the easiest path is to do it in bulk — bulk resizing runs the whole batch in one pass.

Pillar 2: a modern format — WebP or AVIF

The format decides how cleverly the same pixels get encoded. JPG is still a solid choice, but WebP at the same quality usually weighs 25–35 percent less, and AVIF goes lower still. Both are supported today by every major browser.

In practice, for most sites, switching from JPG to WebP delivers the biggest win for the least effort. If a gallery sits in JPG, converting it to WebP alone can reduce the total weight by a third. Just keep a JPG fallback for the few places that won't open WebP — and when you need to reverse direction, a quick WebP-to-JPG conversion helps. A separate guide covers the differences between formats: JPG, PNG, WebP or AVIF.

Pillar 3: sensible compression

Compression comes last — the deliberate sacrifice of detail the eye doesn't catch anyway. The trick is hitting the point where the file is small but the loss is invisible. For photos, quality around 75–85 percent is the sweet spot — go lower and you start seeing blocky edges and mush on smooth surfaces.

When you want a specific, predictable weight, it's easier than juggling a quality slider to name the target size and let the tool handle the rest. That's how compressing to 200 KB works — a sensible ceiling for larger in-article images; for thumbnails and smaller graphics, reach for the 100 KB variant. The whole process runs in the browser, so the photos never leave your device.

Serve an image at the size it's displayed

This rule deserves its own paragraph, because it's the one broken most often. There's no point uploading an image larger than the layout calls for. If a product photo shows up in a 400-pixel-wide tile, a 3000 px file is ten times the data — data someone has to download and the browser throws away anyway.

In practice this means matching the file's dimensions to its real slot in the layout, not to whatever the camera spat out. A background image, a hero at the top, a thumbnail in a grid and an in-article photo are four different sizes — and each should get its own fitted version, rather than one giant file used for everything.

Lazy-loading, or load what's visible

Another cheap win is deferred loading. Browsers can load images only as the user scrolls down to them, rather than fetching an entire long page at once. It's enough to add the attribute loading="lazy" to images below the first screen.

There's one exception worth remembering: the main image at the very top (the LCP one) should not be deferred — on the contrary, that's the one meant to load as early as possible. Save lazy-loading for galleries and photos further down the page.

A mini-audit of the images on your page

Before you start optimizing, it pays to know where the megabytes actually leak. This mini-audit takes a few minutes:

1. Open the page and weigh it. In the browser, the developer tools panel (the "Network" tab) is enough: it shows the total page weight and how much of it is images. Most often, images account for well over half.
2. Spot the largest files. Sort the resources by size. Usually a handful of culprits stand out — a few heavy photos that make the difference on their own.
3. Check dimensions against display. For each big image, compare its dimensions with the space it occupies on screen. If a file is 4000 px and the tile is 400, you've found your first candidate to shrink.
4. Look at the format. A .png extension on ordinary photographs is a warning sign — PNG for photos can weigh several times too much.
5. Measure LCP. Free tools from Google show which element is the largest and how long it takes to display. That points to which image to tackle first.

After such a review it usually turns out that a handful of files account for 80 percent of the problem. Slimming those down gives the biggest jump, and that's where to start.

Target image weight per page

There's no single sacred number, but there are reasonable reference points. A single in-article photo should fit within 100–300 KB, a larger banner or hero up to 400–500 KB, a thumbnail in a grid under 100 KB. If any file tops a megabyte, it can almost always be slimmed down safely.

At the whole-page level, a good target is total image weight under one, at most two megabytes — counting everything visible on arrival. It sounds strict, but after going through the three pillars it turns out to be quite achievable, and the difference in speed is plain to see.

One small but pleasant note to finish on: since the entire process — resizing, conversion and compression — can be done in the browser, product photos, company material or client images don't have to land on someone else's server just to be slimmed down. The details are in our privacy policy.

FAQ

Why does my site load slowly even though the code is light?

In most cases it's the images. A single photo straight off a camera can weigh more than the entire code of a page, and a few of them at the top is already several megabytes to download before anything appears. Weigh the page in the developer tools — images usually account for well over half the total.

How do images affect Core Web Vitals?

Most strongly through LCP, the time the largest element takes to appear — and that's usually the main image. The heavier it is, the later the page looks ready. Images with no reserved space also worsen CLS, the jumping of content while it loads.

How much should images on a page weigh?

A single in-article photo is best at 100–300 KB, a banner up to 400–500 KB, a thumbnail under 100 KB. The total weight of images visible on arrival should fit within one, at most two megabytes.

Does WebP really make a difference over JPG?

Yes. At the same quality WebP usually weighs 25–35 percent less, and every current browser supports it. For most sites, switching from JPG to WebP delivers the biggest win for the least effort.

Do I have to optimize images one by one?

No. The easiest way is to run the whole batch through bulk resizing and compression in one pass and download the result as a ZIP. The entire process happens in the browser, so the files are never sent anywhere.