Tools
How to Reduce Image File Size for a Faster Website
Heavy images are the single biggest reason websites feel slow. A typical product or marketing page ships more than two megabytes of weight, and roughly half of that is images served at full resolution, full quality, and in the wrong format. Larger files push your Largest Contentful Paint past the 2.5 second target, inflate bounce rate, and quietly bleed conversions — every extra 100 KB on a hero image costs measurable engagement on both mobile and desktop. If you only do one performance pass this quarter, do it on images.
Why heavy images kill your page
Google's Core Web Vitals treat the largest image on the page as the Largest Contentful Paint element. The current "Good" threshold is under 2.5 seconds at the 75th percentile of real users. The HTTP Archive reports that the median desktop page now weighs in around 2.5 MB and the median mobile page around 2.2 MB, with images consistently responsible for roughly 50% of that weight. A single 1.2 MB hero photo can therefore decide whether your LCP score is green, yellow, or red — before any of your carefully-written JavaScript ever runs.
The business case is just as clear. Google's own research links a one-second improvement in mobile load time to higher conversion rates across retail, travel, and lead-gen sites. On flaky 4G connections a 600 KB image and a 60 KB image feel like two different products: the first scrolls in jankily, the second paints instantly. Reducing image file size is the cheapest performance win available — there is no server-side rewrite, no architecture change, just bytes you didn't need to ship in the first place.
The 4-step reduction pipeline
You don't need an image-optimization service or a build pipeline. The same four steps that run inside every modern image CDN can be done in your browser, one image at a time, in under a minute. Run them in this order, because each step depends on the one before it.
| Step | Action | Typical savings |
|---|---|---|
| 1. Resize to display dimensions | Downscale the bitmap to the largest size the layout actually renders. A 4000×3000 photo served into a 1200×600 slot wastes more than 90% of its pixels. | 60–80% |
| 2. Set quality to ~75–80 | Drop the encoder quality slider to roughly 75–80 for photos. The visual delta is imperceptible at normal viewing distance and the byte savings are dramatic. | 30–50% |
| 3. Convert to WebP | Re-encode the resized, re-quantized bitmap as WebP. Same dimensions, same quality, typically a third of the bytes of the original JPG or PNG. | 25–35% |
| 4. Strip metadata | Remove EXIF, IPTC, XMP, color profiles and authoring comments. A phone photo can carry 50–100 KB of metadata that the browser never renders. | 2–10% |
Stacked together, the four steps routinely cut a 1.2 MB original down to under 150 KB with no visible quality loss at typical web viewing sizes.
Per-format guidance
Different visual jobs want different formats. Pick by content, not by reflex.
- Photos. JPG at quality 75–80, or WebP at an equivalent quality. AVIF goes further still but costs encode time and isn't supported on a small number of legacy devices — fall back to WebP if compatibility matters.
- Logos, icons, and UI graphics. Keep the transparency with PNG or, better, WebP with an alpha channel. SVG is even smaller for line art and scales without raster artifacts — use it whenever the source is vector.
- Illustrations and flat art. WebP or PNG. WebP wins on byte count, PNG wins on ubiquitous support. If you need both, generate a WebP with a PNG fallback via the picture element.
Need to switch a folder of legacy assets from one format to another? Theimage converterhandles batch re-encoding to JPG, PNG, WebP and AVIF in a single pass, with side-by-side previews so you can see the quality trade-off before you commit.
Setting a budget
Optimization without a budget just produces slightly smaller images. Give every category on the page a hard byte ceiling, enforce it in CI, and watch the average page weight collapse. A pragmatic starting budget for a content-led site:
- Hero image: under 100 KB. This is your LCP element. Anything heavier and you're paying for it in Core Web Vitals.
- Gallery thumbnails: under 50 KB each. Multiply by the number of thumbnails above the fold — that's a budget you can defend.
- Open Graph image: under 200 KB. Crawlers and social previews re-fetch this constantly; a tight ceiling keeps link unfurls snappy.
- Total above-the-fold imagery: under 300 KB.If you blow this, no amount of code-splitting will rescue the LCP score.
Run the four-step pipeline, paste the outputs into the budget above, and ship. Faster pages, better Core Web Vitals, happier visitors — and every byte you cut is a byte you don't pay to ship.