Guetzli generates smaller images but is it production ready?

[bvvkrishna]

We have planned to implement Guetzli on our production environment and has tested the algorithm on approximately 100+ images. Also did a comparision analysis with Zopfli to see the benefits. We have noticed that even though Guetzli generates smaller images it takes lot of time to compress the image once image file size crosses around 100 KB. Are there any plans in addressing the computation time so that algorithm can run faster? Because this is the primary factor which is blocking us in implementing the algorithm in production. So could you able to tell when this can be fixed.

[kornelski]

There's discussion of it in #50

[tomByrer]

So use case @bvvkrishna right now is to use Guetzli as a build step for images, or as a extra optimzation of high-demand images on a CMS. Not ready for compressing all images live right now.

[rogierlommers]

We have implemented a queuing system, dedicated for the Guetzli step. Images in our asset flow are processed as normal, through synchronous calls. Then, as the final step (when the rendition is put on the place where it's served from), the location is put on a queue. Based on the number of messages in that queue, we can start n-amount of workers, all performing the Guetzli process to the images.

The benefits:

• we are able to serve renditions right away
• but as an extra benefit: they will be runned through Guetzli, but in an a-synchronous way

[catalinux]

@rogierlommers We're doing the same thing. It works great.