現在の案件でWebサイトの高速化が課題となっています。
Page load time also has a significant impact on mobile users’ experience.My team at Etsy found an increased bounce rate of 12% on mobile devices when we added 160KB of images to a page.
（http://radar.oreilly.com/2014/01/web-performance-is-user-experience.html より抜粋）
モバイルにおいて、160KBの画像を追加したことで直帰率が12%も上がってしまったEtsyの例があります。
案件でもパフォーマンス向上対策のひとつとして画像のsprite化とbase64化をやっているので、覚書としてこちらにまとめます。
画像のsprite化
複数の画像を一枚の画像にまとめたもののことをsprite画像といいます。
それをcssでbackground-imageで画像の指定をして、background-positionでその画像の中のどの画像を使うか指定をします。
.header_menu {
background-image: url('sprite_01.png');
}
.header_menu.news {
background-position: 0 0;
}
.header_menu.about {
background-position: 0 -54px;
}
sprite化の良いところ・悪いところ
画像を取得するサーバーへのリクエスト回数が減ることで表示速度の向上ができます。
sprite画像を作るのが面倒というデメリットは、gulp.spritesmithを使って自動で生成するようにすれば問題ありません。
ただ、sprite画像の読み込みが終わるまで表示されないので、読み込みが終わるまでそのエリアがボタンだと気づかない場合が多いので、ボタンなどの背景には向きません。
（メモ：gzipを使えば、spriteと変わらない。
sprite化では、grunt-spritesmithによくお世話になっています。
https://github.com/Ensighten/grunt-spritesmith
画像のbase64化
画像データをを64種類の英数字を使って表現する形式にすること。
画像をbase64にエンコードして、その文字列をCSSに入れることで、中に画像を埋め込むことができます。
.kitty-img {
background-image: url('img/kitty.png);
}
↓↓↓↓↓↓↓↓↓↓↓↓↓↓
.kitty-img {
background-image: url('○○ここにbase64化した文字列○○');
}
base64化の良いところ・悪いところ
→画像がCSS内にあるので、画像を取得するためのサーバーへのリクエスト回数が減り、負荷が減ります。
sprite画像とは違い、CSSの読み込みが終わると画像の読み込みも終わるので、
最初から画像が表示される必要のあるボタンなどの背景画像にはよいらしいです。
しかし、CSSが重くなり読み込みの時間が長くなるので、キャッシュが無い時の初期表示が遅くなってしまいます。
いつもbase64化の際、こちらでお世話になっています。
http://blog.thingslabo.com/archives/000058.html
画像を劣化せずに圧縮できるサービス
https://tinypng.com/
.jpgと.pngをドロップするだけで簡単に圧縮してくれます。
よくお世話になっています。
http://mozjpeg.codelove.de/
（jpgだけですが）
実案件にて使用例
・大規模サイト
・多言語でサイト展開
・ベースを本社でつくり、サイト運用は現地のスタッフに任せている
今の案件では、画像は圧縮（gulp-imagemin※）しており、
アイコン画像はそれからさらにbase64化しています。
※https://www.npmjs.com/package/gulp-imagemin
タイトルロゴ画像やボタン画像については、sprite化しています。
本来ならばボタン全てbase64化した方がいいのかもしれませんが、
spriteしたほうが日本語から翻訳する際にデザイナーさんも一気に作業できる点がよいのかもしれません。
とりあえずここまで。