画像を css ファイルにエンコードする Base64 uri は、余分なリクエストを防ぎ、ページの読み込みを高速化します。
base64 uri をサポートしていない古い IE をサポートする必要がないと仮定します。
base64 を使用するための最善のポリシーは何ですか。私は 8KB 未満のファイルをエンコードする傾向があります。しかし、なぜすべてをエンコードしないのでしょうか?
画像を css ファイルにエンコードする Base64 uri は、余分なリクエストを防ぎ、ページの読み込みを高速化します。
base64 uri をサポートしていない古い IE をサポートする必要がないと仮定します。
base64 を使用するための最善のポリシーは何ですか。私は 8KB 未満のファイルをエンコードする傾向があります。しかし、なぜすべてをエンコードしないのでしょうか?
すべてを base64 インライン イメージとして送信する場合のいくつかの問題:
今日のポリシーに固執することもできます (HTML などの他の場所から別のファイルとして呼び出す css 内の画像をインライン化しない限り) が、個人的には、適切に構成されたキャッシュ パラメーターとスプライトほど強力ではないことがわかります。
(外部の .css ファイルに画像を埋め込むことについて話していると思います。)
これは次の場合のオプションです。
これは、次の理由で不適切なオプションです。
Base64 URL は余分なリクエストを防ぐ可能性がありますが、関連する画像のサイズも大幅に増加するため、リクエストを 1 つ減らすことによるパフォーマンス上の利点は、合計ダウンロード サイズの余分な重みを上回る可能性があります。
リクエストの数を減らすことは良い考えかもしれませんが、サイトのパフォーマンスに関係する唯一の要因ではありません。実際、ほとんどのサイトでは、リストの比較的下にあると思われます。
さらに、画像や CSS が変更された場合、それらすべてを 1 つのファイルにまとめると、既にサイトにアクセスしたことがあるユーザーにとっては不利になります。キャッシュからすべてを破棄して再読み込みする必要があるからです。それらが別々のファイルである場合、変更時にそれらの 1 つだけを再ロードする必要があります。繰り返しますが、必要なダウンロードの総量を増やしています。
やみくもに最適化しようとしないでください。サイト パフォーマンス分析ツールを使用して、特定のボトルネックがどこにあるかを特定し、最も重要なものを最初に修正します。