How Image Compression Affects SEO and Page Speed

Images make up over half the weight of the average web page and are the leading cause of Core Web Vitals failures. Here is what the data shows and exactly what to do about it.

Daniel Osei·March 28, 2026·11 min read

There is a moment that every website owner experiences eventually. You run a PageSpeed Insights test out of curiosity, or because traffic has been flat, or because a developer tells you to. The score comes back somewhere in the fifties. And right there in the list of recommendations, probably near the top: "Properly size images" and "Serve images in next-gen formats."

It feels like a small thing. Compressing a few photos. Surely that is not going to move rankings.

It can. And understanding why requires a short look at how Google actually measures your pages and what it does with those measurements.

How Google Uses Page Speed as a Ranking Signal

Google confirmed page speed as a ranking factor for desktop search in 2010. Mobile followed in 2018 with the Speed Update. In 2021, Core Web Vitals became part of the ranking algorithm, which is when image performance went from a general "good practice" to a measured, specific, and consequential signal.

Google announced the completion of mobile-first indexing in October 2023. Google primarily uses the mobile version of a site for crawling and indexing, which makes complete, accessible mobile content essential. Mobile performance is important to users, but it is not the sole factor determining rankings.

Core Web Vitals are three metrics Google uses to measure page experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). To pass, 75% of your page's real-user visits need to hit the "Good" threshold on all three.

According to the 2025 Web Almanac, only 48% of mobile pages pass all three Core Web Vitals. More than half the web is failing the test Google uses to evaluate page experience on mobile. Images are one of the primary reasons why.

LCP Is Usually an Image Problem

Largest Contentful Paint measures how long it takes for the main content of the page to become visible. That main content element, the "largest contentful element," is almost always an image. A hero image above the fold, a product photo, a blog post cover. Whatever is the biggest visible thing when the page first loads.

Google's threshold for a Good LCP is under 2.5 seconds. Needs Improvement is 2.5 to 4 seconds. Poor is anything above 4 seconds. The goal is to have 75% of your visitors experience LCP under 2.5 seconds.

An unoptimized hero image will fail this test on its own. A 1.5MB JPEG hero image loading over a mobile connection is not reaching 2.5 seconds. It might not even reach it over a strong WiFi connection for a first-time visitor without a cached version.

The fix is not complicated. Compress the image. Convert it to a modern format. Make sure the dimensions match what the page actually displays, so the browser is not downloading a 3000-pixel image to fill a 1200-pixel container. Those three steps alone move the LCP needle more than almost any other change on a typical content website.

If you want to see exactly what is causing your LCP and get specific suggestions, the blog post on Core Web Vitals and image compression goes into the technical specifics in much more detail.

What Images Actually Weigh on the Web

The HTTP Archive Web Almanac tracks the performance characteristics of millions of websites annually. The 2025 edition found that the median desktop home page weighs 2.9MB, up 7.3% from 2024. The median mobile home page is 2.6MB.

Images are the largest single contributor to that weight. According to the 2024 Almanac's sustainability chapter, images weigh nearly 4.4MB on average per desktop page across the full distribution, and account for more than 50% of a typical page's total weight. For WordPress sites specifically, images make up 50 to 70 percent of total page weight, and WordPress powers over 40% of the web.

Think about what that means practically. On a typical blog post or product page, you could cut the total page weight nearly in half just by compressing and converting the images. Nothing else on the page, no JavaScript optimization, no CSS cleanup, nothing touches file size the way images do.

The 90th percentile largest image per page is over 1MB. That one image, on one page load, represents roughly 40% of the entire recommended maximum page budget of 1MB that web performance specialists consider the ceiling for a good mobile experience.

The Direct Line Between Page Speed and Rankings

Google says its systems use Core Web Vitals, including LCP, while emphasizing that good scores do not guarantee high rankings. Images are common LCP candidates, so image optimization can improve one part of page experience. Google's page experience documentation explains this distinction.

There is also a user-experience benefit. Faster pages reduce waiting and can make it easier for visitors to reach and use the content. Individual case studies may show business improvements after performance work, but those results depend on the site and should not be treated as universal outcomes or proof of a separate bounce-rate ranking signal.

Format Choice Changes Everything

Most websites are still serving images in JPEG and PNG. Both are mature formats, both work reliably in every browser, and both are significantly less efficient than their modern alternatives.

WebP, developed by Google, produces files roughly 25-35% smaller than JPEG at equivalent visual quality. AVIF goes further still, typically achieving 40-50% smaller files than JPEG at similar quality. The 2025 web development ecosystem supports both widely: WebP now has over 96% browser support, and AVIF covers all current versions of Chrome, Firefox, Safari, and Edge.

That gap between JPEG and modern formats is not theoretical. A product photo that is 400KB as a JPEG is typically around 270KB as WebP and around 220KB as AVIF, with the same apparent sharpness at screen viewing sizes. At scale, across a site with dozens or hundreds of images, those savings compound into meaningful differences in page weight and load time.

The conversion from JPEG or PNG to WebP takes about ten seconds per image using browser-based tools. The JPG to WebP converter and PNG to WebP converter handle this in the browser with no uploads. For AVIF specifically, the JPG to AVIF and PNG to AVIF converters work the same way.

If you want a detailed comparison of WebP and AVIF with specific numbers on compression efficiency and browser support, the WebP vs AVIF comparison covers that properly.

Compression Quality Settings and the Real Tradeoff

There is a common fear that compressing images will make them look bad. This is true if you compress too aggressively, and it is worth understanding where the line actually sits.

