web-dev-qa-db-ja.com

CSSスプライト:面倒な価値はありますか?

私は仕方がありませんが、CSSスプライトが非常に使いすぎているのではないかと思います。

まず、すべての画像を1つのファイルにまとめると、非常に多くの空きスペースができます。画像ファイルをあまり大きくするべきではありませんが、Sprite.png自体は一般的に(small1.png+small2.png... +[これらの個々の接続すべてのHTTPヘッダー])。

次に、画像ファイルを本質的に小さくしたり圧縮したりする可能性のある個々の画像属性は、Sprite.pngで失われます。たとえば、グレースケールではないグレースケール画像Sprite.pngはグレースケールではなくなりました。

第三に、これらすべてのCSSブロックが合計されます。以下が旧式の<img src=small1.png>に追加してスプライトに変換する必要がある場合...

#small1 { background:url(Sprite.png) n n; height:n; width:n; } id=small1 height=n width=n

...その後、12個のスプライトが追加のペイロードで1KB(および変更)に相当します(画像自体を超えて)。 「大したこと!」と言う前に、ここで小さなSprite対応の画像について話していることを思い出してください。1KBは比較的重要な意味を持ちます。また、 CSSはあなたに忍び寄ることができます

実は、これは私の簡単な記事です。この「最適化」は馬鹿げているのではないでしょうか。

私はスプライトを使うべきではないと言っているのではありません。 「1つのリクエストが常に多くのリクエストよりも優れている」以上のことが必要だと思います。特に、HTTPキープアライブと最適化されたWebサーバーとファイルシステムを使用している場合。そして、すべてのことを考慮し、そのようなありふれた詳細に焦点を当てる点は何ですか?一方、Webアプリケーションでは、ほぼすべての非効率的な点がありますか?

1
dogglebones

TLDR;状況によって異なりますが、価値があると思います。

1つのリクエストが多くのリクエストよりも優れているとは限りませんが、スプライトが正しく使用されている場合、通常は価値のある最適化です。

なぜ空きスペースがあるのですか?スプライト内の要素間をピクセル単位でパディングすることで、ほとんど問題を回避できます。また、Spriteの実際の保存はキャッシュされるときに行われるため、ユーザーが移動するたびに複数の背景画像がリクエストおよびキャッシュされるのではなく、一度キャッシュされると1つのファイルが多くのページで使用されることに注意してください。

画像の最適化に関しては、それは本当ですが、おそらく十分なグレースケール画像がある場合は、2つのスプライトファイルを検討しますか?

意味的に意味のない<img>要素内にあるコンテンツにはスプライトを使用しないでください。他の要素をスタイリングするときにスプライトを使用する必要があるため、background-urlは常に必要でした。

2
Toby