There's some unexamined hooey in this post. For example you can't really compress a JPEG, but you can re-encode it to a lower quality, which can have dramatic effect on the file size. That's what moz2jpeg is doing for this person.
But they could have just done the same thing in Photoshop, Preview, MS Office image tool, etc. JPEG is a standard; file size does not depend on what tool you use to create it. It's strictly dependent on the image itself, and the render settings you choose. Same with PNG.
In fact, you'll get better quality for the file size if you go directly from the original image straight to your final resolution in one step. Rendering to high-quality JPEG, then re-rendering on the server to shrink the file size, will give you worse image quality than just going straight from the original file to the final in one render.
WebP looks promising but is not yet well-supported. Most sites can go a long way just by caring about, testing for, and adjusting image rendering defaults to optimize for file size.
EDIT to add a bit more:
If you are optimizing images as part of a pre-deploy build process, you can use whatever library you want. The only thing that really matters is your choice of format (JPG or PNG), and the render settings. Or, you can hand-optimize the images and drop them into your repo to deploy as-is.
If you're running a CMS where non-developers are going to be uploading images through an admin UI (like Wordpress), your CMS should be using a server-side library to render optimized versions of the images that get uploaded, then serving the optimized versions. You can adjust the settings of the server's image library, although that might require a plugin or module, or custom code, depending on the CMS.
Missing this is a common killer mistake in page load times. I visited a site the other day that served a 16 MB JPEG file for the "hero" image on the homepage. My guess it that it was the JPEG straight out of a high-resolution camera.
This is also good for user privacy, as the server-side rendering should remove IPTC and EXIF data that would get served with the original image.
> JPEG is a standard; file size does not depend on what tool you use to create it.
That’s simply not true. The specific choice of cosines can make a huge difference on compression while having nearly zero perceived visual difference. Most encoders however take a naive approach whereas something like Guetzli does an amazing job of compressing JPEGs way better than Photoshop ever could.
Guetzli is not appropriate as a general-purpose tool for optimizing website images. That's not really what it's designed for.
I guess I should specify that I'm trying to give practical advice for people who think the linked blog post is instructive. For the vast majority of people, the simple act of thinking about, selecting, and testing the available settings in popular image optimization tools is going to have a far greater effect than the small optimizations (and sometimes big tradeoffs) that might come from cutting-edge stuff like Guetzli.
The reward per effort of going from "not optimizing my images" to "purposefully optimizing my images using common tools" is typically much bigger than the step from the latter to "using the absolute best possible tool for each image."
Guetzli is for minimizing file size at the highest quality levels for JPEGs. Essentially, it's for nice looking photos.
It only goes down to quality 84 and it takes a looonngg time to optimize. As a point of comparison, the author of the linked blog post dropped his JPEG quality to 70 and was happy with it. A JPEG at 70 (or lower), if you're happy with the look, has a good shot to be even smaller than the smallest Guetzli output.
Generally speaking, the easiest gains in JPEG file size will probably come from just dropping the quality down and down in tests, and deciding what you can live with. But if you have to have the best quality, and have plenty of resources/time for encoding, then maybe Guetzli will be a good fit.
> JPEG is a standard; file size does not depend on what tool you use to create it. It's strictly dependent on the image itself, and the render settings you choose.
This is not correct. For both JPEG and PNG the compression ratio can depend on the tool.
For JPEG the reason is that the quantization tables are not fixed. The quantization tables dictates how information is thrown away, and as such is responsible for the lossy part of JPEG.
The JPEG standard merely contain recommended quantization tables, however a lot of research has gone into deriving better quantization tables, especially image-dependent (tailored) ones that can provide better compression for the same image quality, or better image quality for the same compressed size.
For PNG the standard defines five pixel filters used to transform pixel values into something more compressible. However it leaves the encoder free to decide which filter to use and when. Thus a simple encoder is free to use the "None" filter for everything, ie don't do any filtering.
In addition, the PNG standard allows for additional pixel filters to be registered as extensions. Thus encoders with more advanced pixel filters could potentially compress better than an encoder supporting only the standard filters.
Here's why: PNG has a pre-processing step to turn pixel data into bytes, then a general purpose compressor is used on the bytes. The algorithm used is picked per row, and if you pick the right one the compressor will have a better shot at small output, but which algorithm is best for each row of your image?
The popular libpng reference implementation contains a weak heuristic to pick algorithms that might do well, but a tool can do much better... Or it can do much worse. Early PNG support in Adobe Photoshop just picked "do nothing" for every row, resulting in huge PNG files.
I suggest you just try running optipng on some random PNG files you have on your HDD. Results vary greatly, but I've seen savings between 10 and 20% on files coming from GIMP where I always set the compression to 9 (maximum).
I never touched Photoshop in my life so no idea what you can tune there and what its defaults are, but general experience shows that a lot of people either just don't bother and go with the defaults, or go all crazy clicking and manipulationg everything without knowng what's going on.
I agree with you that for JPEG there is no silver bullet, but like that other comment here suggests, you could perfectly just run optipng on max settings in a cronjob and call it a day, because you know there will be absolutely no quality loss if you don't explicitly request it.
You can compress (or rather, optimize) an existing JPEG if the Huffman tables were suboptimal (which they often are). It usually gives a few percentage points of decreased file size.
You can also drop metadata (e.g. EXIF) in many circumstances, which saves a bit more.
But they could have just done the same thing in Photoshop, Preview, MS Office image tool, etc. JPEG is a standard; file size does not depend on what tool you use to create it. It's strictly dependent on the image itself, and the render settings you choose. Same with PNG.
In fact, you'll get better quality for the file size if you go directly from the original image straight to your final resolution in one step. Rendering to high-quality JPEG, then re-rendering on the server to shrink the file size, will give you worse image quality than just going straight from the original file to the final in one render.
WebP looks promising but is not yet well-supported. Most sites can go a long way just by caring about, testing for, and adjusting image rendering defaults to optimize for file size.
EDIT to add a bit more:
If you are optimizing images as part of a pre-deploy build process, you can use whatever library you want. The only thing that really matters is your choice of format (JPG or PNG), and the render settings. Or, you can hand-optimize the images and drop them into your repo to deploy as-is.
If you're running a CMS where non-developers are going to be uploading images through an admin UI (like Wordpress), your CMS should be using a server-side library to render optimized versions of the images that get uploaded, then serving the optimized versions. You can adjust the settings of the server's image library, although that might require a plugin or module, or custom code, depending on the CMS.
Missing this is a common killer mistake in page load times. I visited a site the other day that served a 16 MB JPEG file for the "hero" image on the homepage. My guess it that it was the JPEG straight out of a high-resolution camera.
This is also good for user privacy, as the server-side rendering should remove IPTC and EXIF data that would get served with the original image.