【ITニュース解説】oxipng after pngquant: about a second per three PNGs, big win on photos, a shrug on illustrations

現代のWebサイトやアプリケーションでは、画像を大量に使用するため、そのファイルサイズはページの表示速度やユーザー体験に大きな影響を与える。画像ファイルが重いと、ページの読み込みに時間がかかり、特にモバイル環境ではデータ通信量も増大してしまう。このため、画像をできるだけ小さく圧縮する技術は、システムエンジニアにとって非常に重要な課題の一つだ。PNG形式の画像は、画質を保ちながら透過表現ができるため広く使われているが、ファイルサイズが大きくなりがちという特性もある。この記事では、PNG画像をさらに効率的に圧縮するための具体的な方法と、その効果を検証した結果について解説する。

今回の検証の目的は、pngquantという非可逆圧縮ツールで画像を処理した後、さらにoxipngという可逆圧縮ツールを組み合わせることで、どれくらいのファイルサイズ削減と処理時間のコストがかかるかを明らかにすることだ。pngquantは、人間の目にはほとんど区別できない範囲で画像の色数を減らすことで、大幅なファイルサイズ削減を実現する。これにより、画質は少しだけ犠牲になるが、その効果は大きい。一方、oxipngは、画像の見た目を一切変えずに、内部データの冗長な部分を整理したり、より効率的な形式に変換したりすることで、ファイルサイズを削減する。これは「可逆圧縮」と呼ばれ、画質の劣化は発生しない。両者を組み合わせることで、より高い圧縮率を目指せるのではないか、という仮説のもとで検証が行われた。

検証は、Apple M4チップを搭載したPC上で、pngquant 3.0.3とoxipng 10.2.1というバージョンのツールを使って行われた。対象となったのは、スクリーンショット、アイコン、イラスト、写真の4つのカテゴリーから各3枚ずつ、合計12枚のPNG画像だ。これらの画像は、ウェブ上で一般的に使われる様々な種類の画像を代表している。検証では、まずpngquantで画像を圧縮し、その出力ファイルをさらにoxipngで圧縮するという二段階のプロセスを踏んだ。結果として得られたファイルサイズと、それぞれの処理にかかった時間を正確に測定し、画像品質の比較は行っていない。

具体的な削減効果を見てみよう。例えば、元のサイズが40,369バイトのアイコン画像は、まずpngquantによって7,600バイトまで削減された。これは元の約81%もの削減に相当する。そのpngquantの出力ファイルに対してoxipngを適用すると、さらに6,954バイトまで小さくなった。oxipngだけで646バイト、つまりpngquant後のファイルから8.50%の追加削減があったことになる。 この追加の646バイトがどれほど重要かは、用途によって異なるが、12枚の画像全体ではさらに顕著な結果が出た。元の合計サイズが4,454,411バイトだった画像群は、pngquant単体で1,411,877バイトまで削減され、元の約68.3%も小さくなった。さらにoxipngを追加で適用すると、合計1,283,130バイトとなり、全体として元の約71.2%の削減に達した。つまり、oxipngの追加によって、さらに128,747バイトの削減が実現されたのだ。 処理時間については、pngquantが12ファイル全体で約1.1秒かかったのに対し、oxipngは全体で約4.4秒を要した。これは、1グループ（3ファイル）あたり約0.78秒から1.51秒の追加処理時間となり、記事のタイトルにある「約1秒の追加」という表現に相当する。

削減効果は画像のカテゴリーによって差が出た。元のファイルサイズに対する削減率で比較すると、pngquantとoxipngの二段階圧縮によって、特に写真で大きな効果が見られた。写真グループは、pngquant単体で66.3%削減されたものが、oxipng追加で70.3%まで削減され、4.0ポイントの追加削減となった。これは具体的なバイト数で81,767バイトの削減に相当する。アイコン、スクリーンショット、イラストの各グループでも追加削減はあったが、写真ほど大きくはなかった。アイコンは3.1ポイント（5,677バイト）、スクリーンショットは1.9ポイント（36,305バイト）、イラストは1.6ポイント（4,998バイト）の追加削減だった。この結果は、写真のような複雑な色やグラデーションを持つ画像の方が、oxipngのような可逆圧縮で最適化できる余地が大きいことを示唆しているかもしれない。

