CSS スプライトがサイトのパフォーマンスを向上させる方法を理解しようとしています。
単一の画像の合計サイズが小さい画像の合計である場合、いくつかの小さい画像のダウンロードが、小さい画像を保持する単一の画像のダウンロードよりも遅いのはなぜですか?
CSS スプライトがサイトのパフォーマンスを向上させる方法を理解しようとしています。
単一の画像の合計サイズが小さい画像の合計である場合、いくつかの小さい画像のダウンロードが、小さい画像を保持する単一の画像のダウンロードよりも遅いのはなぜですか?
HTTP 要求のオーバーヘッドがこのような影響を与える理由を理解することが重要です。
最も単純な形式の HTTP 要求は、ソケットを開き、開いているソケットで要求を送信し、応答を読み取ることで構成されます。
ソケットを開くために、クライアントの TCP/IP スタックは TCP SYN パケットをサーバーに送信します。サーバーは SYN-ACK で応答し、クライアントはそれに対して ACK で応答します。
したがって、1 バイトのアプリケーション データを送信する前に、少なくともサーバーへの 1.5 ラウンド トリップを待つ必要があります。
次に、クライアントは要求を送信し、サーバーが要求を解析するのを待ち、要求されたデータを見つけて、それを送り返す必要があります。これは、別のラウンド トリップと、サーバー側のオーバーヘッドに加えて、サーバー側のオーバーヘッドがいくらか発生します (低速のサーバーをいくつか見たことがありますが、小さなオーバーヘッドであることが望ましいです)。 ) に実際のデータを送信する時間を加えたものであり、パケットのドロップと再送信につながるネットワークの輻輳がないと仮定すると、これが最良のケースです。
これを回避しなければならない機会があるたびに、そうする必要があります。
最新のブラウザは、関連するオーバーヘッドの一部を削減するために、複数のリクエストを並行して発行します。HTTP リクエストは理論的には同じソケットで実行できるため、状況が少し改善されます。ただし、一般に、ネットワーク ラウンド トリップはパフォーマンスに悪影響を与えるため、避ける必要があります。
サーバーへの往復が少なくなります。6 つの異なる画像に対する 6 つの (たとえば) リクエストの代わりに、1 つのリクエストと同じ画像の 6 回の使用を取得します。ほとんどの場合、サーバーが「最後に要求してから変更されていません」と応答する場合、ネットワーク トラフィックの量が大幅に削減される可能性があります。
複数の画像には複数の http リクエストが必要なためです。Yahoo のパフォーマンス ルール #1: HTTP リクエストを最小限に抑えるを参照してください。
リクエストの数を最小限に抑えることに加えて、画像によっては、それらを分離した場合よりも結合した場合のファイル サイズが小さくなる場合もあります (とりわけ、メタデータの量が減ったためだと思います)。 . スプライトを使用するもう 1 つの利点は、ホバー状態の要素に最初にホバーしたときにちらつき効果がないことです。これにより、ページのパフォーマンスに対するユーザーの認識が向上します。画像の最適化に関する興味深いリソースとして、Yahoo ユーザー インターフェイス ブログのこの一連のブログ記事を参照してください。パフォーマンスに関する Yahoo の推奨プラクティスを読み直して驚いたのは、画像を縦方向ではなく横方向に並べると、ファイル サイズも縮小できるということでした。
上記の理由は別として、私はそれらが扱いやすいと感じています。画像を更新する場合、変更してアップロードする必要があるファイルは 1 つだけで、コード内で変更する URL は 1 つだけです。