punypngをためしてみた ― 2009/09/11 23:41
ASCII.jp:30分でできる!Webサイトを高速化する6大原則
の画像最適化でpunypngが紹介されていて、他のツールとの比較で圧倒的すぎるので、ちょっと試してみました。
先ずは元画像も手に入るButterfly
確かにこりゃ圧倒的だ。
次はASCII.jpのサンプル
余談ですが、圧縮前の画像(004_304x100.png)と圧縮後の画像(005_304x100.png)が全く同じもので、しかも圧縮前の18,356バイトでもなく圧縮後の14,888バイトでもない16,188バイトと何をどうしたのかさっぱり分からないサンプルで、仕方ないのでそれを使いました。
こちらは大きな差はつきませんでしたが、確かに一番優秀です。
ちなみにどちらのテストでも、OptPNGは「-zc1-9 -zm1-9 -zs0-3 -f0-5」(1080通り)のオプションを指定してます。
驚きなのが処理速度で、Webアプリにも関わらずpunypngはPNGOutとほとんど処理時間が変わりませんでした。一方でOptPNGは(1080通り)のオプション指定のせいもあって4倍くらい時間がかかりました。
ついでにJpegも以前テストした画像で試してみましたが、自動的に最小サイズになるように選択されるのかプログレッシブで返ってきました。ベースラインかプログレッシブかを選べないのは残念です。
サイズは101,933バイトで、JTBの方が18バイト小さいという結果になりました。
Jpegに関してはベースラインを選べないというのもありますし、手持ちのツールでいいかなと。
私はGifの最適化ツールは持ってないのですが、どうせなのでGif画像(1)も試してみました。
結果は23,402バイトが20,178バイトに。
<追記>
Gifsicle(-O2)と比較してみました。(画像(2)、(3)は公開していません)
以上、punypngとGifsicleでサイズに違いはみられませんでした。
ということで、punypngはPNG画像の最適化のみ利用価値があると考えます。
ただし、ファイルサイズの上限があるのでなんでもというわけにはいきませんけれどね。
</追記>
こりゃ参った。速いし、よく縮むし、Webサービスでなく通常のアプリケーションにしてリリースして欲しいです。
参考
Webで使用する画像ファイルの最適化 - maruko2 Note.
の画像最適化でpunypngが紹介されていて、他のツールとの比較で圧倒的すぎるので、ちょっと試してみました。
先ずは元画像も手に入るButterfly
Butterfly | 105,332 | |
---|---|---|
PNGOut | 97,106 | 92.2% |
OptPNG | 102,277 | 97.1% |
punypng | 62,331 | 59.2% |
確かにこりゃ圧倒的だ。
次はASCII.jpのサンプル
余談ですが、圧縮前の画像(004_304x100.png)と圧縮後の画像(005_304x100.png)が全く同じもので、しかも圧縮前の18,356バイトでもなく圧縮後の14,888バイトでもない16,188バイトと何をどうしたのかさっぱり分からないサンプルで、仕方ないのでそれを使いました。
004_304x100.png | 16,188 | |
---|---|---|
PNGOut+cPNGC | 15,922 | 98.4% |
OptPNG+cPNGC | 15,380 | 95.0% |
punypng | 14,986 | 92.6% |
こちらは大きな差はつきませんでしたが、確かに一番優秀です。
ちなみにどちらのテストでも、OptPNGは「-zc1-9 -zm1-9 -zs0-3 -f0-5」(1080通り)のオプションを指定してます。
驚きなのが処理速度で、Webアプリにも関わらずpunypngはPNGOutとほとんど処理時間が変わりませんでした。一方でOptPNGは(1080通り)のオプション指定のせいもあって4倍くらい時間がかかりました。
ついでにJpegも以前テストした画像で試してみましたが、自動的に最小サイズになるように選択されるのかプログレッシブで返ってきました。ベースラインかプログレッシブかを選べないのは残念です。
サイズは101,933バイトで、JTBの方が18バイト小さいという結果になりました。
Jpegに関してはベースラインを選べないというのもありますし、手持ちのツールでいいかなと。
私はGifの最適化ツールは持ってないのですが、どうせなのでGif画像(1)も試してみました。
結果は23,402バイトが20,178バイトに。
<追記>
Gifsicle(-O2)と比較してみました。(画像(2)、(3)は公開していません)
OPTPiX | punypng | Gifsicle | |
---|---|---|---|
画像(1) | 23,402 | 20,178 | 20,178 |
画像(2) | 80,098 | 78,921 | 78,921 |
画像(3) | 112,660 | 109,864 | 109,864 |
ということで、punypngはPNG画像の最適化のみ利用価値があると考えます。
ただし、ファイルサイズの上限があるのでなんでもというわけにはいきませんけれどね。
</追記>
こりゃ参った。速いし、よく縮むし、Webサービスでなく通常のアプリケーションにしてリリースして欲しいです。
参考
Webで使用する画像ファイルの最適化 - maruko2 Note.
Yahoo!ニュースの表示が高速化 ― 2009/05/28 19:44
新しいテクを使ってるかのように見えて、実はほとんどが古いテクだったと、ヤボを承知で突っ込んでみた。
「Yahoo!ニュース」の表示速度が3~5倍に、そのからくりは……:記事の芽
使ってみたくて去年いろいろやってみたのですが、絵心ないもので(デザインセンスも)挫折しました。orz
参考
CSS Spriteを活用しよう | DesignWalker
独学で極める “Webデザイン”の技と心:第10回 CSS Spritesでサイトを高速化|技術評論社
CSS Spritesのすべて - 技術解説、採用事例、ツールリンク | マイコミジャーナル
1枚の画像を切り出すテクニックCSS Sprite、便利ツール登場 | マイコミジャーナル
少なくともPhotoshopの減色が糞でOptpixがイケてるのは99年時点でも常識だったと思いますよ。
証拠:Spec. List
私の記憶に間違いなければ、Photoshop買ったのが95年後半か96年前半で減色の糞さ加減にあきれてネットを探してたら「pag1teto」(当時の名前は違ったかも)とかが既にあって、Photoshopの減色の糞さ加減を叩いてたくらい古い話。
お暇ならどうぞ→画像を減色してファイルサイズを小さくする
お暇ならどうぞ→画像を劣化させずにファイルサイズを小さくする(PNG)
(最後のワザとやらはまだぬるいわけで……約27%削ってます)4.7%だわw
追記:間違えて悔しいwのでYahoo!ニュースで実際にやってみた。
ranking.png 696→ pngrewrite + PNGOUT + cPNGC で 496 約28.7%減
ranking.png 696→ pngrewrite + PNGOUT で 509 約26.9%減
yn_gnavi_sprite.png 3,091→ pngrewrite + PNGOUT + cPNGC で 2,820 約8.8%減
yn_gnavi_sprite.png 3,091→ pngrewrite + PNGOUT で 2,833 約8.3%減
ついでにJpegも
20090529-00000003-vari-ent-thum-000-small.jpg 17,924 → Progressive Jpeg で 17,229 3.8%減
というわけで、最後のワザとやらは最適化がまだぬるいと。
他にもお暇なら「画像を劣化させずにファイルサイズを小さくする」シリーズ(笑)。
画像を劣化させずにファイルサイズを小さくする(Jpeg)
画像を劣化させずにファイルサイズを小さくする(Progressive Jpeg)
(アサブロの)テンプレートの画像が最適化されてなくて、転送量的にプロバイダとしてどうよ?と(それぞれの記事で)突っ込んでるのですが、今年3月から管理画面に表示されるようになったランキングのコメントに
「アクセスされ過ぎです。ああ、サーバへの負担がぁ・・・」
などと表示してる余裕があるなら、テンプレートの最適化くらいすればいいのにw
ちょっと補足(カッコ書き)を追加
計算対象を間違えてたので修正と追記
cPNGCのバグなのか?今回のPNG8で透明色が指定されている場合、透明色の情報を失うようなので処理から外して最適化したバイト数に変更しました。(cPNGCの仕様。未対応とデカデカとBlastPNGに書いてあるのになんで気が付かないんだか orz)
透明色の指定があるのにcPNGCで処理してたので、処理しないようにしたものに訂正。
「Yahoo!ニュース」の表示速度が3~5倍に、そのからくりは……:記事の芽
一つめのワザは複数枚の画像を1枚にまとめる「CSS Sprite」の採用です。広まり始めたのが2007年9月28日なのでこれは古くはないですね。YouTubeが採用した時にも話題になりました。
使ってみたくて去年いろいろやってみたのですが、絵心ないもので(デザインセンスも)挫折しました。orz
参考
CSS Spriteを活用しよう | DesignWalker
独学で極める “Webデザイン”の技と心:第10回 CSS Spritesでサイトを高速化|技術評論社
CSS Spritesのすべて - 技術解説、採用事例、ツールリンク | マイコミジャーナル
1枚の画像を切り出すテクニックCSS Sprite、便利ツール登場 | マイコミジャーナル
ワザの2つめが画像ファイルの形式の変更です。従来はGIF形式を採用していましたが、これをPNG形式にしました。GIFは特許問題の件があったから、96年時点でよく知られていたと思うのですけど、国際標準化という話で見れば、古いというほどでもないかな。
Portable Network Graphics - Wikipedia
・1996年10月1日 - PNG Version 1.0の仕様リリース。後にRFC 2083として承認。同日、W3Cによる勧告。
(中略)
・2003年11月10日 - 国際標準化(ISO/IEC 15948:2003)。このバージョンは1.2とわずかな差異あり。新規追加チャンクはなし。
・2004年3月3日 - 国際標準化(ISO/IEC 15948:2004)
PNG形式のファイルを生成する際に使うソフトも見直しました。これが3つめのワザです。
(中略)
当初PNG形式もPhotoshopで生成する計画でしたが、別の画像編集ソフトを使ったところ、ファイルサイズが小さくなることを発見。最終的に、ウェブテクノロジというソフトメーカーの「Optpix WebDesigner」を採用しました。128色ではなく64色にしても、グラデーションが不自然にならないことも分かりました。
発見とか茶吹いたwww
少なくともPhotoshopの減色が糞でOptpixがイケてるのは99年時点でも常識だったと思いますよ。
証拠:Spec. List
私の記憶に間違いなければ、Photoshop買ったのが95年後半か96年前半で減色の糞さ加減にあきれてネットを探してたら「pag1teto」(当時の名前は違ったかも)とかが既にあって、Photoshopの減色の糞さ加減を叩いてたくらい古い話。
お暇ならどうぞ→画像を減色してファイルサイズを小さくする
最後のワザが、PNG形式の制御情報(チャンクと呼ぶ)の削除です。PNGファイルには、目には見えませんが本来の画像データ以外に制御情報が含まれています。「Smush.it」という専用ソフトを使うことで、表示上なくてもさしつかえないチャンクを削除。これでOptpix WebDesignerで作った4.67KBのPNGファイルは、4.44KBに。ここでは約4%の削減に成功しました。Smush.it™を使わずとも、PNGOUT(圧縮最適化)、cPNGC(不要チャンク削除)があるじゃないかと……OptiPNGとか結構前からあった気がする……いつからだっけ?(少なくとも2005年にはBlastPNGとセットで使ってたからもっと前のはず)
お暇ならどうぞ→画像を劣化させずにファイルサイズを小さくする(PNG)
追記:間違えて悔しいwのでYahoo!ニュースで実際にやってみた。
ranking.png 696→ pngrewrite + PNGOUT で 509 約26.9%減
yn_gnavi_sprite.png 3,091→ pngrewrite + PNGOUT で 2,833 約8.3%減
ついでにJpegも
20090529-00000003-vari-ent-thum-000-small.jpg 17,924 → Progressive Jpeg で 17,229 3.8%減
というわけで、最後のワザとやらは最適化がまだぬるいと。
他にもお暇なら「画像を劣化させずにファイルサイズを小さくする」シリーズ(笑)。
画像を劣化させずにファイルサイズを小さくする(Jpeg)
画像を劣化させずにファイルサイズを小さくする(Progressive Jpeg)
(アサブロの)テンプレートの画像が最適化されてなくて、転送量的にプロバイダとしてどうよ?と(それぞれの記事で)突っ込んでるのですが、今年3月から管理画面に表示されるようになったランキングのコメントに
「アクセスされ過ぎです。ああ、サーバへの負担がぁ・・・」
などと表示してる余裕があるなら、テンプレートの最適化くらいすればいいのにw
ちょっと補足(カッコ書き)を追加
計算対象を間違えてたので修正と追記
透明色の指定があるのにcPNGCで処理してたので、処理しないようにしたものに訂正。
画像を劣化させずにファイルサイズを小さくする(Progressive Jpeg) ― 2008/11/08 10:02