これらの結果を踏まえると、実務でoxipngを導入するかどうかの判断は、削減効果と処理時間のバランス、そして開発・運用プロセスによって変わってくるだろう。例えば、写真のようにoxipngによる削減効果が大きく、8万バイト以上の削減が1.5秒程度の追加処理時間で得られるのであれば、導入は非常に有効だと考えられる。しかし、アイコンやイラストのように削減効果が数千バイト程度で、そのために1秒前後の追加処理時間が発生する場合、頻繁にビルドが実行されるような開発ワークフローでは、処理時間が無視できなくなる可能性がある。このような場合は、全てのコミットでoxipngを実行するのではなく、リリース時のみに実行するなど、運用方法を工夫する必要がある。もし一度だけデプロイしてしまえば後はCDNなどにキャッシュされるようなケースであれば、タイプする手間もほとんどかからないため、導入しても問題ないだろう。

他の圧縮ツールとの比較も行われた。zopflipngという別のツールも検証されたが、pngquantの後に追加しても削減効果はわずか（0.0〜0.5ポイント）であり、しかも1グループあたり3.5秒から19.5秒という非常に長い処理時間がかかった。このため、今回の検証目的においては、zopflipngは推奨されないという結果になった。ただし、これはzopflipngが劣るアルゴリズムであるということではなく、主にDeflateストリームの再圧縮に重点を置いているため、すでにpngquantで最適化された画像に対しては追加の削減余地が少なく、かつより計算コストが高いという特性があるためと考えられる。

ツールの実行順序も重要である。今回の検証では、もしoxipngをpngquantの「前に」実行した場合、pngquant単独で圧縮した場合と比べて、ファイルサイズにほとんど差がなかった。このことから、oxipngのような可逆圧縮ツールは、pngquantのような非可逆圧縮ツールで一度大きく圧縮された後に適用することで、最も効果を発揮することがわかる。つまり、まずpngquantで非可逆圧縮を行い、その後にoxipngで可逆圧縮を行うという順序が推奨される。

さらに、ImgIngというブラウザベースのバッチ圧縮ツールで生成されたPNG画像に対してもoxipngを試したところ、興味深い結果が得られた。このツールで出力された12枚の画像のうち、7枚は元の画像よりもファイルサイズが大きくなり、1枚は元のサイズのままだった。しかし、残りの4枚のパレットPNG画像に対してoxipngを適用したところ、元のImgIng出力から30%から45%もの大幅なファイルサイズ削減が見られた。これは、たとえ別のツールで一度圧縮された画像であっても、特にパレットPNGのような画像タイプでは、oxipngによってさらに非可逆圧縮なしでファイルサイズを小さくできる可能性を示している。

結論として、今回の検証からは、pngquantで最初に非可逆圧縮を行い、次にoxipngで可逆圧縮を行うという二段階のプロセスが、PNG画像の効果的なファイルサイズ削減に最も適しているという結果が得られた。zopflipngは、今回の用途では処理時間のコストに対して削減効果が低いため、導入は見送るべきだろう。もし開発ワークフローに圧縮処理を組み込むのであれば、全てのファイルにoxipngを適用するのではなく、変更されたファイルのみを対象とすることで、処理時間のオーバーヘッドを最小限に抑える工夫も考えられる。ただし、この検証は12枚の画像という限られたデータセットと、特定の環境での結果であり、画像品質の比較は含まれていないため、自身のプロジェクトで導入する際には、実際の画像や環境で同様の検証を行うことが重要だ。