DEV Community: 吴美良

"How I Built a Browser Image Compressor That Handles 30 Images at Once"

吴美良 — Sun, 16 Aug 2026 03:18:13 +0000

Most image compressors do the actual work on a server. Mine runs entirely in the browser — 30 images at a time, re-encoded with the Canvas API, on your device. Here's the architecture that makes that possible, and the bugs that nearly broke it.

I built CompressFast to scratch my own itch, and the constraint was non-negotiable: files must never leave the device. That single decision shaped everything downstream.

The architecture: keep the heavy work off the main thread

Re-encoding a 4000×4000 photo is CPU-heavy. If you do it on the main thread, the UI freezes and the browser flags "page unresponsive". So the core is a Web Worker that owns the entire compression pipeline:

Main thread (React)  ←→  Web Worker
   upload / UI              └─ decode → transform → encode → transfer

The main thread handles selection, previews, and state. The worker does:

Decode — createImageBitmap for standard formats, a dedicated path for HEIC
Transform — resize, rotate, flip (applied before encoding, never after)
Encode — canvas.toBlob('image/webp', quality) (and JPEG/PNG/AVIF)
Transfer — the compressed Blob is handed back via postMessage

The key detail: use transferables (ArrayBuffer, not structured-clone of a Blob) wherever you can. For a 30-image batch, that's the difference between instant and a half-second of GC pressure per file.

Auto format detection — the "smart" part

Not every image should be compressed the same way. Photos want lossy WebP; screenshots and logos want lossless PNG. So the worker classifies each file and picks a strategy:

JPEG/photo → WebP, quality 75–82% (the visual-equivalence sweet spot)
PNG/screenshot → lossless (oxipng-style), 20–60% smaller with zero pixel change
GIF → animated WebP (60–80% smaller)
HEIC (iPhone) → decoded first, then treated as a photo

This is why batch mode doesn't need per-file settings — the user drops a folder, and each image gets the right treatment automatically.

Three bugs that took way too long to find

If you're building anything with Web Workers, learn from my scars:

1. A worker can't reference window — even transitively.
I pulled in a library whose module top-level touched window. In the worker context, Webpack's chunk threw ReferenceError: window is not defined, and every compression hung on the spinner with no error in the console. Fix: audit every worker import — grep -r "window\|document" node_modules/<lib> — and keep browser-only libraries on the main thread, passing data to the worker afterward.

2. Integer truncation broke image scaling.
My fast resize path used Math.round(1/ratio) as a pixel step. For large images that truncation pushed the source coordinate past the row width, and the image came out split horizontally with black mosaic at the bottom. Fix: exact floating-point ratios plus a Math.min() bounds guard on every manual pixel loop.

3. An async handler corrupted processing order.
I made the worker's message handler await a transform after encoding. Async handlers don't preserve order — the rotation state got out of sync with the blob. Fix: keep worker message handlers synchronous. Apply transforms at download time, not inside the handler.

Bonus: Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy headers will silently block worker scripts in production (they worked fine locally). Test any security header change against a real deployment.

Scaling up to 30 files without melting the tab

Batch mode adds two more concerns:

Throttle re-renders. Resize/compare previews fire on every pointer move. A requestAnimationFrame throttle keeps it at 60fps instead of 300 wasted renders per second.
Memory. Blobs stay in memory until download. Packing the final results into a single ZIP (client-side, jszip) keeps 30 "Download" buttons from becoming 30 separate saves.

The result

A 1920×1080 screenshot goes 2.1 MB → 186 KB WebP (91%) → 102 KB AVIF (95%), all computed on-device with no server round-trip. Batch a whole folder, get one ZIP back.

The whole stack — Next.js, a Web Worker, Canvas, and a ZIP library — costs $0/month to run, because there's no compression server to pay for. That's the real payoff of going browser-side: your users' machines do the work you'd otherwise pay for, and their files never leave their hands.

If you want to try it: compressfast.site — free, 30 files per batch, no account.

What's the worst Web Worker bug you've hit? I'd love to add it to the list.

"Image Optimization: The Complete 2026 Checklist for Faster Websites"

吴美良 — Sat, 15 Aug 2026 04:00:28 +0000

Images are the single biggest performance lever on almost every website. They average over 1MB of every 2MB page — and cutting them down is the fastest way to improve Core Web Vitals and SEO rankings.

I've spent the past few months obsessing over image compression (I built CompressFast to scratch my own itch). Here's the complete, ordered checklist I use on every project.

1. Resize first — it's the single biggest win

A 6000×4000 photo served to a 1200px-wide card is pure waste. Before anything else, resize to the largest size your layout actually displays.

Resizing alone cut my test image from 4.7MB to 1.1MB — a 77% reduction with zero quality change.

2. Pick the right format per image type

This is the mistake I see most often — using one format for everything.

Photos → WebP (30–50% smaller than JPEG) or AVIF (another 30% smaller)
Screenshots / UI → PNG lossless, or WebP lossless
Logos / icons → SVG (vector, tiny, infinitely scalable)
Animated GIFs → animated WebP (60–80% smaller)

3. Compress, don't just convert

Converting PNG → JPEG saves space, but then compressing that JPEG saves even more. Always run a compression pass after conversion. Quality 75–82% is the sweet spot for photos — visually indistinguishable from 100%.

4. Strip metadata

EXIF, GPS coordinates, camera model, editing software tags — all useless for web display and can be 10–30KB per file. Strip it.

5. Use lossless compression for text-heavy images

For screenshots, logos, and anything with sharp edges, lossless tools (like oxipng for PNG) shrink files 20–60% without changing a single pixel. Never run lossy compression on text — it creates ugly artifacts.

6. Lazy-load off-screen images

loading="lazy" (or loading="lazy" via next/image) stops below-the-fold images from blocking your LCP. Combine with width/height attributes to prevent layout shift (CLS).

7. Serve modern formats with fallbacks

Use the <picture> element to serve WebP/AVIF to modern browsers and JPEG as a fallback:

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="...">
</picture>

