Image Optimization for Faster Page Loads: What Actually Matters
What actually moves the needle on image-driven page speed — correct sizing, modern formats, and lazy loading — and what doesn't matter as much.
Images are usually the single largest contributor to a page's total weight, which makes them the highest-leverage place to look first when a page feels slow.
Most of the benefit comes from a small number of specific fixes, not from a vague instruction to "compress your images."
The fixes that actually move the needle are: serving each image at the size it’s actually displayed rather than a larger source scaled down in the browser, using a modern compressed format like WebP or AVIF instead of an unoptimized JPEG or PNG, and lazy-loading offscreen images so the browser doesn’t spend bandwidth on images the visitor may never scroll to.
Key Takeaways
- Serving desktop-sized images to mobile devices can use 2–4x more data than needed, per web.dev’s own guidance — matching an image’s displayed size to its source size is one of the highest-leverage fixes available.
- Format matters: WebP and AVIF produce meaningfully smaller files than JPEG or PNG at comparable visual quality, and modern browsers support both natively.
- Lazy-loading offscreen images keeps the initial page load from spending bandwidth on images a visitor may never scroll to — the hero/above-the-fold image should be the opposite: eager or priority-loaded, never lazy.
- Largest Contentful Paint (LCP) — one of Google’s three Core Web Vitals — is frequently the hero image itself, so the single largest optimization opportunity is often exactly the image visitors see first.
- A correctly-sized, moderately-compressed image beats an oversized image squeezed with aggressive compression — dimensions matter more than chasing extra compression on a source that’s too large to begin with.
Why Images Dominate Page Weight
On most content-heavy pages, images account for a larger share of total page weight than every other resource combined — markup, CSS, JavaScript, fonts. That makes them the highest-leverage place to start: a meaningful reduction in image weight typically has more impact on load time than trimming any other single resource type.
The Fixes That Actually Matter
Serve the Right Size, Not Just a Smaller File
A 2000px-wide source image displayed at 400px wide on a mobile screen forces the browser to download far more data than it will ever render — web.dev’s own guidance notes that serving desktop-sized images to mobile devices can use 2–4x more data than needed. Using responsive image techniques (srcset and sizes) lets the browser choose the smallest image that still looks correct for the visitor’s actual screen.
Use a Modern Format
WebP and AVIF compress more efficiently than JPEG or PNG at comparable visual quality, and both are natively supported by every modern browser — there’s rarely a good reason to ship an unoptimized JPEG or PNG as the final production asset today.
Lazy-Load What’s Offscreen — But Not the Hero
Images below the fold don’t need to load before the visitor has scrolled anywhere near them — lazy-loading them frees up bandwidth for what actually matters first. The hero image is the exception: it should load eagerly and with priority, since delaying it usually delays the page’s Largest Contentful Paint directly.
How This Connects to Core Web Vitals
Largest Contentful Paint measures how long it takes the largest visible element to render, and on most pages that element is an image — frequently the hero. An oversized, unoptimized, or lazily-loaded hero image is one of the single most common causes of a poor LCP score, which makes image handling one of the few technical fixes that maps almost directly onto a specific, measurable Core Web Vitals metric.
What Doesn’t Matter as Much
Squeezing a few extra percentage points of compression out of an image that’s already correctly sized and in a modern format produces diminishing returns compared to fixing the sizing or format in the first place. Stripping image metadata alone, without addressing dimensions or format, rarely moves a page’s load time in any noticeable way.
An Image Optimization Checklist
- Serve each image at (or close to) the size it’s actually displayed, using responsive srcset/sizes rather than one large source for every screen.
- Convert production images to WebP or AVIF rather than shipping unoptimized JPEG or PNG.
- Lazy-load offscreen images; load the hero/above-the-fold image eagerly with priority.
- Check whether the hero image is the page’s Largest Contentful Paint element and optimize it first if so.
- Avoid upscaling a low-resolution source — a small blurry image loads fast but looks worse than a correctly-sized sharp one.
Beyond Images: The Rest of the Performance Picture
Image handling is the highest-leverage single fix on most pages, but it isn’t the only performance issue a site can have — plugin and script bloat, render-blocking JavaScript, and uncached server responses all contribute independently. See why WordPress sites struggle with Core Web Vitals for how those other factors show up in practice, particularly on plugin-heavy platforms.
Frequently Asked Questions
Is compressing my images enough to fix page speed?
Usually not on its own. Compression helps, but serving the wrong size (a large source scaled down in the browser) or an outdated format typically has more impact than squeezing extra compression out of an already-oversized image.
Should every image be lazy-loaded?
No — offscreen images should be lazy-loaded, but the hero or above-the-fold image should load eagerly with priority, since it’s frequently the page’s Largest Contentful Paint element and delaying it directly hurts that metric.
WebP or AVIF — which should I use?
Both compress meaningfully better than JPEG or PNG and have strong modern browser support; AVIF often compresses slightly smaller but WebP has broader tooling support. Either is a real improvement over an unoptimized JPEG or PNG.
How do images affect Core Web Vitals specifically?
Most directly through Largest Contentful Paint (LCP) — the largest visible element on a page is frequently an image, often the hero, so an oversized or slow-loading one is a common cause of a poor LCP score.
Does image size matter more than format?
Generally yes — a correctly-sized image in an older format still beats an oversized image in a modern format, because the dimensions determine how much data has to be decoded and rendered regardless of compression.
Is it safe to upscale a low-resolution image to fill a larger space?
No — upscaling doesn’t add real detail, it just produces a blurry image at a larger file size than the original. It’s better to use a properly-sized source image to begin with.
Is Your Site Fighting You on Speed?
See what a CMS migration actually involves — and whether it addresses the real cause of your site’s speed problem.
Sources and Further Reading
Responsive image sizing: web.dev — Serve Responsive Images. Broader image-performance guidance: web.dev — Image Performance.
Written by
Rafael Arceo
Rafael Arceo is a digital marketing and web technology specialist focused on Google Ads conversion tracking, GTM, GA4, SEO, WordPress, Payload CMS, and website conversion setup.
Related Posts
Google's four LCP subparts explained, with the specific fix for each — and why compressing images alone often doesn't move your score.
What LocalBusiness structured data actually does in Google Search and Maps, which fields matter most, and when a service business genuinely needs it.
What structured data actually does for SEO, which schema types are worth adding, and why FAQ rich results don’t work the way they used to.
Need Cleaner Tracking or a Better Website Setup?
Send your website URL and I can help identify what needs to be checked, fixed, or improved.