How Image Compression Affects Core Web Vitals and SEO

PageSpeed Insights gives you a score between 0 and 100. Most sites score somewhere in the 40s and 50s on mobile. The most common reason is images.

Not bad code. Not slow servers. Images that are too large, in the wrong format, or served without compression. Fix the images and the score moves. Ignore them and everything else you do to speed up the site runs into a ceiling.

This is not a coincidence. Images are typically the largest assets on any given page. They have more influence over loading speed than almost anything else you can touch. And because Google uses real-world loading speed as a ranking signal, how you handle images has a direct line to where your pages appear in search results.

What Core Web Vitals Actually Are

Google introduced Core Web Vitals in 2020 as a standardised way to measure how a page feels to a real user. They replaced the older collection of lab-based performance metrics with three field-measured signals that reflect actual user experience.

As of March 2024, the three Core Web Vitals are:

LCP (Largest Contentful Paint) measures how long it takes for the largest visible element on a page to load. This is usually a hero image, a large product photo, or a prominent text block. Google's threshold is under 2.5 seconds to be rated Good. Between 2.5 and 4 seconds is Needs Improvement. Above 4 seconds is Poor.

INP (Interaction to Next Paint) replaced First Input Delay in March 2024. It measures how quickly the page responds to interactions, clicks, taps and keypresses, throughout the entire session. The threshold is under 200 milliseconds for Good. INP is driven mostly by JavaScript, not images, so it is less directly affected by compression.

CLS (Cumulative Layout Shift) measures visual stability. It tracks how much page elements jump around unexpectedly as the page loads. The threshold is below 0.1 for Good. Images affect this when they load without declared dimensions and cause content below them to shift downward.

Google uses the 75th percentile of real-user data from the Chrome User Experience Report. This means at least 75% of page loads need to meet the Good threshold for a site to pass. One slow user drags the whole score.

Images Cause 80% of LCP Problems

LCP is where image compression matters most. Unoptimised images are the most common reason sites fail LCP.

The logic is direct. LCP measures when the largest element becomes visible. On most pages that element is an image. If that image is a 3MB JPEG that the browser has to download before rendering it, the LCP time is however long that download takes. On a mobile connection, 3MB takes several seconds. On a slower mobile connection, longer.

Compress that image to 200KB in WebP and the same content loads before the threshold. Nothing else about the page changed. Just the image.

Images cause 80% of LCP problems on most sites. The math is not complicated. If you want to move your LCP score, start with the image.

The Format Question

Not all compression is equal. The format you choose determines how much you can compress before quality degrades.

JPEG is the baseline. It is the format most photos live in. MozJPEG, the encoder used by performance-focused tools, squeezes significantly more compression out of JPEG than the default encoder in most image editing software. A MozJPEG-encoded JPEG at 80% quality is often smaller than a standard JPEG at 70% quality with no visible difference to the eye.

PNG is lossless. Every pixel is preserved exactly. This makes it the right choice for logos, screenshots, UI elements and anything with hard edges or text. But it is the wrong choice for photographs, where lossless compression produces files far larger than necessary. A photo saved as PNG is typically three to five times the size of the same photo as a good JPEG. OxiPNG can optimise PNG files further, but the format's fundamental limit is that it does not discard data.

WebP achieves roughly 25-34% smaller files than JPEG at equivalent quality. It supports both lossy and lossless modes, handles transparency (which JPEG does not), and is supported by all major browsers. For most websites replacing JPEG with WebP is the single highest-impact format change available. Google developed WebP specifically to make the web faster, and the size reduction over JPEG is consistent enough across image types that it should be the default format for most web images.

AVIF goes further. AVIF files are typically 50% smaller than JPEG and 20-30% smaller than WebP at equivalent quality. The compression is based on the AV1 video codec, which was designed to push compression efficiency to its limits. The trade-off is encoding speed: AVIF takes longer to compress than WebP, which matters if you are processing images in bulk. Decoding is also slightly heavier on the browser, though for most users the difference is not perceptible. AVIF supports high dynamic range, wide colour gamut and high bit depth, which is relevant for photographers and e-commerce sites where colour accuracy matters. As of 2025, browser support for AVIF is at 93.8% compared to WebP at 95.3%, so both are viable for production without fallbacks, though offering a WebP or JPEG fallback remains good practice.