Real numbers from my testing

A single 1920×1080 screenshot, compressed:

Step	File size	Reduction
Original PNG	2.1 MB	—
Resize + WebP 75%	186 KB	91%
Resize + AVIF 50%	102 KB	95%

That 91–95% saving is the difference between a 4-second and a sub-1-second page load.

The privacy point most guides skip

Most online compressors upload your files to their server to do the compression. That means your (or your users') images are sitting on someone else's infrastructure. If you're compressing product shots, client work, or anything sensitive, use a tool that runs entirely in the browser — the file never leaves the device.

I built CompressFast exactly for this: browser-side compression, no upload, no account, batch up to 30 files, free. It also auto-detects the right format per image so you don't have to think about steps 2–5.

What's the biggest image optimization win you've found? Drop it in the comments.

webdev #performance #images

# I Built a Smart Image Compressor That Auto-Detects the Best Format

吴美良 — Tue, 11 Aug 2026 04:54:48 +0000

We've all been there — staring at a quality slider, wondering if 70% is too low or 90% is too high. Should this PNG stay as PNG? Should I convert to WebP? What even is lossless?

I got tired of guessing, so I built Smart Compress into CompressFast. Drop any image, it figures out the optimal format and quality automatically.

How It Works

The smart analyzer looks at three things:

1. Format

Each image type gets a different strategy:

Input	Smart Decision	Why
PNG (small, likely logo/icon)	Lossless PNG via oxipng	Pixel-perfect, 20-60% smaller
PNG (large, likely photo)	Convert to WebP 75%	70%+ savings, still looks great
JPEG photo	WebP 75%	25-35% smaller, same quality
JPEG huge (>4MP)	WebP 70% + resize to 1920px	90%+ savings for web
GIF	Animated WebP	60-80% smaller, animation preserved
HEIC	WebP	Universal compatibility
SVG	Keep as-is	Vector doesn't need compression

2. Dimensions

If an image is over 2 megapixels, Smart suggests resizing to 1920px wide. Most websites display images at 1200px max — those extra pixels are just wasted bytes.

3. File Size

Larger files get more aggressive compression. A 10MB photo gets different treatment than a 200KB icon.

The Code

The analysis engine is dead simple — just a function that takes file metadata and returns optimal settings:

function analyzeFile(file: FileMeta): SmartRecommendation {
  const pixels = (file.width && file.height) ? file.width * file.height : 0
  const isLarge = pixels > 2_000_000 || file.originalSize > 1_000_000
  const isHuge = pixels > 4_000_000 || file.originalSize > 5_000_000

  if (file.type === 'image/png') {
    if (isHuge) {
      return {
        quality: 75, outputFormat: 'webp',
        resizeWidth: pixels > 2_000_000 ? 1920 : 0,
        reason: 'Large PNG → WebP (photo/screenshot, 70%+ savings)'
      }
    }
    return {
      quality: 100, outputFormat: 'png', lossless: true,
      reason: 'PNG lossless (oxipng — pixel-perfect, 20-60% smaller)'
    }
  }

  if (file.type === 'image/jpeg') {
    return {
      quality: 75, outputFormat: 'webp',
      reason: 'JPEG → WebP 75% (25-35% smaller, same quality)'
    }
  }
  // ... more format handlers
}

The key insight: most images don't need custom settings. A JPEG photo is a JPEG photo. The heuristics are simple because the use cases are predictable.

The UI

Instead of hiding this behind a settings panel, I put it front and center — a purple "Smart" button right next to the existing Max / Balanced / Best presets:

┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────────┐
│   📦     │ │   ⚖️     │ │   ✨     │ │   🧠 Smart   │
│   Max    │ │ Balanced │ │   Best   │ │   Auto       │
└──────────┘ └──────────┘ └──────────┘ └──────────────┘

Clicking Smart shows a summary panel explaining exactly what it chose and why. No black box — users can see the reasoning and override if they want.

Privacy: Everything Runs Locally

Like everything in CompressFast, the Smart analysis runs entirely in the browser. The file metadata (format, dimensions, size) is read locally — no data ever touches a server. You can unplug your internet after the page loads and Smart Compress still works.

This is the whole philosophy of the project: compression is a solved problem, but most online tools upload your files to a server first. We do everything client-side with Web Workers and WebAssembly.

Try It

Smart Compress is live now at compressfast.site. Free, no signup, no upload. Drop an image and click the purple Smart button.

If you're curious about the full tech stack (Next.js 14, Zustand, oxipng WASM, Creem payments — all for $0/month), I wrote about it here.

I Built a CLI Image Compressor — 73% Smaller in 0.1s

吴美良 — Mon, 03 Aug 2026 15:45:39 +0000

I just shipped compressfast — a command-line image compressor that runs entirely on your machine. No uploads, no API
keys, no limits.

One command:
npx compressfast photo.jpg --quality 80

What it does:

Compress JPEG, PNG, WebP, AVIF
Batch process entire folders
Resize while compressing
Watch mode for automatic processing
All local — files never leave your machine

Real results:
141.6 KB → 37.4 KB (-73.6%)
Time: 0.1s

Built with: Sharp (libvips) — the fastest image processing library for Node.js.

npm: npmjs.com/package/compressfast
GitHub: github.com/WML123270/compressfast

Try it: npx compressfast --help
🔗 Try it: https://compressfast.site — free, no upload, 8 formats supported.

# I Built a $0/month SaaS — Full Stack Breakdown

吴美良 — Sun, 02 Aug 2026 03:49:15 +0000

3,700+ images compressed. 178 users. 1 Pro sale. Total monthly hosting bill: $0.00.

I built CompressFast — a privacy-first image compressor that runs entirely in the browser. No server-side processing. No uploads. No database costs.

Here's exactly how the stack works, why it costs nothing, and what I'd change.

The $0 Stack

Layer	Service	Cost
Hosting	Vercel (Hobby)	$0
DNS	Cloudflare	$0
Database	Upstash Redis (free tier)	$0
Email	Resend (100/day free)	$0
Payments	Creem (5% per sale)	$0 fixed
Analytics	Vercel Analytics (free tier)	$0
Domain	compressfast.site	~$3/yr
Total monthly burn		$0.00

The only real cost is the domain renewal. Everything else rides on generous free tiers.

Architecture: Why There's No Server Bill

The key insight: image compression doesn't need a server.

User's browser
    │
    ├─ Page loads (static HTML from Vercel CDN)
    ├─ User drops 30 images
    ├─ Web Workers spawn → Canvas API compresses locally
    ├─ Blob URLs generated → ZIP created client-side
    └─ Download starts instantly

No upload. No backend processing queue. No temporary storage. The browser does everything.

The only backend code is licensing

/api/create-license  → Generate activation code → Store in Redis
/api/verify-license  → Check code validity → Track device fingerprint
/api/creem           → Webhook: payment → issue license → email via Resend
/api/resend-license  → "Forgot your code?" → email it back

Three tiny API routes. Redis stores license keys + device IDs + stats. That's it.

Multi-Worker Pool (0 Cost, 4x Speed)

Instead of spawning/destroying workers per task, I keep a pool alive:

const POOL_SIZE = Math.min(4, navigator.hardwareConcurrency || 2)
const workers: Worker[] = []

for (let i = 0; i < POOL_SIZE; i++) {
  const w = new Worker(new URL('./worker.ts', import.meta.url))
  workers.push(w)
}

// Round-robin dispatch — no load balancer needed
function dispatch(task: CompressTask): Promise<CompressResult> {
  const worker = workers[taskIndex++ % POOL_SIZE]
  return new Promise(resolve => {
    worker.onmessage = (e) => resolve(e.data)
    worker.postMessage(task.buffer, [task.buffer]) // transferable = zero-copy
  })
}

postMessage(buffer, [buffer]) with transferable objects means zero-copy handoff. The buffer is literally moved, not cloned. 2x faster for large images.

The Compression Pipeline (All Client-Side)

┌─────────────────────────────────────┐
│         Web Worker Pipeline          │
├─────────────────────────────────────┤
│ 1. decodeImage()                    │
│    createImageBitmap → OffscreenCanvas
│                                     │
│ 2. resize?                          │
│    calcResizeDims + multi-step scale │
│                                     │
│ 3. transform? (rotation + flip)     │
│    Canvas matrix transform           │
│                                     │
│ 4. watermark? (text or image)       │
│    Overlay render                    │
│                                     │
│ 5. encode()                         │
│    Canvas API: JPEG/WebP/PNG        │
│    WASM: AVIF (@jsquash), PNG (oxipng) │
│                                     │
│ 6. postMessage back to main thread  │
└─────────────────────────────────────┘

Full pipeline runs in 50-200ms per image depending on size and format.

License Keys Instead of User Accounts

I did NOT want to build auth. So the Pro model is dead simple:

User pays Creem ($24.99 lifetime)
    → Webhook fires
    → Server: generate "XXXX-XXXX-XXXX" code
    → Store in Redis: code → {email, devices[], created_at}
    → Resend: email with activation code
    → User enters code in app
    → Verified, device fingerprint registered
    → Max 5 devices per code

No passwords. No sessions. No user table. No GDPR headaches. The activation code IS the account.

SEO Landing Pages (11 Pages, $0 Hosting)

11 SEO tool pages pre-rendered at build time. Each page targets a specific keyword:

Page	Target
/compress-png	"compress PNG online"
/compress-jpeg	"compress JPEG online"
/compress-webp	"WebP compressor"
/compress-svg	"SVG optimizer"
/remove-metadata	"remove EXIF data"
/vs-tinypng	"TinyPNG alternative"
...	(6 more)

All static HTML. Vercel CDN handles them globally for free. Google is slowly indexing them.

Real Numbers (After 1 Month)

Metric	Value
Total PV	850
Total UV	178
Images compressed	3,716
Pro sales	1 ($24.99)
Monthly cost	$0.00

Not retiring on it. But it proves the model works: $0 burn rate means every sale is pure profit.

What I'd Do Differently

SEO pages earlier. They're low effort, high leverage. Should have been day 1.
Start Twitter sooner. Build-in-public compounds. I started late.
Don't spend 3 hours debugging Worker window access. It's always the same bug.

The Stack in One Line

Next.js + Web Workers + Canvas API + Upstash Redis + Creem + Vercel = $0/month SaaS.

No servers. No uploads. No excuses.

compressfast.site · GitHub

Tags: #webdev #javascript #nextjs #saas #buildinpublic

I Built a $0/month SaaS — Full Stack Breakdown

吴美良 — Tue, 28 Jul 2026 03:10:18 +0000

How CompressFast runs on zero infrastructure cost while handling thousands of image compressions.

The $0 Stack

┌──────────────────┬──────────────────────────┬───────────────────┐
│ Layer │ Technology │ Cost │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Frontend │ Next.js 14 (App Router) │ $0 (Vercel Hobby) │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Image Processing │ Canvas API + Web Workers │ $0 (client-side) │
├──────────────────┼──────────────────────────┼───────────────────┤
│ State Management │ Zustand │ $0 │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Compression WASM │ @jsquash/oxipng + avif │ $0 │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Payments │ Creem (one-time) │ % of sale only │
├──────────────────┼──────────────────────────┼───────────────────┤
│ License DB │ Vercel KV (Redis) │ $0 (free tier) │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Analytics │ Custom API + Vercel KV │ $0 │
├──────────────────┼──────────────────────────┼───────────────────┤
│ Total │ │ $0/month │
└──────────────────┴──────────────────────────┴───────────────────┘

Why Client-Side?

The key insight: image compression is CPU-bound, not I/O-bound. Modern browsers have excellent Canvas APIs. You don't
need a server to resize or re-encode an image.

No upload bandwidth — files stay on device
Instant processing — zero network round-trip
Privacy-first — a real differentiator
Infinite scale — each user brings their own CPU

The Compression Pipeline

User drops file
↓
Main thread: detect format
↓
Web Worker pool (4 workers, round-robin):
- SVG: regex-based text optimization
- HEIC: main-thread decode → Worker
- Raster: decode → resize → quantize → encode
Optional: watermark, rotation, flip
Optional: target-KB iterative search
Optional: lossless oxipng (WASM)
Optional: AVIF (WASM)
Optional: EXIF preservation
↓
Blob ready → download or ZIP (JSZip)

Key Decisions

Web Workers, not main thread. Offloading to Workers keeps UI responsive. 4 workers in round-robin — handles 20 files
without freezing.

WASM for PNG/AVIF. Canvas does JPEG/WebP natively, but lossless PNG needs oxipng (Rust→WASM) and AVIF needs
@jsquash/avif. Both load on demand.

Zustand over Redux. For a single-page tool, Zustand wins. Entire store is ~800 lines with all compression logic.

One-time purchase, not subscription. Creem handles $24.99 lifetime Pro. No recurring billing headaches.

Numbers After 2 Weeks

744 page views, 123 unique visitors
2,847 images compressed
1 Pro sale ($24.99)
Twitter: ~5 followers

What I'd Do Differently

SEO tool pages earlier — 11 pages drive long-tail traffic
Demo showcase from day 1 — visitors need to see results first
Mobile-first testing — most users on mobile

Try It

compressfast.site (global)
jisuyatu.com (China)

This is post #4 in my CompressFast build-in-public series. Previous: [privacy-first approach], [AVIF vs WebP
benchmarks], [why your compressor uploads files].

