How Image Compression Affects Core Web Vitals and SEO

Images cause 80% of LCP problems. Here is how compression, format choice and quality settings directly affect your PageSpeed score and Google rankings.

Daniel Osei·February 3, 2026·11 min read

PageSpeed Insights gives you a performance score between 0 and 100 and reports both lab diagnostics and, when available, field data. Images are one common bottleneck, but scripts, fonts, server response, and third-party code can also dominate.

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.

Images can be among a page's largest assets. Optimizing them can improve loading experience when they are the bottleneck. Google considers Core Web Vitals within its broader page-experience systems, but performance does not guarantee a particular search position. See Google's page experience guidance.

For a focused checklist on the metric most often affected by images, read how to optimize images for Largest Contentful Paint.

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.

Core Web Vitals field assessment uses the 75th percentile of real-user experiences. This describes the distribution across visits; one slow visit does not by itself determine the result. See Google's Core Web Vitals thresholds.

Images Are a Common LCP Bottleneck

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.

If the LCP element is an image, inspect its discovery time, request priority, transfer size, and decoding cost. If the LCP element is text, server response, fonts, CSS, or rendering work may be the better starting point.

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 supports lossy and lossless modes and transparency. Google's test sets produced smaller files than comparable JPEG and PNG samples, although results vary by image and settings. See Google's WebP documentation and compression study.

AVIF can provide strong compression and supports high dynamic range, wide colour gamut, high bit depth, and transparency. Encoding can be slower than WebP. Netflix's engineering tests show the potential benefits and the variation across content and settings. See Netflix's AVIF evaluation. Check current compatibility for the browsers and tools in your delivery chain.

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 higher than an image needs wastes bytes. The size increase and visible difference depend on the encoder, source content, display size, and viewer, so compare actual outputs rather than assuming a fixed percentage.

For JPEG and WebP photographs, 75 to 85 is a useful starting range. Quality scales are not equivalent between codecs. Text, sharp edges, and logos may benefit from lossless encoding, but test the result at its intended size.

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.

An LCP image that is not discoverable early in the initial HTML may benefit from preloading. Do not add a duplicate preload when the browser already discovers and prioritizes the correct resource promptly:

<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

Performance case studies can show correlations or results from a particular implementation, but they do not predict the outcome for another site. Measure changes with your own field data, analytics, and controlled experiments.

Google states that good Core Web Vitals do not guarantee top rankings and that relevant content remains central. Treat performance as a user-experience improvement and one part of a much broader search system. See Google's page experience guidance.

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.

Useful starting points include testing WebP around 80 for photographs, lossless WebP or PNG for suitable logos and UI, explicit dimensions, and no lazy loading on an in-viewport LCP image. These are starting points, not rules for every image or page.

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.

Written by

Daniel Osei

Web Performance Engineer

Daniel has spent 6 years optimizing images and web assets for publishers and e-commerce brands. He writes about image formats, compression techniques, and web performance at ImgTweak.

View author profile and editorial background