1

ですから、javascriptとcssをできるだけ少ないファイルにバンドルするのは良いことだと聞いています。もちろんそうですが、話が単純すぎるように思えます。

ここで私の論理が理にかなっているかどうかを確認してください。

明らかに、HTTPリクエストが少ないほど、ラウンドトリップが少なくなるため、より良い結果が得られます。しかし-そして私は裸のhttpについてあまり知りません-http応答はチャンクで送信されませんか？そして、ファイルがそれらのチャンクの1つよりも大きい場合、複数の（おそらく同期？）ラウンドトリップとしてダウンロードする必要はありませんか？これとは対照的に、最新のWebブラウザーはJavaScriptなどのリソースを並行してダウンロードするため、チャンクサイズのすぐ下のファイルに対するいくつかの要求ははるかに迅速に到着します。

チャンク化が問題ではない場合でも、バンドルされたファイルは完全にダウンロードされて実行されるまで待機する必要があるため、パケット損失の可能性があるため、推奨される最大サイズがあるようです。スクリプトが実行する必要があるより寛大なネイティブルールとは異なります。順番に。

もちろん、ブラウザのキャッシュとコードの変動性についても考慮する必要がありますが、誰かがこれを確認したり、私がベースから外れている理由を説明したりできますか？誰かがそれに入れる数字はありますか？

4

1 に答える 1

4

これに当てはまる数値の参照は見つかりませんが、信頼できる情報源から過去に、誰か（GoogleまたはFBのいずれか）がリクエストの同時実行を取り巻く効率の問題について多くの調査を行ったことを読みました。 CDNを構築し、パケット損失、トランスポート層のオーバーヘッド、およびその他のそのような要因を考慮に入れると、2〜3の同時転送が最適であることがわかりました。これは、単一のサーバーと通信する単一のクライアントに適用され、複数のサーバーからコンテンツを分散することで、わずかですが顕著な効率の向上が見られます。これは、分散CDNを使用するもう1つの利点です。

下から上へ-HTTP、TCP上で実行されると、必然的に低レベルで多くのラウンドトリップが発生します。これは、各TCPPSHが次の送信前にACKされる必要があるためです。イーサネットMTUが1500（DSLやその他のATMベースの接続が豊富な場合は実際には1492）であることを考えると、TCPの最大ペイロードサイズをこれ以上大きく設定しても、実際には効率が低下するため、意味がありません。Webページで使用されるリソースの多く（すべてではないにしても）は約1.4KBを超えるため、トランスポート層で必然的に「チャンク」（断片化）され、TCPペイロードサイズの設定がばかげていると、ネットワークで断片化が発生します。レイヤーも。前述のように、これらのトランスポートフラグメントのそれぞれは、次のフラグメントが送信される前に受信者によってACKされる必要があり、少なくとも数回のラウンドトリップが発生します。

アプリケーション層では、HTTP自体も「チャンキング」をサポートしています。これは、トランスポート層の断片化の問題とは少し異なる球技です。Chunked Transfer Encodingは、永続性の概念を念頭に置いて設計されており、サーバーとクライアントの両方にメモリ消費のメリットも提供します。応答はわずかに大きくなりますが、（正しく実装されている場合）それほど多くのラウンドトリップが発生する可能性は低く、追加のラウンドトリップはまったく新しいHTTP要求ではなく、単にTCP PSH/ACKペアになります。チャンク転送エンコーディングの考え方は、複数のストリームで交換されるチャンクに分割するのではなく、本体を同じストリーム内のチャンクにスピルすることです。確かに、あなたの質問の言い回しは、HTTPメッセージはチャンクで転送されますが、これは単にそうではありません。サーバーが適切に構成されている場合、動的コンテンツと動的に圧縮されたコンテンツのみがチャンク化され、それでもすべてがチャンク化されるわけではありません。ほとんどのHTTPサーバーは、応答をできるだけ少ないTCPパケットに収めるために最善を尽くします。

推奨される最大サイズに関しては、信頼できる答えを出すことはできませんが、この問題についての私の見解をお伝えします。上記のパラメータの範囲内で発生する可能性のあるすでに無限の変動を考えると、それを行う最も効率的な方法は、提供しているものと提供している方法に大きく依存します。

大量の静的コンテンツを提供している場合は、おそらく個人の転送が大きいほど全体的に優れていますが、注意が必要です。たとえば、クライアント側の動的コンテンツ（JSを利用したもの）が多数含まれているWebページを提供しているとします。できるだけ早くロードするページ。ただし、最初に送信する必要があるのは、ディスプレイの初期状態をレンダリングするために必要なコンテンツだけです。ベースHTMLは明らかに最初に送信する必要があるものですが、これが当てはまるのは当然のことです。次に、ページの初期レイアウトを示すスタイルシートと、必要な画像が必要になります。これで、すべてが表示されます。ロードされたかのように。次に、すべての基本クライアント側コードをページに添付するJavascriptが必要です。これは実際にはかなり小さい可能性があります。これらすべてがロードされた場合にのみ、リソースのより大きな本体を取得する必要があるため、これへのすべての参照をHTMLヘッドに配置する代わりに、リソースがロードされる順序をほとんどまたはまったく制御できません（NB ：ロードされ、実行されません）、基本的なJavascriptファイルから動的にロードします。これにより、できるだけ早く読み込まれたように見えるページを作成できますが、実際には、あまり使用されないリソースや、後でいくつかのユーザーアクションの後にのみ必要となるリソースが読み込まれます。

すべてを動的に提供している場合（PHP / Perl / ASP /ここにサーバー側言語を挿入）、サーバー側の実行時間も考慮する必要がありますが、同じ原則が適用されます。ページができるだけ速く読み込まれたように見せるために必要なマークアップ/スタイル/スクリプト/画像/その他のものを作成します。作成に時間がかかるものは、後でJS経由で読み込むことができます。

これを読み返してみると、これがあなたにとってどれほど役立つか、あるいはそれがあなたの質問に答えるかどうかさえわかりませんが、うまくいけば、それはいくつかの面白い（？）読書に役立つでしょう。

于 2012-03-29T08:44:01.003 に答える