web-dev-qa-db-ja.com

個々の画像ではなくスプライトシートを使用するのはなぜですか?

一部のサイトで気付いたのは、小さな画像がたくさん含まれている1つのBIIIIIIIG画像を使用し、個々の画像を使用するのではなく、CSS _background-position_を使用して各画像の座標を定義していることです。

これが私がいるところです:

大きなスプライトシートを使用する場合の短所

  • 小さな画像を1つでも表示するには、大きな画像を読み込む必要があります
  • 各画像のクラスを含む長いスタイルシートを作成(または生成)する必要があります
  • 多くのクラス定義でCSSが乱雑になると、パフォーマンスに影響を与える可能性があります
  • 1つの画像が変更された場合(または別の画像が追加された場合)、画像とそれに関連付けられたCSSの両方でキャッシュの問題が発生する可能性があります
  • 適切なスタイリング(display: inline-block; width: 32px; height: 32px; background-image: url('spritesheet.png');)を備えた_<div>_が必要であり、これによりさらに別のクラスがミックスに追加されます。
  • 今は思い出せないことがたくさんあります。

大きなスプライトシートを使用するための長所

  • ...えーと...まだありません。

実際、ここでプロに近づく唯一のことは、シートを個々の画像に分割すると、結果のフォルダーが3Mbを占めることですディスク上(各ファイルが100バイト未満であり、割り当てがあるため)サイズは4k)。実際のファイル自体はシートとCSSの半分以下のサイズで出力されるため、HTTPリクエストのオーバーヘッドがあっても大幅なスペース節約があります

基本的に、私の質問は次のとおりです。個々の画像に大きなシートを使用することについて、誰かプロがいますか?

28

目的は、HTTPリクエストを減らすことです。さらに、圧縮されたスプライトの重量が元の画像よりも軽くなる場合があります。

最近、透明なグラデーション(白からトランス、グレーからトランス)が多く、透明な画像に白黒のウェブサイトがありました。それらをすべてスプライトに入れ、pngの色を8に減らすことで、スプライトのファイルサイズを元の画像よりも小さくすることができました(ちょうど...約0.5%の節約でした)。 HTTPリクエストの数を10から1に減らすことで、サイトの読み込みが速くなります(最初の接続から転送されたすべてのデータまでの時間を測定する場合)。

その場合、測定可能な増加が見られました。

特にPNG圧縮を使用していない場合は、物事を台無しにして、必要以上に大きなスプライトになってしまう可能性があることに同意します。

これを投稿してから2年後の注意– SSLを使用している場合は、SPDYを調べる必要があります(さらに2年後の私のメモでは、SPDYではなくHTTP 2.0について言及します!)SPDYはスピリットの利点を否定します。

19
Rich Bradshaw

短所としてあなたが言ったことの多くは、実際にはまったく短所です。

1つの大きな画像を読み込むと、画像に必要なさまざまな属性(カラーテーブル、mimeタイプなど)の1つだけが含まれます。例:プログレッシブjpg形式を使用している場合、1つのスプライトシートで画像を1回スキャンできます。多くの場合、読み込み時間が大幅に短縮されます)100の異なるファイルに同じ情報を含める代わりに、全体像のファイルサイズを小さくします。

また、httpリクエストは1つだけです(スプライトシートの数に応じて2つ)が、適切に処理された場合、ページロードごとに1つだけです。

CSSでbg画像を使用している場合は、すでにcssセレクターを作成していますなので、余分な作業は必要ありません。URLをコピーして貼り付けるだけです。

Ctrl + F5を押しても解決できないスプライトシートのキャッシュの問題は発生していません。

いずれの場合も、適切なスタイルのdivは必要ありません。これは<img>タグ置換方法ではなく、主にbgイメージに使用されます。ボタンやアイコンセットのように。

この方法の長所は短所をはるかに上回ります。その証拠は、非常に多くの開発者によって使用されていることです。それがひどい方法だったとしたら、誰もそれを手に入れなかったでしょうし、それが最初に使用されたときに誰かがすでにこれらの問題を提起していたでしょう。

