Core Web Vitals and Images: Compression Is the Smallest Lever

The advice is always the same: compress your images and your Core Web Vitals will come good. Google publishes field data on where that time actually goes, and on sites that fail the metric, downloading the image is the shortest part of it. Around 8%.

The hero image on our last post weighs 11.1 KB by the time a phone receives it. There is no version of squeezing that further which anyone will ever feel. Meanwhile the median failing site spends 1.29 seconds waiting before the download even begins. That is the gap worth your afternoon, and almost nobody writes about it.

This is not an argument for ignoring image weight. It is an argument about order, and about one step that genuinely does matter being confused with another that mostly does not.

The three metrics, briefly

Core Web Vitals is three measurements, each judged at the 75th percentile of page loads and split between mobile and desktop. Pass means all three sit in the good band for at least three quarters of visits.

LCP is when the largest image, text block or video in the viewport finishes rendering. INP is how long the page takes to paint a response to taps, clicks and key presses. CLS is the largest burst of unexpected layout shift across the whole life of the page.

Anything between the two columns below is the “needs improvement” band, which is to say not yet a pass.

Only two of those can be an image problem. INP is about what your JavaScript does when somebody taps something, and no amount of image work moves it. If your INP is poor, nothing in this article will help you, and you should be reading about long tasks instead.

Where the time actually goes

LCP splits into four consecutive parts: the wait for the server to start responding, the wait before the browser begins fetching the image it has decided is largest, the download itself, and the gap between the bytes arriving and the pixels appearing.

Google published the median of each, at the 75th percentile, for origins whose LCP is poor. These are the sites with the problem, not the average site:

The durations are Google's. The share column is ours, calculated from those four durations, because the shares are the thing people argue about and it is better to show the arithmetic than to assert it. Google's own summary of the same data is blunter: “The majority of origins with poor LCP spend less than 10% of their p75 LCP time downloading the LCP image.”

Read the second row again. Resource load delay is the stretch where the browser knows it needs a picture and has not started getting it: it is still parsing, still waiting on a stylesheet, still running the script that will eventually reveal the image URL. As Google puts it, the median failing site spends “almost four times as long waiting to start downloading the LCP image as it does actually downloading it.”

There is a second finding in there worth pulling out, because it contradicts the usual excuse. For these same failing origins the median image download is only 20% slower on mobile than on desktop. The story that your images are fine really and it is just phone networks does not survive the data.

What our own pages actually ship

Numbers from somebody else's corpus are worth checking against your own files, so here are ours. The master artwork for the formats post is a 1536x1024 JPEG at quality 88, and it weighs 206.4 KB on disk. Nobody is ever sent that file.

These are the bytes actually returned by our image endpoint at three widths, read from Content-Length, with and without a browser that accepts modern formats:

A phone gets 11.1 KB of a 206.4 KB original. That is 94.6% smaller, about one eighteenth of the file, and almost all of the saving comes from sending fewer pixels rather than from compressing the ones sent harder.

The arithmetic that settles it

Lighthouse models a slow 4G connection at roughly 1.6 Mbps. Put the two files through it:

• The 206.4 KB master: about 1,032 ms of download
• The 11.1 KB resized AVIF: about 55 ms

That is the whole case, in two lines. Resizing is worth roughly a second, which is enormous against a 2.5 second budget. Compressing the resized file further is worth tens of milliseconds, which is nothing. The same word, optimisation, is doing both jobs in most articles, and that is why people spend a weekend tuning quality settings and watch their score refuse to move.

It is arithmetic, not a measurement, and the assumption is stated so you can redo it with your own connection figure.

So what should you do, in order

1. Fix the server response. 2,270 ms is the single largest block on failing sites. Caching, a CDN and a hosting plan that is not oversold will move LCP further than every image change combined.
2. Make the hero image discoverable early. Put it in the HTML as a plain img, not a CSS background and not something a script inserts. Do not lazy-load the one image that is above the fold: it is the single most common way to add a second to your own LCP on purpose.
3. Send the right number of pixels. This is the step worth a second. Serve widths that match the layout rather than one desktop-sized file to everyone.
4. Then pick a modern format. Real, and worth 54 to 60% on our files, but it is a bonus on top of the resize rather than a substitute for it.
5. Set width and height on every image. Costs nothing and belongs to a different metric, below.

Where images genuinely do decide a metric

CLS is the one people forget, and it is the one where an image is usually at fault rather than incidental. Google lists the causes as “images or videos with unknown dimensions, fonts that render larger or smaller than its initial fallback, or third-party ads or widgets that dynamically resize themselves.”

An image without intrinsic dimensions occupies no space until it arrives, then shoves everything below it down the page. The fix is free: put real width and height attributes on the tag, and the browser reserves the box before a single byte of the picture lands. Not rounded, not guessed, the actual pixel dimensions of the file.

This is why our own post type refuses to make the artwork dimensions optional while the artwork itself is optional. A post can ship with no illustration at all, but it cannot ship with an illustration whose size is unknown.

Questions people ask

Is image compression a waste of time then?

No, it is a cheap win in the wrong position. Do it, because it is nearly free once your pipeline does it automatically. Just do not expect it to rescue a page whose server takes two seconds to answer, and do not do it before the two steps above it.

My images are already small and LCP is still poor. Why?

Most likely your largest element is not an image at all. LCP counts text blocks too, so on a text-led page the metric is measuring a heading waiting on a web font. Check which element the browser actually picked before optimising anything.

Does any of this affect rankings directly?

Core Web Vitals is a real signal and a small one, and it has never been the thing that outranks better content. The reason to fix LCP is that people leave slow pages, which is a bigger problem than the ranking factor and one you can see in your own analytics.

What does Resiqo do about this?

It handles exactly one step in that list, the third: resizing and format conversion, which run in your browser and are unlimited on every plan including the free one, because they cost us nothing to run. It does nothing for your server response time, which is the larger problem on most failing sites. We would rather say that than imply otherwise. If you want the naming side instead, that is in batch renaming images for SEO, and the format question is settled with measurements in WebP vs JPEG vs PNG.

Sources: web.dev, Common misconceptions about how to optimize LCP, for the four subpart durations, the “less than 10%” figure, the “four times as long waiting” comparison and the 20% mobile gap; web.dev, Largest Contentful Paint, for the 2.5 and 4.0 second thresholds, the 75th percentile rule and which elements qualify; web.dev, Interaction to Next Paint, for the 200 and 500 millisecond thresholds; web.dev, Cumulative Layout Shift, for the 0.1 and 0.25 thresholds and the list of shift causes. The share column in the subparts table and the download arithmetic are ours, calculated from the figures shown. The delivered file sizes were read from Content-Length on this site's own image endpoint on 4 October 2026 and can be refetched.