How Image Compression Affects SEO and Page Speed

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 completed its transition to mobile-first indexing in July 2024. Every website is now evaluated by mobile Googlebot first, regardless of whether most of your visitors come from desktop. Your mobile performance is what determines your rankings, even for desktop search results.

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

The connection between image weight and rankings runs through two separate channels. The first is direct: Core Web Vitals, especially LCP, are a ranking signal, and images are usually what is failing the LCP threshold.

The second is behavioral and indirect but arguably more significant in practice.

According to Google's own research, 53% of mobile visitors abandon a page if it takes more than 3 seconds to load. When page load time goes from 1 second to 3 seconds, the probability of a visitor leaving before the page finishes loading increases by 32%. At 5 seconds, that bounce probability has risen by 90%.

When users bounce, Google's systems register it. A page that consistently sends users back to the search results is a page that is not serving users well. Over time, that behavioral signal affects rankings. This is the part that does not show up in a Core Web Vitals report but matters enormously for sustained search visibility.

The BBC ran an internal study that found their website lost 10% of its visitors for every additional second of load time. Swappie, a refurbished phone retailer, improved their Core Web Vitals and cut load time by 23%, which translated into a 42% increase in mobile revenue. Renault measured a 1-second improvement in LCP and saw a 13% rise in conversions. These are not hypotheticals from a simulation. They are documented outcomes from real websites measuring real users.

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 only processes the first 2MB of a page's HTML source. Beyond that, content is truncated and never indexed. While most pages stay well under that limit, it is a reminder that page weight has concrete technical consequences beyond just the user experience.

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 does reliably is remove a ceiling. Pages that fail Core Web Vitals are at a disadvantage to pages that pass them, all other content quality being equal. Slow pages lose visitors before they finish loading, and those behavioral signals matter over time. Sites that meet Google's performance thresholds are, according to Google's own data, 24% less likely to have visitors abandon the page during loading.

The December 2025 Google core update saw pages with LCP above 3 seconds experience roughly 23% more traffic loss than faster competitors with comparable content, according to third-party analyst data. That is a meaningful number. It does not mean speed trumps content quality. It means that when content quality is comparable, the faster site wins.

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.