スプライトの主な目的は、ページ上のグラフィック要素に対してサーバーに対して行われるhttpリクエストを減らすことですか?または、できるだけ多くの要素をスプライトに合わせてみてください。
私が求めているのは、スプライトが大きすぎるのはいつかということだと思います。
スプライトの主な目的は、ページ上のグラフィック要素に対してサーバーに対して行われるhttpリクエストを減らすことですか?または、できるだけ多くの要素をスプライトに合わせてみてください。
私が求めているのは、スプライトが大きすぎるのはいつかということだと思います。
ユーザーがページを使用する前にファイルのダウンロードを待たなければならない場合、サイズが大きすぎます。
スプライト画像タイプにPNGを使用している場合、各行は通常、他の行とは独立して圧縮(収縮)されることを覚えておくと便利です。
したがって、スプライトの数と画像サイズのバランスをとるために、圧縮を利用するために、類似したスプライトを垂直方向ではなく水平方向に並べて配置してみてください。
PNGは、予測値(前の行と同じ行の前のピクセルに基づく)と実際の値の間のデルタのみを格納する「予測子」もサポートします。
さまざまなPNG予測子の圧縮設定を設定できる(または自動的に最適化できる)優れた画像エディターを見つけて、画像に最適な設定を見つけてください。
スプライトの主な目的は、ページ上のグラフィック要素に対してサーバーに対して行われる http 要求を減らすことですか?
はい、小さな画像に対する多くのリクエストを避けたいと考えています。それらを 1 つのスプライトに結合すると、1 つの http リクエストで取得できます。
スプライトが大きすぎるのはいつですか?
これは実際には、確認したいすべてのリクエストの合計です。スプライトが大きすぎる唯一の原因は、その部分の合計 (まさにスプライトと同じです) が大きすぎて開始できない場合です。
スプライトに関しては、このブログ投稿の下にあるメモリ使用量に関する議論も必ずチェックしてください:http: //blog.mozilla.com/webdev/2009/03/27/css-spriting-tips/
私のアドバイス:
大きな問題なく、すべての小さな静的デザイン要素を1つのマスターイメージにパックできます。
もちろん、Webサイトに10メガピクセルの写真がある場合、それらをまとめると狂気になります。
必須の UI 要素以外を含めると、CSS スプライトが大きすぎます。これらはアイコンやロゴなどの小さな補足画像で、圧縮によって品質があまり損なわれないものです。これらの画像はすべて個別に読み込まれるため、個別に要求するよりも悪いことはありません。読み込みに時間がかかりすぎる場合、問題はスプライトに依存するのではなく、画像を適切に圧縮することに依存しています。
はい、主な目的はリクエストを減らすことです(したがって、読み込み時間も短縮されます)。もう 1 つの利点は、1 つのイメージが正しくキャッシュされることだけを気にする必要があることです。ヒント: PNG 画像を使用すると、圧縮によって大きな白い (「空の」) 領域が最適に処理されます。
Google マップは [256x256] ピクセルの画像を使用します。