Why Client-Side Image Compression Matters for Your Page Weight and LCP

Images are still the fattest thing on most websites. You can ship a lean JavaScript bundle, tree-shake your CSS, defer every non-critical script — and then a single un-optimized hero image undoes all of it. The fix isn't one magic format or one plugin. It's a workflow, and the right place for most of it is the browser.

Where to Compress: Browser or Server?

Both have valid niches. The question is which one owns each case.

Server-side compression is the right call when:

• Images flow through a CMS that needs to produce multiple sizes on publish.
• You have a CDN with image resizing (Cloudflare Images, Imgix, Cloudinary).
• Users upload once and the same asset gets served to millions.
• You need OCR, face detection, or AI processing as part of the pipeline.

Client-side compression is the right call when:

• A user is preparing an asset for a one-time use — email attachment, marketplace listing, portfolio site.
• You want the privacy guarantee: their photo never leaves the device.
• You're building a web app that cares about upload bandwidth for the user.
• You need a fast feedback loop on quality settings without waiting for a round-trip.

The interesting one is the web app case. If your user uploads a 12 MB phone photo and you only need a 400 KB thumbnail, compressing in the browser before upload saves their bandwidth and your ingress costs. It's a free win on both sides.

The Format Rodeo: JPEG vs WebP vs AVIF

The three formats most people are choosing between today have very different personalities.

JPEG

Still the baseline. Every browser, every image viewer, every email client, every printer driver speaks JPEG. It's a 1992 format and it shows — no alpha channel, blocky artifacts at low quality, no animation — but its universality is an asset.

Use JPEG when the consumer is unpredictable. Emails, CMS uploads that might get forwarded, files a user will download and re-share.

WebP

Google's 2010 contribution. 25–35% smaller than JPEG at visually equivalent quality, supports transparency, supports animation, decodes reasonably fast. Every modern browser supports it — Safari finally joined the party years ago — and most image libraries output it natively.

Use WebP when you control the surface. Your own website, your own web app, anywhere you can serve a <picture> with a JPEG fallback if needed.

AVIF

Based on AV1 video codec. Typically 30–50% smaller than JPEG for comparable quality, supports HDR, wide color gamut, film grain. The catch: encoding is slow (much slower than WebP), decode is fast but not as fast, and older environments don't support it.

Use AVIF for your highest-traffic hero images where the download savings outweigh the CPU cost of encoding once. Not every image needs it.

The Impact on Page Weight and LCP

Largest Contentful Paint (LCP) is almost always an image on content-heavy pages. A couple of numbers from typical blog layouts:

• A 1920×1080 JPEG at quality 85: ~350 KB
• The same image as WebP at quality 80: ~210 KB
• The same image as AVIF at quality 65: ~140 KB

On a 4G connection (real-world median, not the spec sheet), that's a difference of about 0.8 seconds to first paint. That's the difference between a Lighthouse score of 72 and 94. It's the difference between a bounce and a read.

Multiply that across six images above the fold and the gap is brutal. Compression isn't optional if you care about Core Web Vitals.

A Realistic Workflow

Here's the pipeline I'd use for a fresh project today:

1. Source assets stay lossless — original RAW, PNG, or high-quality JPEG — in a separate directory.
2. Master exports go to WebP at quality 80 as the default. This covers 95% of use cases.
3. Hero and OG images get an additional AVIF export at quality 60–65.
4. Use <picture> with AVIF first, WebP second, JPEG fallback last.
5. Set width and height on every image tag. CLS costs you more than compression saves you.
6. Lazy-load everything below the fold with loading="lazy".

For one-off compression — resizing a screenshot before pasting it into a doc, flattening a PNG to a web-friendly size — the browser is faster than opening Photoshop.

Gotchas That Bite

• Double compression. Compressing a JPEG that's already been compressed to WebP gives worse results than compressing the original. Always start from the highest-quality source available.
• Transparency fallbacks. A PNG with an alpha channel converted to JPEG will get a white background, which is rarely what you want. Use WebP or AVIF, which both support alpha.
• EXIF stripping. Browser compression often strips EXIF metadata — usually a good thing for privacy, but sometimes you want orientation or color profile preserved. Check your tool's settings.
• Quality slider drift. "Quality 80" in one encoder is not "quality 80" in another. A WebP at 80 is perceptually closer to a JPEG at 90. Benchmark with your own eyes, not the number.

What Privacy Has to Do With It

The same principle from PDFs applies here: a photo is a personal artifact. A selfie for a profile upload, a document scan, a receipt with a credit card number visible — none of these should have to transit a third party's server just to become 300 KB smaller.

Compressing in the browser keeps the original bytes on the device. You get the compressed output, you upload that to whichever service you trust, and the original never travels. For images that contain anything identifiable, that's the privacy difference that matters.

The Bottom Line

WebP as your default, AVIF for hero images, JPEG as a fallback for mystery consumers. Compress in the browser before upload when bandwidth or privacy is at stake, compress on the server or CDN when you need to fan out many sizes. Set width and height on every image. Watch your LCP score climb.

The page-weight wins are bigger than any JavaScript optimization you'll make this quarter.