Earlier quoted context omitted.
There's one thing JPEG has the edge on- true Progressive loading. If you're clever you can use fetch freqests to render a thumbnail based off the actual image by manually parsing the JPEG and stopping after some amount of detail. I'm more than a little suprised that no self-hosted photo solution uses this in any capacity (at least when I last checked).
Google answers this question in the FAQ: https://developers.google.com/speed/webp/faq#does_webp_suppo... But in my experience, webp is better enough that the whole file loads around the same time the jpg progressive loading kicks in. Given that progressive jpgs are larger than non progressive (so not a 'free' feature), jpg is just a waste of bandwidth at this point.
Re: Automating Image Compression
#11That link doesn't address my point at all. If you have 1000 photos in a scrolling gallery there's no lossy format besides JPEG that allows you to grab just enough of the file to render a thumbnail. This has Major bandwidth, Storage, Compute, and UI responsivness implications.