# Why Your Image Compressor Is Uploading Your Files (And How to Stop It)

吴美良 — Mon, 27 Jul 2026 02:01:39 +0000

AVIF vs WebP vs JPEG: Real Benchmarks (2026)

吴美良 — Sun, 26 Jul 2026 03:19:48 +0000

I compressed 100 photos through 3 formats. Here's the actual data.

A 2MB JPEG photo. Convert it to WebP — now it's 480KB. Convert it to AVIF — now it's 310KB.

Same visual quality. Three different file sizes.

I've spent the last 2 weeks building an image compression tool, so I've seen thousands of these comparisons. Here's what the numbers actually say, and what it means for your website.

The Setup

I took 50 real-world photos and 50 screenshots/design assets — not synthetic test images, but actual files people would upload:

Photos: vacation shots (JPEG, 2-8MB), product photos, portrait selfies
Graphics: PNG screenshots (1-4MB), logos, UI mockups, illustrations
Source sizes: 500KB to 12MB, average ~3.2MB

Each image was compressed through JPEG (quality 85%), WebP (quality 80%), and AVIF (quality 65%) — settings that produce visually identical results on a 2x retina display.

The Numbers

Format	Avg Compressed Size	Reduction vs Original	Reduction vs JPEG	Browser Support
Original	3.2 MB	—	—	100%
JPEG (q85)	820 KB	74.4%	—	100%
WebP (q80)	480 KB	85.0%	41.5% smaller than JPEG	96.8%
AVIF (q65)	310 KB	90.3%	62.2% smaller than JPEG	93.1%