誰かがもっと追加する必要がある場合は、恥ずかしがらないでください:)

9
Kyle

グーグルはそれを説明します ここ 。基本的に、ページの読み込み時間を短縮する必要があります。新しい接続を初期化するたびに、多少の遅延が発生します。場合によっては、データ転送サイズを削減し、ページの読み込み時間を短縮することもできます。めったにまたはすべて一緒に変更されない画像(テーマ)に適しています。次に、ブラウザはキャッシュされた画像を使用でき、すべての画像を1つずつ変更するのではなく、1つのファイルのみをチェックして変更を確認する必要があります。

4
Cougar

スプライトシートはめちゃくちゃです。限目。砂糖を塗る必要はありません。彼らはデザイン技術の大きな後退を示しています。これはおそらく、スプライトシートの使用が好きなのが古い学校のゲーム開発者だけである理由を説明しています。スプライトシートの償還品質は1つだけで、読み込みが少し速くなります。それ以外はゴミです。設定する悪夢は言うまでもありません。

単純な歩行サイクルを実行するためだけに500行のコードを含める必要があるのは、どの世界で「許容できる」のでしょうか。うまくいけば、一部の賢い人は、flvなどの自己完結型のアルファサポートビデオ形式をドラッグするのと同じくらい簡単な解決策を思い付くでしょうが、それはタブレットでも実行されます...

スプライトの素晴らしさについて大規模なリストを書きたいと思うなら、私はあなたのデザインの仕事がどれほど退屈でなければならないのか疑問に思うだけです。肝心なのは、「ツール」があなたが簡単であるべきことをするのを難しくしているなら、それは良いツールではないということです。それを捨てる。

はい-リクエストの数。

ほとんどのブラウザは、ドメインごとに並行して約2つのリソースしかダウンロードしないため、小さな画像を大量に提供する場合、ユーザーはHTTP要求/応答サイクルの約半分を待つ必要があります。スプライトを使用する場合、それは1つの要求と1つの応答だけです(より大きな応答ですが)。

1
Chowlett

多くの画像がある場合、ブラウザはそれらを1つずつダウンロードする必要があります。ブラウザは限られた数のファイルしか同時にダウンロードできないため、これには時間がかかります。 1つの画像は1つのダウンロードスロットのみを結び、ページのレンダリングを高速化します。

さらに、他の多くのページで使用されている場合、大きなスプライトシートはすでにキャッシュされています。

1
Oded

ブラウザはすべての画像に対してhttpリクエストを実行するだけでよく、数百の画像に対しては実行する必要がないため、これは多くの小さな画像に特に適しています。したがって、クライアントブラウザでのWebの読み込みがはるかに高速になります。

問題は読み込み速度です。 1つのhttpリクエストだけが、数十のリクエストよりもかなり高速です。

1
Packet Tracer

また、CSSをよりクリーンに保つのに役立ちます。たとえば、ボタンにスプライトを使用します(これは、ホバー状態imgのロードに余分な遅延がないことも意味します)

<button type="submit" class="vorige"><span>Vorige</span></button>

button  {display: block; width: 162px; height: 47px; background-position: 0 0;}
button:hover    {background-position: 0 94px; cursor: pointer;}
button:active   {background-position: 0 47px;}
button span {display: none}

.vorige     {background-image: url(../img/button/btn_vorige.png);}
.volgende   {background-image: url(../img/button/btn_volgende.png);}
.verstuur   {background-image: url(../img/button/btn_verstuur.png);}

スプライトがあるため、個別のホバー画像のコードを省略できます。

.vorige:hover   {background-image: url(../img/button/btn_vorige_active.png);}
.volgende:hover {background-image: url(../img/button/btn_volgende_active.png);}
.verstuur:hover {background-image: url(../img/button/btn_verstuur_active.png);}
1
Mirthe