How Image Size Directly Impacts Core Web Vitals and Mobile SEO

Written and reviewed by the Compress To KB editorial team. Last updated September 24, 2026. We build and maintain the compressor this guide refers to, so what we say about how it behaves comes from its actual code and from day-to-day use, not from guesswork.

If you open PageSpeed Insights on a slow page and read the recommendations from the top, there is a good chance the first three are about images. That is not a coincidence. Photos are usually the heaviest thing a page downloads, and they are very often the element Google's metrics are timing. This guide explains how image weight connects to Core Web Vitals, what is worth fixing first, and how much ranking benefit you should realistically expect.

A Quick Refresher on the Three Metrics

Core Web Vitals are three measurements of real-user experience. Largest Contentful Paint (LCP) is the time it takes for the biggest visible element to render, and Google considers 2.5 seconds or less to be good. Interaction to Next Paint (INP) measures how quickly the page responds to taps and clicks, with 200 milliseconds or less counted as good. Cumulative Layout Shift (CLS) scores how much the layout jumps around while loading, with 0.1 or less as good. Google evaluates them at the 75th percentile of real visits, separately for mobile and desktop, using field data from the Chrome User Experience Report. The web.dev documentation explains all three in detail.

Notice what that means in practice: your score is not what you see on your own fast laptop. It is what the slower quarter of your visitors experience, which for many sites is a mid-range Android phone on a patchy 4G connection.

Where Images Hurt LCP

On most blog posts, product pages and landing pages, the largest element is an image: a hero, a featured photo or a product shot. LCP time is the sum of four parts, which web.dev lists as time to first byte, resource load delay, resource load duration and element render delay. File size affects the third part directly. A 2.8MB photo straight from a phone takes several seconds to download on a modest mobile connection no matter how good your hosting is. Bring the same image to around 150–250KB and that part of the timeline shrinks dramatically, often by more than any server upgrade would achieve.

The other parts matter too, and compression will not fix them. If the browser does not discover the hero image until late, or if a script delays rendering, a small file still arrives late. Do not lazy-load the LCP image, since lazy loading tells the browser to wait. Give it fetchpriority="high" instead, and make sure it is in the initial HTML rather than injected by JavaScript.

Where Images Hurt CLS

Layout shift happens when an image arrives and pushes text downward because the browser had not reserved space for it. The cure is unglamorous: put width and height attributes on every image, or use the CSS aspect-ratio property, so the space exists before the pixels do. Smaller files help indirectly because they finish loading sooner, but reserved space is what actually prevents the jump.

What About INP?

To be straightforward about it, INP is mostly about JavaScript and main-thread work, not image bytes. Huge images can contribute indirectly, for instance by making decoding compete with scripts on a weak phone, but if your INP is poor, look at your scripts first. We mention it so you do not chase image compression to fix a problem it cannot solve.

Dimensions Matter as Much as Kilobytes

A frequent mistake is compressing a 4000-pixel-wide photo to 300KB when the page only ever displays it 800 pixels wide. You have paid for pixels nobody sees. The better order of work is to resize the image to about twice its largest display width (the extra covers high-density phone screens), then compress it. Our tool is a compressor, not a resizer: it keeps your dimensions when it can and reduces them only as a last resort to reach a target, so resize first if you know the display size.

Sensible Targets for Common Image Roles

These are starting points, not laws. A photo with a lot of fine texture, such as foliage or fabric, needs more bytes to look clean than a photo of a smooth sky. Always check the result at the size a visitor will actually see it.

Choose the Format Wisely

At the same visual quality, WebP is generally smaller than JPEG and AVIF often smaller still, which means the same LCP image can weigh noticeably less without any visible change. We compare them properly in JPEG vs WebP vs AVIF. For a website you control, serving WebP or AVIF with a JPEG fallback through the picture element is a well-supported approach. Pair it with srcset and sizes so phones download a smaller version than desktops; the responsive images article on web.dev is the clearest reference we know.

Measure Before and After

Do not optimise on faith. Run your page through PageSpeed Insights, note the LCP element it identifies, and record the field data if your site has enough traffic to show it. Then replace only that one image with a compressed version and test again. If the LCP element turns out to be a text block or a slider script, compressing images will not move the number, and you will have saved yourself a lot of wasted effort. Lab tools like Lighthouse give instant feedback, but field data in the Search Console Core Web Vitals report takes about a month to reflect changes, so be patient.

How Much Will This Help Your Rankings?

Honest answer: some, but not as much as headlines suggest. Google states that page experience is one signal among many and that great content relevant to the query can still rank well with a mediocre score. Where speed makes a clear difference is in what happens after the click. A widely cited 2020 study by Deloitte for Google, Milliseconds Make Millions, found that shaving a tenth of a second off mobile load times was associated with measurable gains in retail conversions and engagement. Faster pages keep visitors around, and that benefit does not depend on any ranking algorithm. If you sell products, our guide on optimising e-commerce images applies the same ideas to catalogues.

A Practical Order of Work

• Identify the LCP image on your five most-visited pages.
• Resize each to about twice its display width.
• Compress it to a sensible target using the 200KB or 100KB tool, and inspect the result.
• Add width and height attributes, and fetch priority on the hero.
• Lazy-load images below the fold, never the hero.
• Re-test, and only then move to the next batch.

Small, targeted changes to a handful of important images almost always beat a site-wide overhaul. Start with the picture your visitors see first.

A Word on Third-Party Optimisation Plugins

Many content management systems offer plugins that promise to compress every image automatically on upload. These can be genuinely useful, and if you already run one, check what it is actually doing before assuming the job is finished. Some only apply lossless optimisation, which trims a small percentage without changing quality; others let you set a lossy quality level or a target size, which is where the real savings come from. Run a plugin-optimised image through PageSpeed Insights afterwards rather than trusting the plugin's own dashboard, since "optimised" badges do not always mean "small enough". A manual pass on your handful of highest-traffic pages, using a specific target size for the actual LCP image, often beats a blanket automatic setting tuned to be safe for every image on the site.

Common Questions

Does converting to WebP or AVIF automatically fix LCP? Only partly. A smaller file downloads faster, which helps the load-duration part of LCP, but if the image is discovered late or a slow script blocks rendering, format alone will not fix those parts of the timeline.

Should I compress every image on the page the same way? No. Treat the LCP image differently from images far below the fold. The visible hero deserves careful, individual attention; a gallery of thumbnails can usually share one setting.

Is there a point where compressing further stops helping? Yes. Once a file is small enough that the download time is no longer the bottleneck, further compression only risks visible quality loss for no measurable speed gain. Test on a throttled mobile connection to find that point rather than guessing.