The headline: WebP halves your JPEG size. AVIF halves WebP again.

Photo Results (JPEG source, 50 images)

For photographs — the most common use case — here's what happened:

Format	Avg Size	Best Case	Worst Case
JPEG q85	820 KB	180 KB	3.1 MB
WebP q80	480 KB	95 KB	1.8 MB
AVIF q65	310 KB	60 KB	1.2 MB

What this means: On an average product page with 6 photos:

JPEG: 6 × 820KB = 4.9 MB
WebP: 6 × 480KB = 2.9 MB (saves 2 MB)
AVIF: 6 × 310KB = 1.9 MB (saves 3 MB)

On a 4G connection (10 Mbps), that's the difference between 4 seconds and 1.5 seconds to load all images. On a product page, that's the difference between a bounce and a sale.

Screenshot/Graphics Results (PNG source, 50 images)

PNGs are a different story. Lossy WebP and AVIF can crush PNGs — but only if you're OK losing pixel-perfect accuracy.

Format	Avg Size	Notes
Original PNG	1.4 MB	Lossless, pixel-perfect
PNG (lossless compress)	640 KB	Still lossless, 54% smaller
WebP q80	180 KB	Visually identical on screen, not pixel-perfect
AVIF q65	120 KB	Same visual quality as WebP

For screenshots with text, the lossless PNG compression is the safer choice — at 640KB it's still 54% smaller than the original, and every pixel is correct. For illustrations and UI mockups without fine text, WebP at q80 is visually identical and 7x smaller than the original PNG.

The Catch: Encoding Speed

There's a reason every CDN doesn't just serve AVIF by default:

Format	1 Image	30 Images (Batch)
JPEG	0.3s	9s
WebP	0.8s	24s
AVIF	2.5s	75s

AVIF is slow to encode. About 3x slower than WebP, 8x slower than JPEG. This matters if you're compressing on-the-fly (user uploads) vs at build time (static site generator).

For a static site? Use AVIF at build time, the slow encode doesn't matter.
For user-generated content? WebP is the sweet spot — fast enough, small enough.

Real-World Recommendations

For Blog / Content Site

→ WebP, quality 80%
Best balance of size, speed, and compatibility. Every modern browser supports it. Your 5MB hero image becomes 700KB. Done.

For E-Commerce / Product Pages

→ WebP for now, AVIF as <picture> fallback
Product images matter for conversion. Serve AVIF to 93% of browsers, fall back to WebP for the rest. The <picture> element handles this automatically:

<picture>
  <source srcset="product.avif" type="image/avif">
  <source srcset="product.webp" type="image/webp">
  <img src="product.jpg" alt="Product photo">
</picture>

For User-Generated Content

→ WebP, quality 80%
Users upload JPEGs. You convert to WebP. Fast encode, small output. 30 images process in ~24 seconds — acceptable for a background job.

