【CSS/Image】フロントで出来るCSSスプライト/DataURIの最適解とは

読了: 約 3 分

画像が膨大な数になったときに、画像の取り扱いについて(png,jpg)をどうするか、
CSSスプライトで何枚用意するのか、一枚に完全に纏めるのか、それともページ単位やカテゴリー単位でもうけるのが
良いのか少し気になったので調べてみました。

概要

1 目的
2 はじめに
3 ページの構造・設計から考える
4 CSS SpliteとdataURIの謎
5 dataURI化するツール
6 まとめ

目的

・フロント側で出来る更新性とパフォーマンスの両面から見た現状の最適な答えを見つけ出すため

はじめに

すでにフロント側で出来る高速化まとめみたいなものを作っていたのですが、
画像のみやCSSだけに焦点を当てたものが少なかったのでさらに調べてみたいと思ったので、
デザイナーさんやマークアップの方向けにまとめてみます。

ページの構造・設計から考える

そもそもCSSスプライトする画像が膨大になったときにカテゴリーやページの種類で分けた方がいいのかどうかという
話ですが、HTTPRequest数を減らすためには画像数は減らした方がいいのですが、管理とのバランスが微妙ですね。
クライアント案件、自社案件でも使い分ける必要があると思いますが、スマホ案件で、自社メディアという想定で書いていきます。

スマホ案件×自社メディア
下記のようなページの構造で作成した場合を想定しています。

ホーム
みんなのタイムラインが見れるページ
じぶんのタイムラインだけが見れるページ
タイムラインにつぶやいたものの詳細ページ
マイページ
ページ独自のボタンを押してくれたユーザーのリストページ
アプリが始まる時に用意するチュートリアル

現在、アプリが開発中であり、変更が都度頻繁に行われる事を想定してファイルを分けています。
運用フェーズになった時に１枚にしてHTTPRequest数を極限までに抑えた状態にしようかなと
考えています。

シンプルなコーポレート等のアイコンと違って、画像のサイズもまちまちなので、ページ単位等で
管理する方が良いかと思います。

firefoxで速度確認していた方の記事を参考にしていただいて
Chromeでのパフォーマンスチェックは、デベロッパーツールで、
Networkを選択して、下の方にあるimagesを選択すれば、imageファイル毎の読み込みスピード・ページのloadスピードが確認出来ます。

datauri化についてはこちらの記事をご参照ください。
Data URIによるHTTPリクエストの削減とYSlowスコア

CSS SpliteとdataURIの謎

CSSスプライトでHTTPRequest数を減らしているなら、わざわざバイナリデータよりデータサイズが3割増えるのに、dataUri化する必要があるのかという疑問が出てきました。

datauri化したCSSのみをキャッシュさせた方が速いのか、画像もキャッシュさせた方が良いのか。

CSSのみキャッシュさせた方が速いけど、
コレに関しては、作成しているもののフェーズによるかなという結論に至りました。
サービス開発中のものをdatauri化を毎回やっているとそれだけで無駄ですし(sassを使っている方は
compassを使えば速いけど)
そのサービスが運用フェーズに来たとかそういう時にやるのがいいのかなという感じです。

それか、改善するときに追加するためのスプライト画像を用意して、それを毎回やるかとかでしょうか、
いずれにせよdatauri化するのを毎回やるのですが。