New client side image optimizations for Discourse

News and Events Announcements
1

Almost 5 years ago, we introduced Client side image optimization to enable users to upload pictures which were larger than the site limits, save user upload bandwidth, save community storage space, and make the user experience with images in Discourse snappier overall.

Building on top of that, there is a new Upcoming Changes that enables a few new features to this system:

GIF → Animated WEBP conversion

Converting large GIFs has been on our radar for a long time, and now they are converted to animated WebP, which averages half the size of the original file:

1ueX9IP
(2.5MB GIF → 1MB WEBP)

output
(10.1MB GIF → 4.8MB WEBP, wouldn’t be allowed by default in Discourse based on size)

HEIC conversion

We added support for HEIC in 2020 via server-side conversions, and we now also support handling those directly in the composer, giving the user visibility of the conversion result before a post is submitted. We kept server-side conversion working as a fallback if client-side fails for some reason.

20220423085935
202204230859351920×2560 421 KB

(3.4MB HEIC → 650KB JPG)

JXL conversion

While the browser support for JXL files isn’t ready, users are now able to upload JXL files to Discourse and have those automatically converted to JPG so every user can see the image.

chestnutwater
chestnutwater1920×1280 910 KB

(1.1MB JXL → 930KB JPG)

37 Likes
2

Love to see optimization for efficiency! But why not greater use of WebP, e.g. for JXL and HEIC conversions, and especially for PNG conversions/compression? I’d suggest AVIF but, unlike WebP, it’s not quite yet widely supported enough yet AFAIK.

3

HEIC and JXL with transparency are already converted to WebP instead of JPG, and I considered using it always, but this would require adding a myriad of site settings to allow admins to fine tune behavior which gave me pause.

Same here.

Ideally, I would love us to empower admins with settings to control image compression on both the client and the server side, while still shipping sane defaults, and even allow end users to opt-out of compression just-in-time via a composer upload modal options, like Telegram and Whatsapp do, but there is no appetite internally for that work.

6 Likes