Opening this bug to continue the work from bug 50714. Over there, lossless alpha channel reduction is done for Chromium (skia) only. Below is the original bug description. ** I noticed that, when exporting PNG images, the alpha channel is included, regardless whether it contains any meaningful transparency or just fully-opaque pixels. In my experience, the overwhelming majority of images available on the internet do not have transparent or semi-transparent pixels. Removing a fully-opaque alpha channel (when it's safe to do so) will not only enhance the compression ratio, but will also improve the speed. Although a safe alpha channel removal requires a-priori inspection of all the image pixels' alphas, this pays off when the zlib compressor has less work to do, afterwards. Overall, in my tests, there is a 10%-20% speed improvement. Speaking about speed, there is the issue of running the alpha channel inspection test, only to notice that there actually is some transparency. In this case, this will be an overhead, with no actual savings. However, this should be below 10% in the (statistically very rare) worst case. Images tend to have transparency around edges, while the center pixels are opaque. Because of this, in the wide majority of cases, the alpha test will exit very early, and will cost almost nothing. In PNG terminology, this operation is called a lossless image reduction of the PNG image type. There are many other possibilities to reduce the image type, and they are mentioned in an article that I wrote long ago, named "A Guide to PNG Optimization". http://optipng.sourceforge.net/pngtech/optipng.html (see Section 2.1)