Why WebP Still Breaks Things in 2024, Sometimes Silently
WebP is great on paper. It’s everywhere — Chrome loves it, Edge respects it, Firefox tolerates it — but there’s still one major use case that keeps tripping me up: lazy-loaded images injected post-render by JS-heavy frameworks. I once made the mistake of swapping every .jpg and .png in a Next.js app’s components with dynamic WebP variants using a Cloudflare Worker, only to discover some images never displayed unless the viewport was resized.
The culprit turns out to be a race condition between intersection observer + the format detection polyfill. Basically, if the image hasn’t been painted before the MIME check fires, it just silently fails. No error in the console. Nothing. The image just doesn’t make it to the DOM render tree.
Check for this behavior if:
You’re using a frontend library that renders differently on hydration
You inject images dynamically instead of at build time
Your images work fine in Safari but blank in Firefox, or vice versa
Fixing it meant either preloading the WebP resource or shimming my image component to fall back more assertively. I also added a really dumb setTimeout(() => img.src = img.src) to retrigger drawing, which actually got everything stable. So yeah — not proud, but the layout held.
Avoiding Double Compression When Using CDNs + Plugins
This one actually cost me two days of AdSense revenue because the page speed tanked under 40 on mobile and the layout jump kicked out half the anchor ads. If you’ve ever run something like ShortPixel or Smush in WordPress, and then layered a CDN like Cloudflare that does its own image optimization, there’s a good chance your images are taking double hits: one lossy, then another lossy — and suddenly your crisp logo looks like a JPEG saved inside a screenshot of itself.
The weird thing is most plugins say they’re compatible with Cloudflare, which they are… unless you’re using “Polish” under performance settings. That auto-optimizes images at the edge, and it does offer WebP support — but poorly documented.
The edge case I found was if your plugin already sets content-type: image/webp or rewrites file extensions server-side, Cloudflare skips optimization entirely. But it doesn’t log that anywhere. Your image headers just say it’s untouched, and your images look off — but not enough to immediately notice unless you’re screenshooting sections for QA or running in a pixel-perfect layout.
I only caught it by diffing the byte size again and again via curl. It’s miserable work, but when you’re trying to manipulate CLS to under 0.1 for those sweet Core Web Vitals, it’s worth it.
Which Tools Actually Respect Source DPI and DPI Fakeouts
So, DPI lies. That’s the thing that almost no optimization tool flags — you can upload a 1000×1000 image that claims to be 144dpi but still looks blurry at half that size on retina screens. And some optimization libraries (lookin’ at you, older ImageMagick builds) will happily downscale it based on declared DPI rather than pixel resolution.
ImageKit claims to retain DPI metadata, and it does — but it also applies auto-scaling based on dimension thresholds. So if you pipe in high-res images from Photoshop exports with fake high DPI but low physical pixels (because someone exported for web with ‘resample down’ checked), the optimizer says “oh cool this is high-res” and aggressively compresses it, throwing off your output.
“Why does my logo look worse after optimization than before?” — me, during a client call, realizing the retina images were resampled into oblivion
If you ever see a sharp image turn into a muddy mess post-optimization but your output size barely changed, that’s usually DPI disrespect. You can get around it by stripping all EXIF headers and re-exporting purely by pixels. Or — and I hate that this works — resizing the image to 1px larger in either direction confuses most optimization presets just enough to skip downsampling. Go figure.
When AVIF Is Worth It — And When It Fails Loudly
AVIF is lighter, sharper, smaller, more modern — and occasionally won’t render at all on older Android WebViews. Not older browsers — those fail gracefully. It’s the WebView environments, especially embedded in apps built on React Native or Cordova frameworks, that fail without fallback, silently.
The first time I hit this was with a hybrid app shell that showed AVIF images over API endpoints. On modern Android? Looked great. On a Motorola E9, the entire interface blanked out where image components should have been — no crash, just zero content. Once again: no console errors… because WebView doesn’t propagate them unless you attach a debugging client.
So this is now my working rule:
AVIF for all modern web across Chrome, Edge, Firefox, Safari (post v16)
Only use AVIF fallback in app wrappers if you manually verify every targeted WebView engine
Never use AVIF as a MIME-typed asset unless you specify a fallback image with <picture>
Also, some CDNs are now faking AVIF support on the edge — you request WebP, and they return AVIF if the header hints it might work. It’s usually fine. But twice I’ve had an asset marked Accept: image/webp serve an AVIF with no warning, and… nothing displays. Huge pain to debug because the developer tools list it as a 200 OK response with a valid file size — but the image is actually corrupt due to format mismatch. It’s easy to miss unless you hex dump the bytes or open in an AVIF-aware viewer like XnView.
Compression Ratio vs Color Banding: How Much Loss Is Too Much
This is an argument I’ve had with designers and developers. You can push JPEG down to around 40% quality and fool the human eye on photos — unless there’s gradient banding. And there’s zero mention of this issue in most image tools. You wouldn’t notice until you embed a sunset stock image, it looks fine on Chrome, but on Firefox’s rendering engine… you see lines. Ugly, chunky, 12-year-old-smartphone lines.
What most devs forget is that gradient compression failure gets amplified by GPU acceleration. The browser tries to interpolate and ends up making it worse. Multiply that by compression artifacts and suddenly your full-width hero image looks like an After Effects composition exported at 144p.
If you want to avoid it:
Never compress gradients below 60% JPEG quality
If you’re stuck with JPEGs, add imperceptible noise before export to break the banding
PNG-24 handles gradients best but only if you’re okay with the file size tradeoff
WebP solves most banding but introduces its own edge contrast sharpening (watch for halos)
I had to manually patch a marketing site’s carousel images because the photographer loved backlight fades. Every image looked fine on the staging server, but when deployed through Netlify’s default image pipeline… total banded chaos. Re-exported with added dithering and used WebP instead. Fixed it. Temporarily.
What “Lossless” Means Is… Incredibly Contextual
Here’s the deal: PNG is ‘lossless,’ which just means it preserves pixel data. But any gamma or color profile info — gone if the tool decides you don’t need it. I tested six so-called lossless PNG optimizers and four of them stripped ICC profiles without blinking.
Running pngcheck -v on optimized images became my new nightmare hobby. At some point I started seeing chunks like:
chunk gAMA at offset 0x29c: 0.45455 (1/2.2)
chunk pHYs at offset 0x2a7: 3780x3780 pixels/meter (96 dpi)
That 96dpi tells you it was re-declared, probably defaulted after stripping the AdobeRGB tag. If you’re delivering icons or UI elements that sit over non-white backgrounds, the color may shift subtly — frustrating when you’re trying to make everything look pixel-aligned on Apple devices.
The deeper cut: even lossless AVIF or WebP has quantization under the hood. It’s not always exact byte-for-byte. If that matters (say, print-to-screen pipelines), you have to validate checksum comparisons across multiple encoders. I fell down this rabbit hole trying to trace why two icons exported via Sketch looked different when optimized using different online services. Same source assets. Different hash sum.
Watch Out for Format Mismatch in Email Clients (Yes, Still)
If you’re embedding images in email, do not assume WebP or AVIF will render — ever. Not just on Outlook, which predictably borks every spec since 1995, but even Gmail on Safari doesn’t consistently obey <picture> tags in emails. You think you’ve got fallbacks in place, then open your beautifully designed digest only to find empty alt text in its place.
The edge case here is Gmail-on-iOS-via-Safari. It pretends to support modern formats and will even show them in live previews when sending test emails… but strip the image tag at runtime in bulk mailings. Why? I don’t know. I’ve sent support queries and gotten shrugs.
Your safest bet is inline base64 PNGs for small logos/icons + hosted JPEGs for main banners. It’s a pain. But at least they’re stable across engines. Anything smarter and you’re rolling dice with user inboxes.
No matter what the optimization service swears about ‘email-safe’ compression, test every client. And test real mailings — not previews.
Server-Side Workarounds That Actually Save You Time
I rigged up a basic Lambda function buried inside an AWS API Gateway to intercept web image requests and determine whether to serve WebP or JPEG based on the Accept header. Not rocket science, but it shaved down 600ms TTFB from using third-party image reroutes. Here’s the gist:
Sure, there are smarter edge functions from Cloudflare and elsewhere, but sometimes you just need a blunt object that works.
More discoveries:
AWS S3 adds unexpected cache-control: max-age=0 unless set explicitly
Cloudfront invalidations are slower than expected past 250 objects at once
Browser cache may stubbornly hold onto old formats for days despite all the headers
That last one caught me when I updated a hero image to AVIF but Chrome’s dev tools kept showing the older WebP version — even after cache flush. Turns out it was preloaded via an inlined <link rel="preload"> tag I forgot to update. Browser treated it as immutable. Browser’s not wrong. But it didn’t help me debug why clients were still seeing version one instead of version two, 48 hours later.