JPEG XL is a newer format that offers excellent compression and a lossless JPEG re-compression mode. Browser support is still developing. It is worth watching but not yet the safe default.

The practical recommendation for most sites: use WebP for general images. Use AVIF for your largest or most performance-critical images, particularly the LCP element. Use PNG for anything with hard edges, transparency or text. Use JPEG when compatibility with older systems is required.

This is covered in more detail in the comparison of WebP vs AVIF if you want to go deeper on the format decision.

The Quality Setting and Why "More Is Not Better"

Every lossy format (JPEG, WebP, AVIF) has a quality setting, usually expressed as a percentage. This is where most people go wrong in both directions.

Setting quality too low produces visible artefacts. The image looks blocky or smeared. Users notice, even if they cannot articulate why.

Setting quality too high wastes bytes. At some point, increasing quality from 85% to 95% adds 40% more bytes with no visible improvement. The human eye cannot detect the difference at typical screen sizes and viewing distances. Those extra bytes just add to the download time.

The sweet spot for JPEG and WebP is typically 75-85% for photographs. For AVIF, 70-75% achieves excellent quality at lower file sizes. For anything with text, sharp edges or a logo, lossless is the right choice regardless of format.

A useful way to think about it: compress until you can see a difference at normal viewing size, then back off one step. That is your optimal quality setting for that image.

There is no universal number. A photograph of a sunset tolerates more compression than a product shot of a watch face. Test with your actual images rather than applying a blanket setting and assuming it works across all content types.

CLS and Declared Image Dimensions

CLS is the other Core Web Vital where images play a direct role, and it is one of the easiest to fix.

When a browser encounters an image without declared width and height attributes, it does not know how much space to reserve. It renders the surrounding content first, then when the image loads it pushes everything below it downward. Users see content jumping around. That is cumulative layout shift.

The fix is to always include width and height attributes on your img elements, or to set an aspect ratio in CSS. This tells the browser exactly how much space to reserve before the image loads. The content stays in place. CLS goes to zero for that element.

<img src="hero.webp" width="1200" height="630" alt="Hero image" />

This is free. It requires no new tools. But a site full of images without declared dimensions will consistently fail CLS regardless of how well the images themselves are compressed.

The LCP Element Deserves Special Treatment

Not all images on a page are equal. The LCP element is the one that determines your LCP score. Everything else is secondary.

Identify your LCP element using PageSpeed Insights or Chrome DevTools. It is usually the hero image, the first large product image, or the first large content block. Once you know what it is, treat it differently from everything else.

The LCP image should not be lazy-loaded. Lazy loading is correct for images below the fold, it defers loading until the user scrolls toward them. But applying lazy loading to the LCP element delays the exact image that determines your LCP score. This is a common mistake that directly hurts the metric.

The LCP image should be preloaded. Adding a preload hint in the document head tells the browser to start fetching the image before it processes the rest of the HTML:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high" />

The LCP image should be the most aggressively compressed image on the page. It is a single file. Spend time on it. Try WebP at 80%, try AVIF at 72%, compare the visual results at actual display size and pick the smallest version that looks right.

Responsive Images and Serving the Right Size

Serving a 1920-pixel wide image to a mobile phone with a 390-pixel screen is wasteful. The browser downloads all 1920 pixels and then scales the image down. All those extra pixels are downloaded but never displayed.

The srcset attribute solves this by letting the browser choose the right image size for the current screen:

<img
  src="photo-800.webp"
  srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1600.webp 1600w"
  sizes="(max-width: 600px) 400px, (max-width: 1200px) 800px, 1600px"
  alt="Photo"
/>

The browser reads the viewport width, matches it against the sizes attribute, and downloads only the version it needs. A mobile user never downloads the 1600-pixel version.

Generating multiple sizes requires a build step or a CMS that handles it automatically. But for the most important images, doing it manually is worthwhile. The LCP image on mobile should be a mobile-sized file, not a desktop image being scaled down in the browser.

