Image Size and Page Speed: Core Web Vitals Explained

Why images dominate load time

A web page is built from a small HTML file and many other resources. Of these, images are usually the heaviest: a few photographs can outweigh all the scripts and styles of a page together. The browser has to download them over a connection that may be slow, shared or metered, and then decode and draw them. Every extra megabyte makes the page slower and costs the visitor data.

Speed matters beyond comfort. Visitors leave pages that take too long, and search engines include page experience among the signals they use for ranking. It is only one signal among many and relevant content matters far more, but a fast page removes a handicap, and for images the fix is simple and mechanical.

The Core Web Vitals in short

Core Web Vitals are three measurements defined by Google that describe the experience of loading and using a page. Largest Contentful Paint, or LCP, measures how long it takes until the largest visible element, often an image, is displayed. Interaction to Next Paint, or INP, measures how quickly a page responds to clicks and taps. Cumulative Layout Shift, or CLS, measures how much the layout jumps around while loading.

Images affect two of them directly. They are often the LCP element, so a heavy image delays LCP. And images without reserved space cause layout shifts when they appear. INP depends mostly on scripts, not on images.

LCP and the hero image

According to Google's guidance on web.dev, a good LCP is 2.5 seconds or less, a value between 2.5 and 4 seconds needs improvement, and more than 4 seconds is poor. The values are judged at the 75th percentile of real visits, which means that three quarters of visits should reach the threshold, measured separately for mobile and desktop.

The LCP element can be an image, a block of text or a video poster. On many pages it is the large picture at the top. If that picture is 3 MB, a visitor on a mobile connection may wait many seconds for it. Reducing it to a few hundred kilobytes, by resizing and compressing, is often the single most effective change for LCP.

What to change, in order of effect

First, reduce the pixel dimensions to the size at which the image is shown, because this shrinks the file most. Second, choose an efficient format and a moderate quality: WebP or JPEG at 70 to 85 for photos. Third, serve several sizes with srcset so that phones do not download desktop images. Fourth, load images that are below the fold lazily, and make sure the LCP image is not lazy-loaded.

A quick plan for a single page: find its largest image, compress it with the tool on this page, check that its file size is in the range of 100 to 300 KB for a hero image, upload it and measure again. When the image is the bottleneck, that one change can improve the score noticeably.

Layout shifts

When an image has no width and height, the browser does not know how much space to reserve, and the content below jumps down when the image finishes loading. This is what CLS measures. The fix is cheap: add width and height attributes that match the image's pixel dimensions, or set an aspect ratio in CSS. The browser then reserves the right space before the file arrives.

This is also a reason to keep proportions when you resize. The compressor keeps the aspect ratio and shows the new pixel dimensions in the list whenever it reduces the size, so you can use them as the width and height in your page.

Measuring it

Use real tools, not a feeling. PageSpeed Insights and the Lighthouse panel in Chrome's developer tools show LCP and point to the images that could be smaller. The Network panel lists every file with its size, so you can sort by size and see which image is the largest. The Chrome User Experience Report and your search console show field data from real visitors, if your site has enough traffic.

Test on a throttled connection, or on a real phone, because a fast office connection hides problems. After each change, measure again; the aim is to see the numbers move, not to follow a checklist.

A realistic target

There is no universal file size that guarantees a good score, because it also depends on the server, caching, fonts and scripts. As a rule of thumb, aim for the total weight of images on a page to be well under a megabyte or two for ordinary pages, and for any single image to be as small as it can be without looking worse at its display size.

The most practical habit is to compress every image before you upload it. It takes seconds with a batch tool, it does not depend on your hosting, and it works for every page you add in the future.

Common questions about speed

A frequent question is whether a smaller image always means a faster page. In most cases yes, but only if the image is actually the bottleneck. If a page is slow because of scripts, fonts or a slow server, shrinking the pictures will help only a little. Use the Network panel to see what takes the time before you decide what to change.

Another question is whether it is worth converting old images. For a site with many pages, start with the most visited ones and the largest images; a handful of changes usually delivers most of the gain, and the rest can follow gradually.