For Screenshots / Technical Docs

→ Lossless PNG compression
Don't use lossy formats for screenshots with text. The compression artifacts around letters look unprofessional. Lossless PNG compression (oxipng, pngquant) gives you 20-60% savings without touching a single pixel.

For "I just want the smallest file"

→ AVIF, quality 60-65%
If file size is everything (email attachments, messaging apps, low-bandwidth scenarios), AVIF wins. A 4MB vacation photo becomes 250KB. Just warn users it'll take a few seconds to encode.

The Tool I Used

I built CompressFast to do these comparisons quickly — drag in images, switch formats, see before/after sizes instantly. Everything runs in the browser (no upload), so you can test with sensitive files too.

But you can also do this with:

Squoosh (squoosh.app) — great for one-at-a-time comparisons
ImageMagick (CLI) — magick input.jpg -quality 80 output.webp
sharp (Node.js) — the fastest server-side option
Cloudinary/imgix — if you want a managed solution

Bottom Line

If you're still serving JPEGs in 2026, you're leaving 40-60% of your image bytes on the table. WebP is safe, fast, and universally supported. AVIF is the next step when you're ready.

The format you pick matters less than actually picking one and compressing your images. Most sites I audit have 2-4MB hero images that could be 300KB. That's not a format problem — that's a "nobody compressed this" problem.

Start with WebP at 80%. You'll cut your image payload in half. Then worry about AVIF.

Have you switched to WebP or AVIF? What's holding you back?

How I Built a Privacy-First Image Compressor with Next.js + Web Worker

吴美良 — Thu, 23 Jul 2026 03:31:06 +0000

How I Built a Privacy-First Image Compressor with Next.js + Web Workers

Zero uploads. 100% browser-side. Here's the architecture behind CompressFast.

I recently shipped CompressFast — a browser-based image compression tool that processes everything locally. No files ever touch a server. Here's how I built it, what went wrong, and what I'd do differently.

The Stack

Layer	Choice	Why
Framework	Next.js 14 (App Router)	SSG for landing pages, API routes for licensing
State	Zustand	Lightweight, no boilerplate, works great with Workers
Compression	Web Worker + OffscreenCanvas	Non-blocking UI, multi-threaded processing
AVIF Encoder	`@jsquash/avif` (WASM)	Browser Canvas API can't encode AVIF
Lossless PNG	`@jsquash/oxipng` (WASM)	True lossless optimization
Styling	TailwindCSS	Productivity, dark mode via `class` strategy
i18n	Custom 200+ key dictionary	Lightweight, no runtime overhead
Payments	Creem + Upstash Redis	License key model, no user accounts

Architecture: The Compression Pipeline

The core is a Web Worker that handles everything heavy:

Main Thread                    Web Worker
    │                              │
    ├─ User drops 30 images        │
    ├─ postMessage(buffer, opts) ──►
    │                          decodeImage()
    │                          (createImageBitmap → OffscreenCanvas)
    │                              │
    │                          resize? (calcResizeDims + high-quality scaling)
    │                              │
    │                          applyTransform? (rotation + flip via canvas matrix)
    │                              │
    │                          applyWatermark? (text or image overlay)
    │                              │
    │                          compressRegular() or compressToTarget()
    │                              │
    │                     ┌───────┴────────┐
    │                     │                │
    │                encodeImage()    encodeAvif()
    │                (canvas API)     (@jsquash WASM)
    │                     │                │
    │                     └───────┬────────┘
    │                             │
    │              EXIF injection? (JPEG only, optional)
    │                             │
    │   ◄── postMessage({ type:'done', buffer, size })
    │
    ├─ Create Blob → saveAs() download

Speed Tiers

Instead of a single quality slider, I built a speed-based adaptive pipeline:

// Speed → compression level mapping
function sp2level(s: number): number {
  if (s <= 2) return 4   // Best: 8 quality tiers, 4 scale steps
  if (s <= 5) return 2   // Balanced: 4 tiers, 2 scale steps
  return 1               // Fast: 2 tiers, no scaling
}

// For large images, pre-scale before compression at low speed tiers
function getPreScale(speed: number, pxCount: number): number {
  if (pxCount > 2_000_000) return 0.8   // >2MP: scale to 80%
  if (pxCount > 1_000_000) return 0.6   // >1MP: scale to 60%
  return 1
}

This means "Fast" mode skips expensive operations — it pre-scales large images and tries fewer quality levels. "Best" mode does 8 quality iterations with 4 scale steps, finding the optimal balance.

Target KB Mode: Binary Search Over Quality

The trickiest feature was "compress to exactly N KB." It's essentially an optimization problem:

async function compressToTarget(img, targetBytes, speed, mime) {
  const qualities = getKBQualityLevels(speed)  // [95,90,80,70,50,30,15,5]
  const scales = getKBScales(speed)            // [1, 0.75, 0.5, 0.25]

  let bestBuf, bestSize = Infinity

  for (const scale of scales) {
    const src = scale === 1 ? img : scaleImageFast(img, scale)
    for (const q of qualities) {
      const buf = await encodeImage(src, mime, q)
      // Keep whichever is closest to target size
      if (Math.abs(buf.size - targetBytes) < Math.abs(bestSize - targetBytes)) {
        bestBuf = buf; bestSize = buf.size
      }
      // Within 10% tolerance → good enough
      if (buf.size <= targetBytes * 1.1 && buf.size >= targetBytes * 0.9) break
    }
    if (bestSize <= targetBytes * 1.15) break
  }
  return { buf: bestBuf, size: bestSize }
}

The HEIC Problem

HEIC (iPhone photos) was a headache. The heic2any library requires window — it crashes in Workers. Solution: decode HEIC on the main thread, then pass the decoded PNG buffer to the Worker:

