Frontend

Cutting a content site's image payload by 70%: browser-side compression wins

By 小码哥_常 · Oct 27, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Browser-side compression eliminates the server resource cost and upload latency that server-side or CDN processing imposes, and it keeps sensitive images off third-party servers. For any site with high upload volume or privacy concerns, this pattern is a concrete way to reclaim double-digit Lighthouse points without extra infrastructure.

Summary

A content site was failing Lighthouse with a Performance score of 38, a 2.4MB banner image, and 6-second first-screen loads. The root cause was uncompressed photos and screenshots hitting the CDN directly; hundreds of articles made server-side or CDN-side recompression impractical.

The fix combined two browser-side approaches. For editor uploads, `browser-image-compression` runs Canvas-based compression client-side before the file goes to the server, cutting a typical 3MB phone JPEG to 300-500KB. For existing images and sensitive screenshots, the engineer used Glazlo, a purely browser-based tool that never uploads files to a server, and supports targeting a specific output size.

Results: Performance went from 38 to 72, LCP from 6.2s to 2.1s, and homepage image payload from 4.8MB to 1.4MB. The article also documents four pitfalls: Canvas JPEG conversion drops PNG transparency, WebP falls back poorly on old Safari, low JPEG quality banding on text-heavy images, and missed compression of responsive image variants.

Takeaways

— The original site had a Performance score of 38, a 2.4MB largest banner image, and a first-screen load over 6 seconds.

— Article images from phones were 4000x3000 JPEGs at 3-5MB; product screenshots were 800KB-1.5MB PNGs.

— Server-side compression with Sharp or ImageMagick spiked CPU to 90% on a 2C4G machine and added upload latency.

— CDN image processing (e.g., OSS or Qiniu) bills per request and won't apply to rich-text img tags without URL parameters.

— Using `browser-image-compression` with maxSizeMB 0.5 and maxWidthOrHeight 1920 on the client compresses 3MB photos to 300-500KB.

— Glazlo performs compression entirely in the browser, confirmed via Network panel, so product screenshots never leave the device.

— After the change, Performance rose to 72, LCP dropped from 6.2s to 2.1s, and total image size fell from 4.8MB to 1.4MB.

— JPEG contributed most of the 70% savings; PNG screenshots only reduced by about 40%.

— Canvas `toBlob()` JPEG output loses alpha channel, turning transparent areas black.

— Safari below 14 doesn't support WebP; about 5% of the site's users were on iOS 13, so a fallback to JPEG is necessary.

— JPEG quality below 50 causes visible artifacts on text and lines; product screenshots should stay at or above quality 75.

— Responsive images using `<picture>` or `srcset` need every size compressed, not just the original.

— For large volumes with frequent uploads, frontend compression is the best first step; online tools suffice for occasional manual fixes.

Conclusions

The biggest win came from phone JPEGs, not engineered assets, which means many sites still have huge untapped savings in user-generated content.

Browser-side compression solves both server load and upload time in one move, making it a better fit for small infrastructure than CDN processing or server-side Sharp.

The transparency pitfall with Canvas toBlob is a reminder that client-side image pipelines need format-aware handling, not just quality tuning.

Glazlo's browser-only processing is notable for privacy-sensitive screenshots, a concern that often gets ignored in favor of convenience.

The 200KB target for WeChat covers shows that matching platform limits isn't the same as optimizing for real loading performance.

Concepts & terms

browser-image-compression

A JavaScript library that compresses images in the browser using Canvas and Web Workers, letting you set max file size and max dimensions before upload.

Largest Contentful Paint (LCP)

A Lighthouse metric measuring when the largest visible content element (like a hero image) fully renders; lower is better for perceived load time.

Canvas toBlob

A browser API that exports a canvas drawing as an image blob; outputting JPEG drops the alpha channel, turning transparency black.

WebP

A modern image format with better compression than JPEG/PNG, but lacking support in Safari versions below 14, so fallback logic is required.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