[Front-End General] CSS Sprite, SVG Sprite との今後のつきあい方
おれおれボイラープレートから Compass を正式に外すにあたって、CSS Sprite を今後どう扱うかを検討してまとまったので個人的なまとめ。
Contents
CSS Sprites
高速化テクニックと Compass への注目
HTTP/1.1 環境でのパフォーマンス向上を目的に、CSS Sprite による高速化テクニックが注目され、Compass が広く利用される。
このあたりとか。
Retina の普及とその対応
高解像度の Retina ディスプレイ普及に伴い、Compass を拡張するテクニックが求められるようになる。
脱 Compass
bourbon のような CSS mixin (Framework) との組み合わせ利用や Compass の開発停滞の影響もあり、脱 Compass の動きが強まる。
spritesmith のようなツールが利用される。
- Ensighten/spritesmith: Utility that takes sprites and converts them into a stylesheet and its coordinates
- CSSスプライトを生成する「grunt-spritesmith」 – to-R
- CSS Sprite を自動生成する – Gulp で作る Web フロントエンド開発環境 #8 – NET BIZ DIV. TECH BLOG
- [Gulp] [Sketch 3] これからはじめるGulp(24):gulp.spritesmithプラグインでSpriteイメージを作る | UI/UX Design、フロントエンド系の技術に関する備忘録 | whiskers
Web フォント(アイコンフォント)
Web フォント(アイコンフォント)という選択肢も現れた。
このあたりとか。
SVG Sprites
SVG が優れている点は、多色カラーでの表現が可能なこと。
こちらを全面的に参考。
こういったツールを使うよう。
HTTP/2
HTTP/2 の普及が進めば、高速化テクニックが逆の結果を招く。
つまり、SPDY や HTTP/2 環境では、Web ページ内で読み込まれるリソースの数を減らすより、その数が増えても、それぞれのファイルサイズを小さくする方がパフォーマンスが向上する方向に振れるということになりますが、一方で現状の HTTP/1.1 環境で有効とされていた高速化のテクニック、例えば CSS Sprites (CSS スプライト) などが、(それによって画像のファイルサイズが肥大化すると) SPDY や HTTP/2 環境では表示速度を低下させかねないということにもなります。
まとめ
普通の Web サイト構築・納品では、サイト更新に伴う画像ファイルの入れ替えができないと困るというメンテナンス性重視の観点から、CSS Sprite を使わない選択肢があったりする。
こういった流れから、以下の結論となりました。
- CSS Sprite とサヨナラ。素のファイルを利用。
- HTTP/2 化されておらず、今すぐ最適化が必要な案件では SVG Sprite を利用。
今後開発するサイトでは「Sprite を使わず、素の画像ファイルを配置する」という方向性。
(扱う案件の性質を考慮した個人的な見解です。)
補遺
CSS Sprite のメモを発掘したので転載。
- jQuery×HTML5×CSS3を真面目に勉強(5):WebページをRetina対応させるテクニック~実践編 (1/3) – @IT
- #334 Compass & CSS Sprites – RailsCasts
- HTTPリクエスト数削減テクニック2: CSS Sprite編 (1/3):CodeZine(コードジン)
- css – How to remove the hash from Compass’s generated sprite image filenames? – Stack Overflow
- [Sass] Retina対応のスプライトシート用 sass mixin « きんくまデザイン