How to Fix Images That Are Too Large
Your audit flagged one or more images whose file size or pixel dimensions are far larger than the page needs. Oversized images are the most common cause of slow Largest Contentful Paint (LCP) and wasted bandwidth. The fix: compress each image, resize it to the dimensions it's displayed at, serve a modern format (WebP or AVIF), and let the browser pick the right size with responsive srcset. WordPress, Shopify, Wix, and Squarespace can automate most of this; custom sites handle it with a build step.
What this means
"Image too large" means a specific image ships more data than it needs to. Either its file weight is high (flagged critical when it's heavy enough to delay the page, warning when it's bloated but less impactful) or its intrinsic pixel dimensions are much bigger than the space it renders in.
A classic example: a hero photo exported from a camera or stock site at 4000x3000 pixels and 3 MB, displayed in a container only 800 pixels wide. The browser downloads all 3 MB, then discards most of that detail when it scales the image down. The visitor waited for data they never saw.
The two audit codes reflect severity. image_too_large_critical fires on images heavy enough to visibly delay the page, typically the largest above-the-fold images. image_too_large_warning flags images that are bloated but lower impact. Both point to the same problem: the delivered bytes don't match what the layout requires.
Why it matters
Images are usually the heaviest thing on a page, so they dominate load time. When the biggest image sits above the fold, it's frequently the Largest Contentful Paint element, and Google measures LCP directly as a Core Web Vitals ranking signal. Google's "good" threshold is an LCP under 2.5 seconds; a multi-megabyte hero image alone can blow past that on a mobile connection. A slow LCP drags down your PageSpeed score and can suppress rankings on mobile, where most searches happen.
There's a user-experience cost too. Heavy images mean longer waits, more data burned on capped mobile plans, and higher bounce rates. On e-commerce and content sites, slower pages convert worse.
The answer-engine angle is easy to miss. AI crawlers from ChatGPT, Perplexity, and Google's AI systems fetch pages within time and resource budgets. Pages weighed down by huge images render slower and are more likely to time out or be fetched incompletely, so your content is less reliably ingested. Cleaner, faster pages get crawled and re-crawled more consistently, which makes your information more likely to be represented accurately in AI-generated answers. Fast, lightweight pages help everywhere: classic search, Core Web Vitals, and AI visibility.
How to fix it
- 1
Resize to the real display dimensions
The biggest win is usually the simplest: stop serving pixels the layout never uses. Check how wide the image actually renders (right-click, Inspect, read the rendered width) and export at roughly 2x that for high-DPI screens, then stop. An image shown at 800px wide rarely needs to be wider than 1600px. Don't rely on the browser to shrink a 4000px original with width/height attributes or CSS; it downloads the whole file first.
- 2
Compress before you upload
Run every image through a compressor to strip metadata and remove invisible detail. Squoosh (free, in-browser), TinyPNG, or ImageOptim handle one-offs; a build step with sharp or imagemin does it in bulk. For photos, JPEG or WebP quality around 75-82 is visually hard to tell from the original at a fraction of the size. Aim to get most content images under about 150 KB and hero images as low as the quality allows.
- 3
Switch to WebP or AVIF
Modern formats compress far better than JPEG and PNG at the same visual quality. WebP is supported by every current browser and typically runs 25-35% smaller than JPEG. AVIF compresses even harder but encodes slower. Convert your images and serve WebP or AVIF with a fallback so older clients still get a working image (see the code example). Most CMS image plugins can do this conversion automatically on upload.
- 4
Serve responsive sizes with srcset
One image size can't be right for both a 375px phone and a 1440px desktop. Generate several widths and let the browser pick using the srcset and sizes attributes. This sends small files to small screens, which is exactly where slow connections need the help. Next.js (next/image) and most CMS platforms generate these variants automatically once configured.
- 5
Lazy-load below the fold, prioritize the LCP image
Add loading="lazy" to images below the fold so they don't compete for bandwidth during initial load. Do the opposite for your LCP image: keep it eager and add fetchpriority="high" so the browser fetches it first. Never lazy-load the hero image; that delays LCP instead of improving it. Always set explicit width and height (or aspect-ratio) so the browser reserves space and you avoid layout shift.
- 6
Re-audit and confirm the LCP element
After deploying, re-run the audit and check PageSpeed Insights. Confirm the flagged images shrank and that LCP is under 2.5 seconds on mobile. Use the 'Properly size images' and 'Serve images in next-gen formats' opportunities in the Lighthouse report to catch anything you missed. Test on a throttled mobile connection, not just your fast desktop.
Example
<!-- LCP hero image: eager + high priority, not lazy-loaded -->
<picture>
<source
type="image/avif"
srcset="hero-800.avif 800w, hero-1200.avif 1200w, hero-1600.avif 1600w"
sizes="(max-width: 900px) 100vw, 800px">
<source
type="image/webp"
srcset="hero-800.webp 800w, hero-1200.webp 1200w, hero-1600.webp 1600w"
sizes="(max-width: 900px) 100vw, 800px">
<img
src="hero-800.jpg"
srcset="hero-800.jpg 800w, hero-1200.jpg 1200w, hero-1600.jpg 1600w"
sizes="(max-width: 900px) 100vw, 800px"
width="1600" height="900"
alt="Product name on a wooden desk"
fetchpriority="high">
</picture>
<!-- Below-the-fold image: lazy-load it so it doesn't compete with the LCP -->
<img
src="section-800.webp"
width="800" height="533"
alt="Team collaborating in an office"
loading="lazy" decoding="async">Serve a resized, modern-format, responsive image. AVIF and WebP are offered first with a JPEG fallback; srcset lets the browser download the smallest file that fits the layout, and the explicit dimensions prevent layout shift.
Platform-specific steps
Yoast and Rank Math don't compress images themselves. Install a dedicated image plugin such as ShortPixel, Imagify, EWWW, or Smush, and enable automatic WebP/AVIF conversion plus a bulk-optimize pass over your existing media library. WordPress already generates multiple sizes and srcset by default, so it serves appropriately sized images once your files are optimized. Add a caching or optimization plugin, or a CDN like Cloudflare, to deliver the optimized files. Avoid uploading originals larger than about 2000px wide; resize before upload or let the plugin cap dimensions.
Shopify automatically serves images as WebP and generates responsive sizes through its CDN, so much is handled for you. The common mistake is uploading enormous source files. Resize images to a sensible max (product images rarely need to exceed about 2048px) and compress them first with TinyPNG or Squoosh before uploading. In theme code, use the image_url filter with width parameters and the image_tag helper so Shopify emits correct srcset and sizes.
Wix serves images through its own CDN and converts to modern formats automatically, but oversized uploads still bloat pages. Compress and resize images before uploading them in the Media Manager. Use Wix's built-in image settings rather than stretching a small image to fill a large section. Wix handles responsive delivery, so your main job is uploading reasonably sized, pre-compressed originals.
Squarespace automatically generates multiple image sizes, serves the appropriate one for the container, and applies its own compression. To help it, upload images under about 2500px wide and compress them first (Squarespace recommends keeping uploads under roughly 500 KB). Don't embed huge full-resolution images in text blocks. If a specific image is still flagged, re-export it smaller and re-upload rather than relying only on the platform.
On custom sites, generate multiple widths and a modern format at build time with sharp or an image CDN (Cloudinary, imgix). Serve them with the picture element and srcset (see the code example) and always set width, height, loading, and fetchpriority. In Next.js, use the next/image component, which handles resizing, WebP/AVIF conversion, srcset, and lazy-loading automatically; set priority on your LCP image and configure the sizes prop to match your layout.
Frequently asked
There's no universal number, but useful targets are content and blog images under about 100-150 KB, and hero images as small as quality allows (often 150-300 KB after WebP or AVIF conversion). What matters more than any single threshold is that the file matches its display size and format. A correctly sized, compressed WebP is usually a fraction of the original JPEG or PNG.
Use WebP as the default for photos and most graphics; it's smaller than JPEG and supported everywhere. Use AVIF if you can generate it and want maximum compression, with a WebP or JPEG fallback. Keep PNG only for images that need transparency or crisp edges (logos, icons, screenshots with text). Prefer SVG for simple vector logos and icons, since it's tiny and scales infinitely.
Indirectly but meaningfully. Google doesn't rank you for small images per se, but oversized images slow your Largest Contentful Paint, and LCP is a Core Web Vitals ranking signal. Fixing heavy images improves LCP, your PageSpeed score, and overall user experience, all of which support rankings, especially on mobile where page weight hurts most.
Not if you compress sensibly. JPEG or WebP quality around 75-82 is visually hard to distinguish from the original for most photos while cutting size dramatically. Blur happens when you over-compress at very low quality, or when you upscale a small image to fill a large space. Start from a high-quality original, export at the correct dimensions, and use moderate compression.
Prioritize the critical ones first, especially any above-the-fold image that's likely your LCP element, since those directly affect Core Web Vitals. Warning-level images matter for total page weight and mobile data, so fix them too, but they're lower urgency. The most efficient approach is to automate compression and format conversion site-wide so new uploads are handled going forward, rather than fixing images one at a time forever.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.