Images account for roughly half the bytes of a typical web page. If you publish content, run a store, or build landing pages, image optimization is the single highest-leverage performance work you can do — it improves loading speed, search rankings, mobile data usage, and conversion rates at the same time. This guide covers the decisions that matter: format, dimensions, compression level, and delivery.
Compress before you upload. Run every image through the free JpegDiet compressor first — pick a sensible target or quality, and publish the smaller file.
Open the compressor1. Why image weight matters more than ever
Google's Core Web Vitals make Largest Contentful Paint (LCP) a ranking factor, and the LCP element is an image on most pages. A hero image that takes 2 seconds to download on mobile pushes your whole page out of the "good" threshold (2.5 seconds). Compressing that hero from 1.8 MB to 180 KB is frequently the difference between green and orange in PageSpeed Insights — no code changes required.
The commercial impact is well documented: slower pages convert worse, rank lower, and burn through visitors' mobile data plans. Uncompressed images are the most common — and most fixable — cause.
2. Choose the right format first
| Format | Best for | Notes |
|---|---|---|
| JPG | Photos without transparency | Universal compatibility, lossy, no alpha channel |
| WebP | Almost everything in 2026 | 25–35% smaller than JPG at equal quality; supports transparency and animation; supported by all modern browsers |
| PNG | Screenshots, diagrams, text, transparency-critical graphics | Lossless but heavy for photos |
| AVIF | Next-gen photo delivery | Even smaller than WebP; slower to encode; browser support now broad |
| SVG | Icons and logos | Vector — scales infinitely, usually tiny |
The practical 2026 workflow: photos go out as WebP (JPG as a fallback where needed), graphics with flat colors go out as SVG or optimized PNG, and icons ship inside an SVG sprite or an icon font.
3. Resize to the size actually displayed
The most common mistake is uploading images far larger than their rendered size. A blog column displayed at 680 pixels wide does not need a 4000-pixel original. Serving oversized images wastes bandwidth and forces the browser to scale them on the fly.
Rule of thumb: export at roughly 2× the displayed width for standard displays (this covers high-DPI phones), then let srcset serve smaller versions to smaller screens. A 1360-pixel-wide WebP is a sensible "large" for most content images.
4. Compress to a quality level people can't perceive
For photos, quality 75–85 in WebP or JPG is visually indistinguishable from 100 for almost all viewers, at a fraction of the file size. Below 60, artifacts start appearing around edges and in gradients. If your CMS doesn't tell you the quality mapping, compress to a target file size instead: for a hero image, aim for under 200 KB; for an inline content image, under 100 KB is very achievable at WebP.
5. Deliver correctly
- Lazy-load everything below the fold with
loading="lazy"— but keep the LCP image eager. - Set explicit width and height attributes so the browser reserves layout space and avoids layout shift (CLS).
- Serve via a CDN so images travel from a node near the visitor.
- Preload the hero with
<link rel="preload" as="image">when it's the LCP element.
6. A repeatable pipeline
- Export the image from your editor at 2× display width.
- Run it through JpegDiet with WebP output and a target size (100–200 KB for content images).
- Upload the compressed file with correct
width/heightattributes and a descriptivealt. - Enable lazy loading for everything except the hero.
- Re-check the page in PageSpeed Insights once a quarter.
Once this is habit, it adds seconds — not milliseconds — back to your pages, and it compounds across every image you publish.