Images are usually the heaviest thing on a web page. The 2024 Web Almanac found that the median desktop homepage loads just over a megabyte of images, and the median mobile homepage around 900 KB. Much of that weight is invisible to visitors: pixels larger than the screen can show, metadata nobody reads, and quality settings far higher than the eye can detect.
Image compression removes that waste. Done well, it cuts page weight, speeds up Largest Contentful Paint, lowers hosting and CDN bills, and makes pages usable on slow mobile connections, all without visitors noticing any loss in quality.
This guide explains how lossy and lossless compression work, how to choose quality settings, the order of operations that gives the biggest savings, the tools worth using, and how to automate compression so it does not depend on someone remembering to run a plugin.
Key Takeaways
- Resize first, then compress. Serving an image at the dimensions it is displayed often saves more than any quality setting.
- Use lossy compression for photographs and lossless compression for logos, screenshots and graphics with sharp edges or text.
- There is no universal “best” quality number. Test visually on your own images and set a default per image type.
- Strip unnecessary metadata, and serve modern formats such as WebP or AVIF with fallbacks.
- Automate compression in your CMS, build pipeline or image CDN so new uploads are optimised by default.
Why image compression matters for SEO
Compression is not a ranking factor on its own. Its impact comes through user experience and page speed. The hero image on many pages is the Largest Contentful Paint element, so its download time feeds straight into one of the three Core Web Vitals. Lighter pages also load faster for real users on mobile networks, which tends to help engagement and conversions.
“Images are often the heaviest and most prevalent resource on the web.”
— web.dev, Image performance
Google’s own image guidelines make the same point: images are often the largest contributor to overall page size, and Google recommends modern optimisation and responsive image techniques. Compression also helps Google Images indirectly, since fast pages with sharp, well-described images give a better result for searchers. For alt text, file names and image sitemaps, see our separate image SEO guide; this post focuses on bytes.
Lossy vs lossless compression
All compression shrinks a file by representing its data more efficiently. The difference is whether any information is thrown away.
| Lossy | Lossless | |
|---|---|---|
| How it works | Discards detail the eye is unlikely to notice | Encodes the same pixels more efficiently |
| File size savings | Large | Modest |
| Quality | Slight, adjustable loss | Pixel-identical to the original |
| Best for | Photographs, product shots, hero images | Logos, icons, screenshots, diagrams, text in images |
| Formats | JPEG, lossy WebP, lossy AVIF | PNG, GIF, lossless WebP, lossless AVIF |
| Risk | Banding, blur or blocky artefacts if pushed too far | Files can stay large for photos |
Lossy compression on text or line art produces visible “ringing” around edges, which is why screenshots saved as low-quality JPEGs look fuzzy. Conversely, saving a photograph as lossless PNG produces a huge file with no visible benefit. Matching the method to the content is the first decision.
Choosing a quality setting
Most encoders expose a quality slider, typically from 0 to 100. The number is not a percentage of quality, and the same number means different things in different encoders and formats. A quality of 75 in one WebP encoder is not equivalent to 75 in a JPEG encoder.
“When compressing, there isn't a universal setting suitable for all cases.”
— web.dev, Image performance
For reference, the Lighthouse audit that flags poorly compressed JPEG and BMP images works by re-encoding them at quality 85 and flagging any image where the potential savings are 4 KiB or more. That gives a useful benchmark: if your JPEGs are saved above roughly that level, there is probably room to save bytes. In practice:
- Pick five or six representative images (a product photo, a portrait, a busy scene, a screenshot).
- Compress each at a range of settings in a side-by-side tool such as Squoosh.
- Zoom to 100% on a normal screen, not 400%. Visitors do not pixel-peep.
- Choose the lowest setting where you cannot see a difference, then use it as your default for that image type.
- Keep a slightly higher setting for images where detail sells, such as product close-ups or art.
The order of operations that saves the most bytes
Compression is the last step, not the first. Follow this sequence for every image:
- Question whether you need the image. Decorative stock photos that add nothing can simply go. Simple shapes and icons can often be CSS or SVG.
- Crop to the subject. Remove dead space so you are not encoding pixels nobody looks at.
- Resize to display dimensions. A 4000-pixel camera image shown in an 800-pixel column wastes most of its bytes. web.dev’s guidance is to size images for the container and the device pixel ratio, so a 500px slot on a 2x screen needs roughly a 1000px image.
- Choose the format. WebP or AVIF for photos, SVG for vector art, PNG or lossless WebP for screenshots. Our guide to WebP and AVIF covers format choice and fallbacks in depth.
- Compress using the quality default you tested.
- Strip metadata. EXIF camera data, GPS coordinates and editing history add bytes and can leak private information. Keep colour profiles where colour accuracy matters.
- Generate responsive variants at several widths and serve them with
srcsetandsizes. - Verify with PageSpeed Insights or Lighthouse, checking the image delivery insight for remaining savings.
Responsive images markup
Generating several sizes only helps if the browser can choose between them. A typical pattern looks like this:
<img
src="team-800.jpg"
srcset="team-400.jpg 400w, team-800.jpg 800w, team-1200.jpg 1200w"
sizes="(min-width: 960px) 800px, 100vw"
width="800" height="533"
alt="Our support team at the Leeds office">
The width and height attributes let the browser reserve space and avoid layout shift, while sizes tells it how wide the image will display so it can pick the smallest suitable file.
Image compression tools compared
| Tool | Type | Best for |
|---|---|---|
| Squoosh | Free browser app | Testing quality settings side by side, one image at a time |
| ImageOptim (macOS) | Free desktop app | Drag-and-drop lossless and lossy batch compression with metadata stripping |
| Sharp (Node.js) / libvips | Library | Build pipelines that resize, convert and compress automatically |
| cwebp, avifenc | Command-line encoders | Scripted conversion to WebP and AVIF |
| CMS plugins (WordPress) / built-in platform optimisation (Shopify) | Platform features | Optimising uploads without developer work |
| Image CDNs | Hosted service | Resizing, format negotiation and compression on the fly at the edge |
For a small site, a plugin plus a one-off bulk optimisation of the media library is usually enough. For larger or custom sites, compression belongs in the build pipeline or at the CDN layer, which we cover in CDNs and SEO.
Automating with a script
If you have developer support, a short Sharp script can resize and convert an upload folder in one pass:
import sharp from 'sharp';
const widths = [400, 800, 1200];
for (const w of widths) {
await sharp('uploads/hero.jpg')
.resize({ width: w, withoutEnlargement: true })
.webp({ quality: 75 })
.toFile(`dist/hero-${w}.webp`);
}
Treat the quality value as a starting point to tune against your own test images, not a recommendation for every site.
Don’t forget lazy loading and priority
Compression reduces the bytes; loading strategy decides when they are fetched. Lazy-load images below the fold with loading="lazy", but never lazy-load the main above-the-fold image, which delays LCP. Our lazy loading guide explains the trade-offs, and our LCP guide shows how to prioritise the hero image with fetchpriority="high".
Common mistakes
- Compressing a huge image instead of resizing it. A heavily compressed 4000px image is still far bigger than a sensibly compressed 1200px one.
- Re-compressing already compressed JPEGs. Each lossy save adds artefacts. Always compress from the original master file.
- One setting for everything. Screenshots and photos need different methods.
- Uploading PNG photographs. A common cause of multi-megabyte hero images.
- Stripping colour profiles from product images, which can make colours look different from the real item.
- Ignoring CSS background images and logos, which plugins that only process the media library often miss.
- Lazy-loading the LCP image, undoing the speed you gained from compression.
Related Guides
- WebP and AVIF: Next-Gen Image Formats Explained
- CDNs and SEO: How Content Delivery Networks Help
- How to Eliminate Render-Blocking Resources
Frequently Asked Questions
What is the best image compression quality setting?
There is no single best number, and quality scales differ between encoders. Test a few representative images, pick the lowest setting with no visible difference at normal zoom, and use that as your default.
Does image compression affect SEO?
Indirectly. Smaller images load faster, which improves page experience metrics such as Largest Contentful Paint. Compression will not rescue weak content, but it removes a common speed bottleneck.
Should I use lossy or lossless compression?
Use lossy compression for photographs and lossless for logos, icons, screenshots and images containing text or sharp lines.
Does compressing images reduce quality?
Lossless compression does not. Lossy compression does remove information, but at sensible settings the difference is not visible to visitors.
How big should images be for a website?
As small as possible while matching their displayed size. Size images for the container width multiplied by the device pixel ratio, and serve several widths with srcset.
Conclusion
Image compression is one of the highest-return speed fixes available: resize to display dimensions, choose the right format, compress at a tested quality, strip metadata and automate the whole process so it never depends on memory. Combined with sensible lazy loading, it can take a large share of the weight off a typical page. If your images are holding your Core Web Vitals back, our page speed optimization service can audit and fix them, or get a free quote.
References
- Image performance – web.dev (Learn Performance)
- Efficiently encode images – Chrome for Developers (Lighthouse)
- Google image SEO best practices – Google Search Central
- Page Weight chapter – HTTP Archive Web Almanac 2024
- Image file type and format guide – MDN
- How to Optimize Images for SEO – Semrush Blog