What the Numbers Look Like in Practice

The business case for Core Web Vitals optimisation is well established at this point.

Vodafone improved LCP by 31% and saw an 8% increase in sales. Pinterest reduced perceived wait time by 40% and saw 15% more sign-ups and 15% more SEO traffic. Renault improved LCP by one second and saw a 14% drop in bounce rate and 13% more conversions. A 0.1 second improvement in page speed correlates with an 8% improvement in conversion rates according to collaborative research between Deloitte and Google.

These are not from startups experimenting with performance. They are large sites with significant traffic where a fraction of a second of improvement was worth millions.

The mechanism is simple. Faster pages rank better. Pages that rank better get more traffic. Pages that load faster also convert better because users do not abandon the page before it finishes loading. 53% of mobile users abandon a site that takes more than 3 seconds to load.

Core Web Vitals are Google's confirmed ranking factors, accounting for approximately 10-15% of ranking signals. They do not override content quality. A well-written page on a slow site will outrank a thin page on a fast one. But between pages of similar quality, the faster one has the advantage. And as more sites optimise, the threshold for "fast enough" rises.

How to Check Where You Stand

Before changing anything, measure the current state.

PageSpeed Insights (pagespeed.web.dev) gives you a score and lists specific opportunities. The Opportunities section usually has image-related items near the top, with estimated byte savings and time savings for each. This is your prioritised to-do list.

Google Search Console shows Core Web Vitals data for your real users, segmented by mobile and desktop. It is slower to update than PageSpeed Insights but reflects actual user experience rather than a simulated test.

Chrome DevTools lets you inspect the LCP element directly. Open DevTools, run a Performance trace, and look for the LCP marker in the timeline. Click it to see exactly which element triggered the measurement.

WebPageTest provides waterfall charts showing what loaded in what order and how long each resource took. Images that appear early in the waterfall and take a long time are your targets.

The Practical Workflow

Having a system makes this manageable rather than something you revisit once every two years.

For existing sites: run PageSpeed Insights, identify the images flagged under Opportunities, compress and convert those images to WebP or AVIF, add width and height attributes to your img elements, and remove lazy loading from the LCP image. Measure again. Repeat for the next set of flagged items.

For new content: compress every image before it goes into the CMS. Set a personal rule that no image goes live above a certain file size, 200KB is a reasonable ceiling for most images, with an exception for hero images that can go to 400KB if necessary. Convert to WebP by default. The getting started guide to image compression covers the process of compressing images in detail.

For the LCP element: treat it as a first-class concern. Know what it is. Keep it small. Preload it. Declare its dimensions. Check it every time the page layout changes.

ImgTweak handles compression, format conversion and resizing entirely in your browser. No uploads, no server, no file size limits. You can compress a batch of images to WebP or AVIF, check the before and after comparison, and download them in the right size for the device in a few minutes. The batch processing feature means you can optimise an entire page's worth of images at once rather than one at a time.

The Compression Quality Balance

The question this article started with was about balance: finding the optimal point between file size and visual quality.

That point is not the same for every image. It is not the same for every page. It depends on the content type, the display size, the audience's connection speed and what the image is communicating.

But there are defaults that work in almost every situation. WebP at 80% for photographs. WebP lossless or PNG for logos and UI. AVIF at 72% for images where file size is especially critical. Width and height attributes everywhere. No lazy loading on the LCP element. These are not controversial settings. They are the result of a lot of industry testing and they give you a strong starting point.

The other side of the balance is the quality floor. Below a certain compression level, image quality degrades in ways that damage trust. A product image that looks slightly blurry communicates carelessness. A hero image with visible compression artefacts sets the wrong tone before the user reads a word.

The way to find that floor is to look at your compressed images at the actual size they will appear on screen. Not at 100% zoom in an image editor. At the size a user on a laptop or phone will see them. If you cannot see a quality difference at that size, the compression is not hurting you. If you can, back off.

Compression and quality are not opposites. With the right format and the right settings, you can have both. The goal is not the smallest possible file. It is the smallest file that does not look compressed.