About progressive imaging support.
One of the things about running a website is that you sometimes forget some features that were always there. We have chosen to remain a heavy graphical site. We are not going to replace everything with minimalistic fonts.
Because of this decision, it's in our best interest to make sure that the content that we provide appears to you, the user, as fast as possible. We've talked about optimization of filesize, which helps significantly. But we also need to consider that not everyone will be connecting to us with the absolute best of connections. The final destination may only be receiving our site at the speeds of dial-up, at the late 1990s level of technology. If you're a webmaster who has gone through the pitfalls of slow imaging on alternative networks. Then feel free to read onward into my Diatribes.
"Note: If you get a black screen but the audio is playing. Or you got a potato PC and it's studdering. We have fallback Links below."
Video tutorial fallback mirrors:
In case you have no-script enabled or for some reason cannot see the title video on this website. We have provided direct links for these videos. For more information about the standards we use on this site click here if you would like to know more.
AV1 - Link MP4/.h264 - Link OGV - Link
WHY progressive instead of traditional?
We shall upload two pictures, which are 8k in size, then use them in Firefox to load them and OBS to capture. These will be animated, so for those on I2P/Tor, it may require a little time to load. We shall put in the 'loop' command so that it will cycle when it is completed.
For those who have suffered throughout the dial-up years of AOL, Prodigy, and Compuserve. Well, outside of us reminding you how fucking old you are, just mentioning such names, those people know what the pain of image loading was in the early days of the internet. Seeing line after line of graphic data slowly coming down. Where someone uploads a ridiculous image size and you almost have to go get yourself a coffee, maybe talk to your neighbor, and by the time you return to your computer, that 2meg image would be done downloading. Luckily, the alt-nets like Tor and I2P aren't that terrible. But they can be close!
A lot of the connectivity depends on how many nodes are within your country that you can access. As well as how much bandwidth each node is willing to offer to the network. As you can see in the photo, if you run with progressive imaging, the user gets a low-resolution preview of the image that is coming to their computer before the transfer is completed. Versus traditional loading of images, which takes a top-down approach of graphical rendering.
Try it yourself!
I will post the originals used in the video so you can try your own experiments with your internet connection. The pictures were taken using the Firestorm Second Life Viewer at the most stupid resolution possible, which so happens to be 7680 x 4320 or 8K.. Which begs the question. Do people play Second Life at 8k? Possibly!! Especially if they hate their framerate.
Click on Chonk1.jpg to be taken to the original 7680 × 4320 JPG. @ 18.4MB
Progressive @ 16.6MB | WebP @ 291KB | AVIF @ 313KB | JXL-Progressive @ 288KB
Click on Chonk2.jpg to be taken to the original 7680 x 4320 JPG @ 18.4MB
Progressive @ 16.7MB | WebP @ 248KB | AVIF @ 257KB | JXL-Progressive @ 274KB
Click on Chonk2.jpg to be taken to the original 7680x4320 JPG @ 21.7MB
Progressive @ 19.7MB | WebP @ 222KB| AVIF @ 187KB | JXL-Progressive @ 233KB
How do we handle JPG.
To convert all of the JPGs to progressive, it's just a simple command we modify on our script that runs the jpegoptim tool, from:
jpegoptim --strip-all FILENAME.JPG
to
jpegoptim --all-progressive --strip-all FILENAME.JPG
And that is it!
The positives?
- Obviously, the user gets to see a low-resolution image right away before the cleaner one is loaded. For those connecting to ClearNet on a broadband connection, you probably wouldn't notice anything.
- Apparently, there's some SEO bullshit about the perception of a site being loaded faster because Google is an idiot about how a website loads. To Google, as long as the whitespace disappears, then it's considered loaded. And sure, smaller files equal faster load times.
- You're JPG files will be smaller. Only a 1-4 percent savings (sometimes up to 9 percent savings on dimensionally larger files). But hey! Every little bit helps.
The negatives.
- On very old browsers, before Windows 7, progressive JPEG encoding may not work.
- Very old CPU devices/phones that can accept this image format, but may experience some lag when loading these kinds of images, as it has to screen render multiple times to load the image.
- If the image is still loading and the user wishes to save before it finishes loading. Artifact or glitching issues may occur.
We guess the file extension used to be called "FILENAME.PJPEG" or "FILENAME.PJP" which we're told modern browsers accept. If it becomes a problem for retro computing, we might set up a mirror for progressive JPEGs underneath that standard for new computers. While maintaining/normalizing *.jpg for the classic computing scene, just like we did with the other image formats out there. We'd rather not because that would be a colossal waste of disk space.
How do we handle PNG?
PNG files do not call it 'progressive', but instead they call it 'interlaced', meaning that the larger blocks of a PNG are rendered first before it refines into smaller and smaller sections. For this, we use the optiPNG command. This is before: optipng -o7 -zm1-9 -strip all FILENAME.PNG This is after: optipng -i1 -o7 -zm1-9 -strip all FILENAME.PNG
The positives?
- Just like JPG, the user does get to see the progress right away.,
The negatives?
- Watch your PNG file EXPLODE in size from 20 to 60 percent!
- Possible corruption if you save before the image is fully loaded.
- Again with the CPU load if you're system is very old.
We're not entirely sure if the interlacing effects of older machines, such as PNG, were brought into browsers later than JPG files. Now, the reason why we use PNG files is when doing OS screenshots, if you reduce your color palette to 4-8-bit, you STILL end up saving more space than transferring it over to JPG. Even with a 60 percent jump, it's still lower than re-saving as JPG. It's just a little unfortunate that PNG files do this.
How do we handle GIFs?
GIF can also be interlaced, although it's sometimes avoided for compatibility issues. We try to stay away from this ancient standard from the 1980s, but for some reason, the internet holds onto this ancient standard because of its animation abilities. Even though Japan has shown us better ways for animation, such as 'animation-PNG' or APNG files, which allow a 24-bit palette and transparency.
How do we handle JXLs?
For the 0.2 percent of you who access this site via JXL as a middle finger to Google. Or, rocking a browser like Thorium that already has JXL enabled WITH animations. You are awesome.
This is our before:
cjxl -d 1.0 --lossless_jpeg=0 -e 9 --brotli_effort=11 FILENAME.JPG FILENAME.JPG.JXL
and our after:
cjxl -p -d 1.0 --lossless_jpeg=0 -e 9 --brotli_effort=11 FILENAME.JPG FILENAME.JPG.JXL
We admit we were hard on the JXL review back then. Partially because at the time of testing, it was version 0.7. Documentation was not the greatest back then, and some rendering issues were occurring. We feel a little bad that Google Chrome shut out this image standard, as it still has potential in the photographic and cell-phone markets, needing little CPU to encode a JXL versus Google's beast that is AVIF.
about:config for Firefox/Librewolf is a magical place.
Perhaps this could be a standard that Tor/I2P should adopt into its prepackaged browsers, as these protocols wish to separate themselves from the internet while also delivering content quickly. We'll also be the first to admit that we're not even scratching the surface of JXL's full potential for showing HDR footage, as we aren't that heavy into photography. Pros and Cons are identical to JPG except you enjoy the benefits of modern compression, so no real need to repeat ourselves on that subject.
Embracing new standards is a chicken/egg issue. There's no harm in getting the egg started by turning this on your Tor/I2P-only browser.
Animated JXL.
FFMPeg 8.0 now officially supports animated JXL files, but the rest of the browser scene has been rather dead about it. So far, the only reason we know our animated JXL files work is that we had to load another browser called "Thorium," a Google Chrome fork of the software, which seems to have JXL working right out of the box. Also, unlike LibreWolf, Thorium can understand JXL transparancies better. We have a feeling it's going to be like the AVIF issue with Firefox. Where animations will just suddenly start working on the next batch of updates.
However, when it comes to animated or regular JXL, the classic cjxl command still converts our animated GIFs to JXL better.. At least for now!
How do we handle WEBP?
It's not the fact that we don't want to. It's simply because we can't.
There is no progressive loading for WEBP. Which we find humorous. It's rather ironic that Google, the people who funded WEBP and have moved the work WEBP has done into the AV1 organization of even bigger corporations. But to this day, they can't help the SEO of the people who use their format by offering progressive loading. Shit, even JXL managed to pull that off, and it's just a handful of devs! This is another classic case of Google:
Think Google. Except us. Fuck that.. - Google.
How do we handle AVIF?
avifenc --progressive -q 80 --qalpha 80 -a end-usage=q -a cq-level=18 -a tune=ssim -s 0 -j 2 "picture.jpg" "picture.jpg".avif
At the time of writing this documentation, we originally thought the AVIF suffered the same fate as WEBP. Only to find out it was the fault of AI that's trying to answer questions on not just search engines but also inside of forums as well, telling people it's not possible when in reality it actually IS possible, just in experimental status by adding the "--progressive" flag to your avifenc command. It seems that throughout AVIF's time, people were -really- screaming for this feature, only for it to be slowly introduced much farther down the timeline than JXL was able to do it.
Another case of AI fucking with not only the developers by excluding the latest fixes and features within their codebase. But also the end-user who would be unfortunate bastards that would pick whatever AI gave them on Google and vibe-code away.
Disadvantages of progressive AVIF
- Expect almost a 100 percent jump in filesize using progressive versus a regularly compressed AVIF! AVIF renders in two passes, effectively stacking images into a single container. This is a bullshit practice on AVIF's behalf that you can surely say you're 'progressive' by offering a lower resolution picture first before the real one comes in. But at the cost of double the bandwidth, traversal is absolute bullshit. completely nullifying the reason why one would even mark their codes progressive.
- As it's still in experimental status, some browsers may or may not support the ability of AVIF progressive rendering. So in the future, perhaps one can encode a super-low quality AVIF first pass, taking only 2 percent additional space.. THEN, encode the normal AVIF second pass. It's just that at the time of writing, it's simply not working this way.
Again, thinking with Google results in bad decisions. But then again, at the time of this article, progressive encoding for AVIF is still marked as experimental, and in our opinion. Kinda worthless.
Special notes on I2P
Apparently, when traversing the I2P networks via proxy of a router, one of the functions the network does is it changes your client header to "MYOB/6.66 (AN/ON)" to mask the identity of your browser/OS/etc. The accept header for MIME formats may be changed as well.
This could be the end result as to why my website can only detect WEBP image support on an I2P network. But if we were to use an outbound proxy, it would place its own client and possible accept header, and then we would receive JXL/AVIF support back. This is in release 2.10.00 of I2P at the time of posting this. This is to make acceptance headers like this hold the process of using AVIF/JXL back on that network, as the software is behaving as a man-in-the-middle to avoid unmasking their clients. Since WEBP is supported in just about every modern browser, it was safe for them to add it to the accept header of "MYOB/6.66 (AN/ON)"
If you directly called out an AVIF/JXL with your browser supporting it, then it works without issue. Unfortunately, Nginx does not roll like that. Which means our consolation prize is that there's at least a group of people still using WebP instead of migrating to justify the disk space, at least for now.
Meat to metal time.
Is progressive JPG/PNG actually better than normalized WEBP or AVIF, which cannot do progressive (or at the time of writting this article does it piss-poor by just making a duplicate of the same file like AVIF)?
In most cases. NO!
One of my art pieces, saved in PNG format, can reach a size of up to 3 MB. To obtain a low-resolution version of this PNG, it could take approximately 1.5MB on the first pass. The compressed WEBP version is around 210 KB. AVIF is simply not ready for prime time in making progressive images if all it's going to do is stack the exact same image twice.
So why would we give the users of Tor/I2P a shitter copy of something when they get the high-quality lossy image for less of a round-trip time than the master? Since people are using newer builds of Firefox that Tor and I2P provide, they handle AVIF/WEBP out of the box. It's better to just leave the option on than to turn it off and let people suffer from trying to download the original JPG/PNG file.
And JXL?
JXL is is competitive with the other formats and sometimes comes out better. It DOES support progressive loading, thus receiving a payload of approximately 25 percent for the first low-res pass is faster on Tor/I2P versus all those put together. But very few people enable JXL in their browsers (kudos to Apple for at least letting Safari use it as an option). Fewer browsers still support animated JXL at the time of publication. And thus, it does not get used.
Final thoughts.
We know that we're using command-line statements such as jpegoptim, optipng, avifenc, and cjxl to accomplish the task. This is because, in general, these applications are included in many of the modern Linux distros. When it comes to deployment on a shared hosting plan, it becomes a little more difficult to support, as the staff that supports hosting plans generally don't like you eating a shit-ton of CPU time to optimize an image. Also, even if you upload it to a shared plan, the odds of them giving you control over image substitution, like what we've done with nginx, would be slim at best.
You could, of course, type in a website to convert whatever format to something progressive as well. But we will not recommend any of them because that's handing your data to a third party. If you want to cross-check their compression versus what you get via the command line. Hand them something they can't use like some normal porn. We tend not to trust these websites because they can fill the metadata of your images with promotional crap that you simply don't need.
At the end of the day. Progressive is helpful if you do have a lot of graphical action going on. Because I2P only supports WebP due to the router masking your browser ID it still proves useful to host such images here despite not having a progressive nature as much as a raw bandwidth saving nature. Of course. We're also not doing ourselves any favors by hosting 200MB of images and video to prove a point. But eh.. We'll get over it eventually.
That's what server said.
+++ END OF LINE