// Main thread only
async function decodeHEICOnMain(buffer: ArrayBuffer): Promise<ArrayBuffer> {
  const heic2any = (await import('heic2any')).default
  const blob = new Blob([buffer], { type: 'image/heic' })
  const result = await heic2any({ blob, toType: 'image/png' })
  const pngBlob = Array.isArray(result) ? result[0] : result
  return pngBlob.arrayBuffer()
}

This was one of those bugs that took 2 hours to debug and 5 lines to fix. Classic.

Pro Features Without a Database

I didn't want to build auth. So I used a license key model:

User pays on Creem → webhook fires
Server generates XXXX-XXXX-XXXX code → stores in Upstash Redis
Email with code sent via Resend
User enters code → verified against Redis, device fingerprint tracked
Max 5 devices per code

No passwords. No sessions. No user tables. The activation code IS the account.

AVIF: The Secret Weapon

AVIF encoding isn't available via Canvas API, so I use @jsquash/avif — a WASM encoder compiled from libavif. The results are staggering:

Same visual quality:
  JPEG: 100KB
  WebP:  70KB  
  AVIF:  50KB ← 50% smaller than JPEG

I gated AVIF behind Pro — it's a clear value proposition. Users can SEE the size difference in the comparison slider.

What I Learned

Workers can't access window. Seems obvious. Still tripped me up 3 times.
Canvas .convertToBlob('image/avif') doesn't exist. You need a WASM encoder.
OffscreenCanvas is amazing but createImageBitmap with resizeQuality: 'high' gives better scaling than manual pixel manipulation.
i18n doesn't need a library. A 200-key dictionary with useContext is simpler and faster.
License keys > user accounts for simple tools. No password resets, no GDPR headaches.

Try It

compressfast.site — free for 30 images/batch, Pro for $24.99 lifetime.

Source code: github.com/WML123270/compressfast — MIT licensed, contributions welcome!

Happy to answer questions in the comments!

Tags: #nextjs #webdev #javascript #tutorial #architecture

WebP vs AVIF vs PNG vs JPEG: A Practical Format Guide for 2026

吴美良 — Wed, 22 Jul 2026 15:35:28 +0000

After spending 2 years building an image compression tool, here's my no-nonsense format guide.

## The Rule

| If it's... | Use... |
|---|---|
| Logo, icon, screenshot | PNG |
| Photo, everyday image | WebP |
| Smallest possible file | AVIF |
| Maximum compatibility | JPEG |

## Why?

PNG — Lossless. Keeps text and sharp edges crisp. Supports transparency. But files are large for photos.

JPEG — Works literally everywhere since 1992. Good compression for photos. No transparency support. At 80-85%
quality, the visual difference from 100% is invisible but the file is half the size.

WebP — The sweet spot. 25-35% smaller than JPEG with same quality. Supports both lossy and lossless. Supports
transparency. Every modern browser supports it now (97%+ global coverage). For most websites, this is the right
answer.

AVIF — The next-gen format. 50% smaller than JPEG, 30% smaller than WebP. Supports HDR, 12-bit color, and both
lossy/lossless. The catch: not supported on older devices (iOS 15 and below). Use it with a <picture> fallback.

## Real Numbers

I ran the same photo through all four formats at comparable quality:

JPEG (90%): 842 KB
PNG: 3,241 KB
WebP (90%): 547 KB
AVIF (90%): 382 KB

WebP cut the JPEG size by 35%. AVIF cut it by 55%.

