ImageOptimで実際にWebサイトを最適化してみた

by ysawa

ImageOptim使っていますか?

ImageOptim は、画像最適化ツールで、画像に付いた余計なタグを取り除いてくれたり、画質の劣化無しで画像を最適化するツールです。これによって、Webサイトや、スマホアプリの容量を大幅に小さくすることができます。

今回は、運営しているサイトPublishersで実際に使ってみて、どのくらい効果があったのかを見ていきます。

ImageOptimをインストール

ImageOptim は無料です。ImageOptimのサイトで「Download for free」ボタンを押して、アプリケーションフォルダにドラッグしたらインストール完了です。

残念ながら ImageOptim は、 Mac のツールなのですが、Windows や Linux でも使える最適化ツールはあるようです。

開いてみる

こんな外見です。ここに、最適化したい画像ファイルをドラッグすると自動的に最適化してくれます。

僕の設定

JPEG は、再度保存し直す場合、劣化する可能性がやはり否定できないので、 JPEGOptim などに関しては、チェック項目を外してあります。メニューから「Preferences…」で設定することができます。

最適化中

画像が入ったフォルダを丸ごとドラッグしてみると、このようになります。

最適化中は、CPUファンがうなりをあげます。Activity Monitorは、このようになります。

しばらく、 CPU のコア数が少ないとしばらく作業ができなくなります。

結果どうなるか

画像の容量が、半分近くに最適化されることがよくあります。 2D のゲームアプリなどは、画像がアプリの大半を占めるでしょうから、全ての画像を最適化してからストアに申請するとよいかもしれません。

Publishersで使ってみた

では、実際のWebアプリ Publishers で見ていくことにします。

ImageOptim適応前

トップページを計測対象とし、最適化前の Chrome の Timeline パネルは、以下のようになりました。

ヒゲの長さがローディングやレンダリングにかかった時間です。現時点で、十分速いのであまりテコ入れする必要なさそうな感じですね。

むしろ、大したこともしていないはずの Scripting に時間がかかっているので、題材として扱うサイトとしては間違っているかもしれません。

ImageOptim適応中

Publishersの画像を全て、ImageOptimにぶち込みました。半分以下になる画像多数ありました。全体では 301 ファイルが最適化され 5.7MB 小さくなりました。

static/img/manage/gritter-light.png     | Bin 4899 -> 2738 bytes
static/img/manage/gritter-long.png      | Bin 6299 -> 3624 bytes
static/img/manage/gritter.png           | Bin 4880 -> 2759 bytes
static/img/manage/icon-charge.png       | Bin 1405 -> 684 bytes
static/img/manage/icon-creditcard.png   | Bin 470 -> 214 bytes
static/img/manage/icon-info.png         | Bin 44296 -> 416 bytes
static/img/manage/icon-merit.png        | Bin 2548 -> 1634 bytes
static/img/manage/icon-pay-magazine.png | Bin 586 -> 243 bytes
static/img/manage/icon-publishers.png   | Bin 1631 -> 766 bytes
static/img/manage/icon-subscribed.png   | Bin 2273 -> 1318 bytes
static/img/manage/icons/16/book.png     | Bin 1305 -> 591 bytes
static/img/manage/icons/16/cabinet.png  | Bin 1318 -> 619 bytes
static/img/manage/icons/16/calendar.png | Bin 1374 -> 720 bytes
static/img/manage/icons/16/client.png   | Bin 1245 -> 669 bytes
static/img/manage/icons/16/database.png | Bin 604 -> 403 bytes

100分の1以下に圧縮された謎のファイルがあったりします。

ImageOptim適応後

適応後は、以下のようになりました。

あまり、厳密に測ったわけではないのですが、ほとんど、差はみられませんでした。回線状況などによって、この程度の最適化は、誤差の範囲内になってしまうということかもしれません。 Loading が 20ms 程度縮まっていますが、画像とはあまり関係ないところで、たまたま縮まった時間かと思います。

あと、 Chrome は、同時コネクション数が多いのでファイルを並列で取りにいきます。回線容量が大きいような状況ではあまり、メリットがないかもしれません。

ただ、スマホでアクセスしたときは、多少なりとも差が出てくるような気がします。スマホで回線細くした上で計測すればよかったと反省しております。

まとめ

あまり、説得力のある結果が出ませんでしたが、これが、スマホアプリやWebでもスマホ上のブラウザとかだと、もっと、成果が体感できたかもしれません。

いろいろ、実験するときの反省材料が出たので、 Web でのターンアラウンドタイムはこうやって計測するともっと正確だよとかあればご教授ください。

この記事を読んだあとに

ysawa

エヌ次元株式会社代表取締役
東京工業大学工学部計算工学専攻卒業
符号理論の応用に関する研究
在学中よりフリーランスエンジニアとして活動
「持続可能な設計」を得意領域とする
会社設立後も設計からアプリ制作や
Webサイトのコーディングまでを幅広く担当
セキュリティスペシャリスト

 このブログについて

このブログは、プログラマやエンジニアのためになる情報を垂れ流しています。
ちょっと異端的なものも含まれているかもしれません。