一部のサイトで気付いたのは、小さな画像がたくさん含まれている1つのBIIIIIIIG画像を使用し、個々の画像を使用するのではなく、CSS _background-position
_を使用して各画像の座標を定義していることです。
これが私がいるところです:
display: inline-block; width: 32px; height: 32px; background-image: url('spritesheet.png');
)を備えた_<div>
_が必要であり、これによりさらに別のクラスがミックスに追加されます。実際、ここでプロに近づく唯一のことは、シートを個々の画像に分割すると、結果のフォルダーが3Mbを占めることですディスク上(各ファイルが100バイト未満であり、割り当てがあるため)サイズは4k)。実際のファイル自体はシートとCSSの半分以下のサイズで出力されるため、HTTPリクエストのオーバーヘッドがあっても大幅なスペース節約があります。
基本的に、私の質問は次のとおりです。個々の画像に大きなシートを使用することについて、誰かプロがいますか?
目的は、HTTPリクエストを減らすことです。さらに、圧縮されたスプライトの重量が元の画像よりも軽くなる場合があります。
最近、透明なグラデーション(白からトランス、グレーからトランス)が多く、透明な画像に白黒のウェブサイトがありました。それらをすべてスプライトに入れ、pngの色を8に減らすことで、スプライトのファイルサイズを元の画像よりも小さくすることができました(ちょうど...約0.5%の節約でした)。 HTTPリクエストの数を10から1に減らすことで、サイトの読み込みが速くなります(最初の接続から転送されたすべてのデータまでの時間を測定する場合)。
その場合、測定可能な増加が見られました。
特にPNG圧縮を使用していない場合は、物事を台無しにして、必要以上に大きなスプライトになってしまう可能性があることに同意します。
これを投稿してから2年後の注意– SSLを使用している場合は、SPDYを調べる必要があります(さらに2年後の私のメモでは、SPDYではなくHTTP 2.0について言及します!)SPDYはスピリットの利点を否定します。
短所としてあなたが言ったことの多くは、実際にはまったく短所です。
1つの大きな画像を読み込むと、画像に必要なさまざまな属性(カラーテーブル、mimeタイプなど)の1つだけが含まれます。例:プログレッシブjpg形式を使用している場合、1つのスプライトシートで画像を1回スキャンできます。多くの場合、読み込み時間が大幅に短縮されます)100の異なるファイルに同じ情報を含める代わりに、全体像のファイルサイズを小さくします。
また、httpリクエストは1つだけです(スプライトシートの数に応じて2つ)が、適切に処理された場合、ページロードごとに1つだけです。
CSSでbg画像を使用している場合は、すでにcssセレクターを作成していますなので、余分な作業は必要ありません。URLをコピーして貼り付けるだけです。
Ctrl + F5を押しても解決できないスプライトシートのキャッシュの問題は発生していません。
いずれの場合も、適切なスタイルのdivは必要ありません。これは<img>
タグ置換方法ではなく、主にbgイメージに使用されます。ボタンやアイコンセットのように。
この方法の長所は短所をはるかに上回ります。その証拠は、非常に多くの開発者によって使用されていることです。それがひどい方法だったとしたら、誰もそれを手に入れなかったでしょうし、それが最初に使用されたときに誰かがすでにこれらの問題を提起していたでしょう。
誰かがもっと追加する必要がある場合は、恥ずかしがらないでください:)
グーグルはそれを説明します ここ 。基本的に、ページの読み込み時間を短縮する必要があります。新しい接続を初期化するたびに、多少の遅延が発生します。場合によっては、データ転送サイズを削減し、ページの読み込み時間を短縮することもできます。めったにまたはすべて一緒に変更されない画像(テーマ)に適しています。次に、ブラウザはキャッシュされた画像を使用でき、すべての画像を1つずつ変更するのではなく、1つのファイルのみをチェックして変更を確認する必要があります。
スプライトシートはめちゃくちゃです。限目。砂糖を塗る必要はありません。彼らはデザイン技術の大きな後退を示しています。これはおそらく、スプライトシートの使用が好きなのが古い学校のゲーム開発者だけである理由を説明しています。スプライトシートの償還品質は1つだけで、読み込みが少し速くなります。それ以外はゴミです。設定する悪夢は言うまでもありません。
単純な歩行サイクルを実行するためだけに500行のコードを含める必要があるのは、どの世界で「許容できる」のでしょうか。うまくいけば、一部の賢い人は、flvなどの自己完結型のアルファサポートビデオ形式をドラッグするのと同じくらい簡単な解決策を思い付くでしょうが、それはタブレットでも実行されます...
スプライトの素晴らしさについて大規模なリストを書きたいと思うなら、私はあなたのデザインの仕事がどれほど退屈でなければならないのか疑問に思うだけです。肝心なのは、「ツール」があなたが簡単であるべきことをするのを難しくしているなら、それは良いツールではないということです。それを捨てる。
はい-リクエストの数。
ほとんどのブラウザは、ドメインごとに並行して約2つのリソースしかダウンロードしないため、小さな画像を大量に提供する場合、ユーザーはHTTP要求/応答サイクルの約半分を待つ必要があります。スプライトを使用する場合、それは1つの要求と1つの応答だけです(より大きな応答ですが)。
多くの画像がある場合、ブラウザはそれらを1つずつダウンロードする必要があります。ブラウザは限られた数のファイルしか同時にダウンロードできないため、これには時間がかかります。 1つの画像は1つのダウンロードスロットのみを結び、ページのレンダリングを高速化します。
さらに、他の多くのページで使用されている場合、大きなスプライトシートはすでにキャッシュされています。
ブラウザはすべての画像に対してhttpリクエストを実行するだけでよく、数百の画像に対しては実行する必要がないため、これは多くの小さな画像に特に適しています。したがって、クライアントブラウザでのWebの読み込みがはるかに高速になります。
問題は読み込み速度です。 1つのhttpリクエストだけが、数十のリクエストよりもかなり高速です。
また、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);}