## What I Recommend
I built CompressFast (https://compressfast.site) — a free browser-based image compressor that handles all these
formats. No uploads, no servers, everything runs locally.

# PNG vs WebP vs AVIF: The Ultimate Image Format Guide for 2026

吴美良 — Fri, 17 Jul 2026 04:04:07 +0000

Stop guessing which format to use. Here's the data, the tradeoffs, and exactly when to pick each one.

The Numbers That Matter

Format	Year	Compression	Transparency	Animation	Browser Support
JPEG	1992	Lossy	❌	❌	100%
PNG	1996	Lossless	✅	❌ (APNG exists)	100%
GIF	1987	Lossless (256 colors)	✅ (1-bit)	✅	100%
WebP	2010	Both	✅	✅	96.5%
AVIF	2019	Both	✅	✅	93.5%

But browser support numbers don't tell the real story. Here's what actually matters.

JPEG: Still the Fallback King

JPEG has been around since 1992. Every device, every browser, every piece of software understands it. And for photos — especially at 65-85% quality — it's still hard to beat.

When to use JPEG:

You need guaranteed compatibility everywhere
Email attachments
Uploading to platforms that don't accept modern formats
Photo-heavy pages where you use <picture> with WebP/AVIF + JPEG fallback

When not to use JPEG:

Logos, icons, screenshots (use PNG)
Anything with text or sharp edges (JPEG artifacts ruin text)
When file size is critical (WebP is 25-35% smaller at same quality)

Real-world test: A 1920×1080 photo at 70% JPEG = 142KB. Same image at 70% WebP = 98KB. Same image at 70% AVIF = 72KB. That's a genuine 49% saving just by switching formats.

PNG: The Trusted Workhorse (That People Misuse)

PNG is lossless — every pixel is preserved. This is great for:

Screenshots
Logos and icons
Images with text
Anything with sharp edges or flat colors

This is terrible for:

Photographs (massive file sizes)
Any image where minor quality loss is acceptable

The PNG trap: Most people save screenshots as PNG and upload them to websites. A 1080p screenshot in PNG might be 800KB. The same screenshot in lossy WebP at 90% quality is 120KB — and no human can tell the difference.

When you should actually use PNG:

You need pixel-perfect reproduction
Transparency is required and WebP/AVIF aren't options
You're sharing original assets for editing

WebP: The Sweet Spot (2026 Edition)

WebP is now 15 years old and supported by 96.5% of browsers globally (Chrome, Firefox, Safari 14+, Edge). The remaining 3.5% are mostly legacy devices and niche browsers.

Why WebP wins for most use cases:

25-35% smaller than JPEG at the same perceived quality
Supports lossless AND lossy — one format for everything
Alpha transparency — JPEG can't do this
Animation — animated WebP files are 60-80% smaller than GIFs
Zero compatibility issues in 2026 for real-world web traffic

The only catch: Some desktop apps (older Photoshop versions, legacy image viewers) don't open WebP files. This is why format conversion tools exist — convert to WebP for the web, convert back to PNG/JPEG for editing.

AVIF: The New Challenger

AVIF (AV1 Image File Format) is built on the AV1 video codec. It delivers 50% smaller files than JPEG at the same quality — the best compression ratio of any mainstream image format.

AVIF advantages:

Best compression efficiency period
HDR support (10-bit and 12-bit color)
Both lossless and lossy
Better at preserving fine details than WebP

AVIF drawbacks in 2026:

93.5% browser support (missing on some older Safari versions)
Slower to encode (2-3× slower than WebP)
Not supported by most desktop image editors

Bottom line: AVIF is the future. For production websites in 2026, use it inside <picture> tags with WebP fallback. For tools and apps that need to generate images quickly, WebP is still the practical choice.

Compression Benchmarks (Real Test)

I took a 1920×1080 photograph (original: 2.4MB PNG) and compressed it through each format:

Format	Quality	Size	% of Original	Visual Difference
JPEG	70%	142KB	5.9%	Minimal
JPEG	85%	218KB	9.1%	None visible
WebP	70%	98KB	4.1%	Minimal
WebP	85%	156KB	6.5%	None visible
AVIF	70%	72KB	3.0%	Minimal
AVIF	85%	118KB	4.9%	None visible
PNG (lossless)	—	482KB	20.1%	Perfect
PNG (oxipng)	—	312KB	13.0%	Perfect

A few things jump out:

AVIF at 70% is smaller than JPEG at 70% by 50%. And it looks better.
WebP at 85% is barely larger than the original JPEG at 70%, with noticeably better quality.
PNG is enormous for photos. 312KB lossless vs 98KB WebP at minimal visible loss — that's a 3× difference.
Quality sliders aren't comparable across formats. 70% in JPEG ≠ 70% in WebP ≠ 70% in AVIF. Each encoder has its own curve.

Decision Matrix: Which Format When?

Use Case	Best Format	Runner-up	Avoid
Website photos	WebP	AVIF with fallback	PNG
Logos / icons	SVG	PNG	JPEG
Screenshots	WebP (lossy 90%)	PNG	JPEG
Print-ready	TIFF	PNG	WebP
Email attachment	JPEG	—	AVIF
Animation (short)	Animated WebP	MP4	GIF
HDR photos	AVIF	—	JPEG
Maximum compatibility	JPEG	PNG	AVIF

The `<picture>` Pattern Every Site Should Use

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Description" width="1200" height="800">
</picture>

This gives AVIF to browsers that support it, WebP to everyone else, and JPEG to the 0.1% that need it. HTML handles the fallback automatically.

Step-by-Step: Optimize Any Image in 2026

Start with the highest quality original you have
Choose the right format — use the matrix above
Adjust quality — 75-85% is the sweet spot for most web images
Resize to actual display size — don't serve 4000px images in a 800px container
Strip metadata — GPS coordinates, camera info, timestamps add kilobytes and leak privacy
Use a tool that does all of this locally — your images shouldn't leave your device

That's exactly why I built CompressFast. It processes everything in your browser — PNG, JPEG, WebP, AVIF, GIF, BMP, SVG, HEIC. Batch 30 images at once. Strip EXIF, resize, convert formats, ZIP download. All local, no upload, works offline.

No account needed. Free.

Questions about format choice? Drop them below — I'll answer every one.

# Why Your Image Compressor Should Never Upload Files

吴美良 — Wed, 08 Jul 2026 13:44:14 +0000

Every "free online compressor" is reading your images. Here's how to tell — and how to build one that doesn't.

You just exported 50 product photos from Lightroom. You google "compress images online." You drag them into the first result. Within seconds, "compressed" downloads appear.

But what actually happened?

The Upload Problem

Every cloud-based image compressor — TinyPNG, iLoveIMG, Compressor.io — follows the same pattern:

Your Browser                    Their Server
    │                                │
    ├── POST /upload (50 images) ──►│  Your photos are now on their disk
    │                                │
    │                      ┌─────────┴──────────┐
    │                      │  Compress           │
    │                      │  Store?             │
    │                      │  Train AI on?       │
    │                      │  Sell metadata?     │
    │                      └─────────┬──────────┘
    │                                │
    │   ◄── GET /download ──────────┤
    │                                │
    │  Did they delete them? Who knows.

The privacy policy might say "we delete your files after processing." But you have exactly zero way to verify that.

What's Actually in Your Images

Even a simple JPEG contains:

EXIF GPS coordinates — exactly where the photo was taken (within meters)
Camera model + serial number — uniquely identifies your device
Timestamp — when you took it
Thumbnail — a smaller embedded preview, often un-cropped
Software tags — which version of Photoshop/Lightroom you use

Someone with access to 50 of your photos can determine:

Where you live (cluster the GPS coordinates)
What devices you own (camera serial numbers)
Your daily routine (timestamps)
Whether you use pirated software (software tags are surprisingly detailed)

This isn't theoretical. In 2023, a major "free compressor" was caught using uploaded images to train an AI upscaler. Their privacy policy was updated AFTER the outcry.

The Local-Processing Alternative

CompressFast — the tool I built — works differently:

Main Thread                 Web Worker
    │                           │
    ├─ User drops 30 images     │
    ├─ Read as ArrayBuffer      │
    ├─ postMessage(buffer) ────►│
    │                      decodeImage()
    │                      compress()
    │                      encodeImage()
    │   ◄── postMessage(result) │
    │                           │
    ├─ Create Blob              │
    ├─ saveAs() download        │
    │                           │
    │  Files NEVER leave        │
    │  the browser              │

Everything happens inside the browser's JavaScript engine:

createImageBitmap() for decoding
OffscreenCanvas for pixel manipulation
canvas.convertToBlob() or WASM encoders for encoding
FileReader + Blob for I/O

The Technical Challenge

Building a local compressor is harder than a server-side one:

1. No native codec access

Servers can shell out to libjpeg-turbo, pngquant, or cavif. Browsers only give you Canvas API — which is JPEG/PNG/WebP only. For AVIF, I had to compile libavif to WASM (@jsquash/avif).

2. Memory constraints

Servers have 16GB+ RAM. Browsers have ~2GB per tab (less on mobile). Processing a 24MP photo creates multiple copies in memory: original Buffer → ImageData → OffscreenCanvas → compressed Buffer. You need to be disciplined about releasing references.

3. HEIC is a nightmare

iOS photos come in HEIC format. Safari can decode HEIC natively, but Chrome can't. The heic2any library solves this but requires window — it crashes in Web Workers. Solution: decode on main thread, pass result to Worker.

4. No filesystem access

You can't "save" to a folder. You can only trigger downloads. For batch output, I use JSZip to bundle everything client-side — no server round-trip needed.

How to Verify a Tool is Actually Local

Don't trust marketing copy. Here's the real test:

Open DevTools → Network tab
Drag an image into the tool
If you see ANY network request with a payload larger than a few KB → it's uploading
Bonus test: Disconnect your internet. If the tool still works → it's legitimately local

Try this with TinyPNG, iLoveIMG, or any other popular compressor. The Network tab will light up immediately.

With CompressFast, the Network tab stays empty during compression. The only requests are optional analytics pings (which you can see in the source).

EXIF Stripping: The Privacy Feature Nobody Talks About

CompressFast strips EXIF by default. Not because it's hard — Canvas API strips it automatically on re-encode — but because most users don't know their photos contain GPS data.

But there's a toggle to KEEP EXIF. Why? Some users want it:

Photographers tracking camera settings per shot
Archivists preserving metadata
HDR workflows that need color profile info

The key is default to safe, opt in to risky. The opposite of what most tools do.

The Business Model Question

"How do you make money if you don't sell data?"

CompressFast is freemium:

Free: 30 images/batch, all formats except AVIF
Pro ($24.99 lifetime): 500/batch, AVIF encoding, custom presets, watermark

No accounts. No subscriptions. No data collection. The activation code IS the "account" — stored locally, verified against Redis, up to 5 devices.

It turns out people WILL pay for privacy when it's paired with a great product.

The Bigger Picture

We've normalized uploading everything to strangers' servers. "Free" tools that process your files, your photos, your documents — all in the cloud, all "for your convenience."

But browsers are powerful now. Web Workers. WASM. OffscreenCanvas. IndexedDB. You can build real, complex applications that run entirely on the client.

Your photos shouldn't leave your machine unless YOU decide they should.

Try CompressFast: compressfast.site — free, no uploads, no accounts.

Open source? The core compression logic is shared in Part 1 of this series. I'm happy to open-source the full project if there's interest — drop a comment.

Tags: #privacy #webdev #security #images #browsers

DEV Community: 吴美良

"How I Built a Browser Image Compressor That Handles 30 Images at Once"

The architecture: keep the heavy work off the main thread

Auto format detection — the "smart" part

Three bugs that took way too long to find

Scaling up to 30 files without melting the tab

The result

"Image Optimization: The Complete 2026 Checklist for Faster Websites"

1. Resize first — it's the single biggest win

2. Pick the right format per image type

3. Compress, don't just convert

4. Strip metadata

5. Use lossless compression for text-heavy images

6. Lazy-load off-screen images

7. Serve modern formats with fallbacks

Real numbers from my testing

The privacy point most guides skip

webdev #performance #images

# I Built a Smart Image Compressor That Auto-Detects the Best Format

How It Works

1. Format

2. Dimensions

3. File Size

The Code

The UI

Privacy: Everything Runs Locally

Try It

I Built a CLI Image Compressor — 73% Smaller in 0.1s

# I Built a $0/month SaaS — Full Stack Breakdown

The $0 Stack

Architecture: Why There's No Server Bill

The only backend code is licensing

Multi-Worker Pool (0 Cost, 4x Speed)

The Compression Pipeline (All Client-Side)

License Keys Instead of User Accounts

SEO Landing Pages (11 Pages, $0 Hosting)

Real Numbers (After 1 Month)

What I'd Do Differently

The Stack in One Line

I Built a $0/month SaaS — Full Stack Breakdown

# Why Your Image Compressor Is Uploading Your Files (And How to Stop It)

AVIF vs WebP vs JPEG: Real Benchmarks (2026)

The Setup

The Numbers

Photo Results (JPEG source, 50 images)

Screenshot/Graphics Results (PNG source, 50 images)

The Catch: Encoding Speed

Real-World Recommendations

For Blog / Content Site

For E-Commerce / Product Pages

For User-Generated Content

For Screenshots / Technical Docs

For "I just want the smallest file"

The Tool I Used

Bottom Line

How I Built a Privacy-First Image Compressor with Next.js + Web Worker

How I Built a Privacy-First Image Compressor with Next.js + Web Workers

The Stack

Architecture: The Compression Pipeline

Speed Tiers

Target KB Mode: Binary Search Over Quality

The HEIC Problem

Pro Features Without a Database

AVIF: The Secret Weapon

What I Learned

Try It

WebP vs AVIF vs PNG vs JPEG: A Practical Format Guide for 2026

# PNG vs WebP vs AVIF: The Ultimate Image Format Guide for 2026

The Numbers That Matter

JPEG: Still the Fallback King

PNG: The Trusted Workhorse (That People Misuse)

WebP: The Sweet Spot (2026 Edition)

AVIF: The New Challenger

Compression Benchmarks (Real Test)

Decision Matrix: Which Format When?

The <picture> Pattern Every Site Should Use

Step-by-Step: Optimize Any Image in 2026

# Why Your Image Compressor Should Never Upload Files

The Upload Problem

What's Actually in Your Images

The `<picture>` Pattern Every Site Should Use