プログレッシブJpegが何かはIT用語辞典をご覧ください。
プログレッシブJpegでファイルサイズが小さくなる理由はベースラインとプログレッシブをご覧ください。
無劣化でベースラインとプログレッシブを変換するツールはJTBの1.0.07以降※1を使います。
操作は、JTBに対象のファイルをドロップして、「ファイルサイズ増加の時は上書きしない」のチェックを外し※2、プログレッシブ化にチェックしてOKボタンを押すだけです。
逆に非プログレッシブ化にチェックすると、通常の(ベースライン)Jpegに無劣化で変換できます。
-追記-
プログレッシブ化によってファイルサイズが必ず小さくなるわけではありません。
ファイルサイズ重視の場合、手順は次のようになります。
※上書きになりますので、必ず元画像をバックアップしてから作業してください。
- 元の画像がプログレッシブJpegなら、JTBで「ファイルサイズ増加の時は上書きしない」のチェックを外し「非プログレッシブ化」をチェックしてベースラインに変換
- JTBで「プログレッシブ化」「非プログレッシブ化」のチェックを外して
「ファイルサイズ増加の時は上書きしない」「最適化」「エクストラ・マーカー削除」をチェックして最適化 - carmineで最適化 (画像を劣化させずにファイルサイズを小さくする(Jpeg)を参照)
- JTBで「ファイルサイズ増加の時は上書きしない」「プログレッシブ化」をチェックして最適化 (この場合、プログレッシブ化でサイズが大きくなるファイルは上書きされません)
では、ファイルサイズを比較してみましょう。例によってアサブロテンプレートから(笑)。 クリックで拡大します。
オリジナル | 127,178 |
ベースライン:JTB→carmine | 105,472 |
プログレッシブ化:JTB | 101,915 |
冒頭のいろいろ思うところといった件ですが、互換性と負荷なんですよね。
今更表示できないブラウザはないと思いますが、ブラウザ以外で使うとなると表示できない場合がないといえません。
負荷も、10分割されてると10倍の表示負荷がかかります。1枚、2枚なら10年前のパソコンでも問題になりませんが、100枚だと1000枚の画像を表示する負荷に匹敵します。
もっとも、ブログで使うテンプレート画像としては、ナローバンドの環境を考えるなら、むしろプログレッシブを使うべきと思う訳で
転送量的にプロバイダとしてどうよ?
と前回と同じ結びになるのでした(笑)。
最近のコメント