HTTP/2 ではJS ファイルと CSS ファイルのバンドルは必要ありませんが、イメージ スプライトについてはどうでしょうか。
デモを見ると、すでに HTTP/1.1 よりも高速に動作しているように見えますが、画像をスプライトにバンドルするとさらに高速になるのではないでしょうか? つまり、すべてのデータが 1 つのファイルにある場合、PNG の最適化アルゴリズムはうまく機能しないのでしょうか?
質問する
5690 次
2 に答える
22
画像のサイズと形式によって異なります。画像が十分に大きい場合、スプライトを使用してもあまり効果はありませんが、小さな画像の場合は、HTTP/2 を使用した場合でも大きな効果があります。HTTP/2 の優れている点は、ヘッダーのオーバーヘッドがはるかに少なく、ラウンドトリップがさらに少なくなる可能性があることです (サーバーが PUSH を実装している場合)。問題は、ファイルをバンドルすることを検討するには、ファイルをどれくらい小さくする必要があるかということです。
bitmapsの場合、特にサイズが十分に小さい場合、PNG の最適化アルゴリズムはスプライトを優先して機能するという点で適切です。たとえば、Gabriel Bouvigne のこの記事の画像は 17.4 kb ですが、これをスライスすると、合計 135 kb の 132 個の個別の画像が生成されます。小さいながらも既存の転送オーバーヘッドを追加すると、10 倍近くになります。もちろん、サーバーとクライアント間の帯域幅が限られている場合でもサイズは重要です。
実際、これは javascript、css、SVG ファイルなどのテキスト リソースにも到達します。それらが十分に小さく、頻繁に変更されない場合でも、それらをまとめることを検討できます。たとえば、Angular のソースのng フォルダーにある Javascript は、個別に圧縮されて gzip された js として転送される場合、69.6 kb かかります。gzip で圧縮する前にそれらを連結すると、わずか 31.9 kb になります。ただし、ここでの係数は 2 をわずかに上回る程度であり、HTTP/2 が接続時間とラウンドトリップを節約する場合、それほど重要ではない可能性があります。これは、リソースを個別にキャッシュする可能性とさらにバランスを取ります。
最後に、小さな画像/アイコンが SVG ベクターの場合 (そうすべきです!)、それらはテキスト リソースとしてカウントされます。また、SVG ベクターは少し大きくなる傾向があります。たとえば、Firefox の SVG アイコンは gzip 圧縮すると 15.7 kb になります。このサイズでは、HTTP/2 グッズが機能している場合、リンクするか、インライン化またはバンドルするかの決定は簡単です。
于 2015-08-23T10:19:01.323 に答える