If you saw the news that Firefox 156 now decodes large JPEGs using far less memory, you probably had one immediate follow-up question: does this mean you can finally stop bothering with srcset, sizes, and multiple image exports? It's a fair question, because the change sounds like exactly the kind of thing that would make manual responsive-image work redundant. The short answer is no, but the reason why is worth understanding before you touch your build pipeline.
What does libjpeg-turbo's IDCT scaling actually do during JPEG decoding?
JPEG decoding involves an inverse discrete cosine transform (IDCT), the math step that turns compressed frequency data back into pixels. Historically, Firefox ran that transform at full resolution, producing a complete decoded bitmap in memory, and only then handed it to CSS or the layout engine to shrink down to the size actually displayed on the page. Embed a 4K JPEG that renders at 800 pixels wide, and the browser still built the full 4K bitmap first.
Starting with Firefox 156, the browser uses libjpeg-turbo's IDCT scaling to downscale during the transform itself, according to OMG! Ubuntu's coverage of the release (omgubuntu.co.uk). Instead of reconstructing every pixel and discarding most of them afterward, the decoder produces a smaller bitmap directly. The bug-report benchmarks cited in that coverage show up to 20 times less memory used for very large images and decoding up to twice as fast. That's a meaningful win for a browser juggling dozens of open tabs full of photography, product shots, or hero banners.
Does this optimization reduce the amount of data downloaded, or only decode-time CPU and memory?
This is the crux of it, and it's purely a decode-time change. The browser still downloads the exact same JPEG file, every byte of it, over the network. If your original image is a large, 4000-pixel-wide photo, Firefox 156 still pulls the whole file across the wire before it ever starts decoding. What changes is what happens after the bytes arrive: less RAM churn, less CPU spent building pixels nobody will see, and a faster path to a smaller bitmap in memory.
Think of it like the difference between mailing someone a smaller box versus mailing a huge box and asking them to throw most of the contents away once it arrives. IDCT scaling makes the unpacking more efficient. It does nothing about the size of the package itself. For site owners, that distinction matters, because network transfer, not decode CPU, is often the bigger cost for visitors on mobile data or slow connections.
Do other browsers already do this, and does it matter for cross-browser sites?
This is where you need to be careful about assuming universal behavior. The available reporting only documents Firefox 156's specific implementation and its libjpeg-turbo-based benchmarks; it doesn't detail how Chrome or Safari handle decode-time scaling. Whether either of those browsers performs comparable scale-aware decoding by default isn't something the source material confirms one way or the other.
What that means practically: don't assume decode-time savings are guaranteed across your whole visitor base just because Firefox ships this. A visitor's experience on Chrome or Safari may look and feel identical on the surface, since decode efficiency is invisible to users either way, but there's no confirmed guarantee that the underlying resource savings match. If your site serves large JPEGs to a mixed audience of browsers, treat this as a Firefox-specific efficiency gain rather than a universal one.
| Browser | Decode-time IDCT scaling (per available source) | Network transfer size affected? | |---|---|---| | Firefox 156+ | Confirmed via libjpeg-turbo, documented in release notes (omgubuntu.co.uk) | No | | Chrome | Not detailed in available source material | No | | Safari | Not detailed in available source material | No |
Should site owners stop bothering with srcset and responsive images because of this change?
No. Responsive image markup solves a completely different problem than decode efficiency, and Firefox 156 doesn't touch it. srcset and sizes exist to stop the browser from downloading a 4000-pixel image in the first place when a 400-pixel version would look identical on a phone screen. That's a bandwidth and load-time decision made before a single byte crosses the network.
IDCT scaling only kicks in after the full file has already arrived, so it can never undo an oversized download. If you drop responsive markup and rely on decode-time scaling instead, every visitor on every browser still downloads your largest exported JPEG regardless of viewport or connection speed. On Firefox, their device will at least decode it more cheaply, but on a slow mobile connection, they're still waiting for the full file to transfer, which is usually the dominant cost for real-world page load time.
What should site owners actually do in light of this change?
Treat Firefox's decoding improvement as a nice-to-have that reduces client-side resource pressure, not as a reason to change your build process. Keep exporting multiple resolutions of your images and keep using srcset with appropriate sizes attributes; that's still the only reliable way to control how many bytes get sent over the wire in the first place.
Where this change is genuinely useful is for cases you can't easily control: user-uploaded images, embedded photos in blog posts, or legacy content where you can't regenerate multiple sizes on demand. In those situations, Firefox users benefit from lower memory pressure automatically, with no markup changes needed on your end. It's a welcome safety net, not a replacement for deliberate optimization.
Is there a common misconception worth clearing up here?
The biggest misconception is conflating "decoded efficiently" with "downloaded efficiently." People see a benchmark claiming 20 times less memory use and up to 2x faster decoding and assume the browser has somehow made the image itself smaller or the download faster. It hasn't. The file on the server is unchanged, the HTTP request is unchanged, and the number of bytes crossing the network is unchanged.
What changed is purely what the browser's decoder does with those bytes once they land, shaving CPU cycles and RAM off a step most users never think about. That's a legitimate, worthwhile engineering improvement, particularly on lower-powered or memory-constrained hardware where image-heavy pages tend to strain resources. But it lives entirely downstream of the transfer, which is exactly where responsive image techniques still do their work.