For JPEG, the practical floor is around 75-80% quality for photographs displayed on web pages. Below that threshold, compression artifacts begin to appear: blocky distortion around high-contrast edges, visible banding in gradients, degraded detail in hair and fabric. Above 80%, the quality difference between the original and the compressed version is essentially invisible to a human eye at normal screen viewing distances.

The size difference between quality 80% and quality 100% JPEG is enormous. A photograph saved at 100% quality might be 2MB. The same photo at 80% quality is typically 300-500KB, with no visible degradation at the size it actually displays on a page.

WebP handles aggressive compression more gracefully than JPEG. You can go down to 70-75% quality on WebP before artifacts become obvious, which gives another few percentage points of file size reduction compared to JPEG at equivalent visual quality.

The key insight is that image quality is not binary. It is a slider, and the right position on that slider depends on the purpose of the image and how it will be displayed. A 2000-pixel hero image displayed at 1200 pixels wide has significant room for compression before any viewer notices. A small product thumbnail at 200x200 pixels has less room because artifacts become visible at small sizes. Understanding this helps you calibrate rather than just hitting a random preset.

For a detailed explanation of how lossy and lossless compression work and when to use each, the lossy vs lossless compression guide is worth reading before you start compressing a batch of images.

Image Dimensions: The Invisible Size Problem

Compression is the obvious lever. Dimensions are the less obvious one that often has an equal or greater effect.

Here is the issue: a camera or stock photo source produces images at full resolution, typically somewhere between 2000 and 6000 pixels wide. Your website's content column is probably 1200 pixels wide at most, and likely narrower on mobile. If you upload the 4000-pixel original and let the browser scale it down for display, you have made the browser download four times as many pixels as it needs.

File size scales roughly with the square of the dimensions. Halving the width and height quarters the total pixel count and reduces the file to approximately a quarter of its original size before you have even changed the compression settings. Resizing a 4000x3000 image to 1200x900 before compressing it is often the single most effective step you can take.

The resize image tool lets you set exact pixel dimensions and download the result. For common web sizes there are direct options: 1920x1080 for full-width hero images, 1280x720 for standard widescreen, 800x600 for inline blog content. Resizing first and then compressing gives you a much smaller starting point for the compression step.

Metadata Weight You Are Paying For Without Knowing

Every photo taken on a smartphone carries invisible EXIF data: GPS coordinates, device model, timestamp, camera settings. This information serves no purpose in a web image. A visitor viewing your product page does not benefit from knowing the photo was taken on an iPhone 16 Pro at 7:43am on a particular morning.

The EXIF header adds roughly 10-20% to an image file size. For a 400KB photo, that is potentially 60-80KB of invisible data that every single visitor downloads for no reason. On a page with ten images, this represents potentially 600-800KB of unnecessary data being served to every visitor.

Removing EXIF data as part of image preparation is free compression. Every browser-based tool at ImgTweak strips EXIF automatically during processing. You do not need to take a separate step. But it is worth being aware of, because if you are using a tool that preserves EXIF, you are leaving size savings on the table.

The guide on what EXIF data contains and why to remove it covers this in detail, including what specific information is stored and how to verify it has been removed.

The Crawl Budget Angle

There is one more SEO dimension that rarely gets mentioned in image compression discussions: crawl budget.

Googlebot visits your site on a schedule and processes a certain number of pages per crawl session. Slow pages consume more of that budget per visit than fast pages. For small sites with a few dozen pages this is irrelevant. For larger sites with thousands of pages, slow image-heavy pages mean Googlebot spends more time on each page and reaches fewer total pages per session. New content takes longer to get indexed.

Google says Googlebot currently fetches up to 2MB for an individual non-PDF URL, including response headers. Referenced resources are fetched separately. Content beyond the cutoff is not fetched, rendered or indexed. This unusually high limit is unlikely to affect a normal HTML document, but Google's crawler infrastructure explanation documents the exact behavior.

Heavy images slow Googlebot down the same way they slow human visitors. Smaller, properly formatted images mean faster crawling, more complete indexing, and new content getting into search results faster.

What to Actually Do: A Practical Order of Operations

If you have a site with unoptimized images and you want to improve search performance, here is the sequence that gives you the most return for the least time.

Start with your LCP image. Every page has one, it is usually the hero image or the first large photo above the fold, and it is the single image with the most direct impact on your Core Web Vitals score. Get it below 200KB. Convert it to WebP. Resize it to the actual display dimensions.

Then work through the rest of the images on your highest-traffic pages. Use PageSpeed Insights (it is free) to see which images are flagged as oversized or in suboptimal formats. It names specific files. Work through that list.

For format conversion, the converters at ImgTweak handle all the common combinations in the browser with nothing uploaded to a server. JPEG to WebP, PNG to WebP, JPEG to AVIF. Drop the file in, download the result.

For compression to specific file size targets, the target-size compressors handle this directly. If PageSpeed is flagging a specific image as too large and you need it under a certain threshold, compress to 100KB, 200KB, or 500KB depending on what you are targeting.

For a complete walkthrough of what makes image files large in the first place, which is useful context before you start optimizing, the guide on why image files get so large covers the underlying causes properly.

Realistic Expectations

Image compression is not going to take a site from position 20 to position 1 on its own. SEO is a multi-signal system and images are one input among many.

What image compression can reliably do is reduce image transfer size. That can improve the resource-load portion of LCP and make a page easier to use, but the outcome depends on the full loading path. Google states that relevance still takes priority when page experience is below ideal, so performance work should support strong content rather than replace it.

Images are the biggest piece of page weight and the most direct cause of LCP failures. They are also the easiest thing to fix. No developer required, no code changes, no hosting upgrades. Convert, resize, compress. The tools are free and the whole process takes minutes per page.

The difference between a site that passes Core Web Vitals and one that does not is often just that nobody has gotten around to the images yet.

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