1

クライアント用に静的な 10 ページの Web サイトを構築していて、サイト全体で数行の JavaScript しかないとします (1KB 未満)。この状況では、(パフォーマンスのために) 1KB 未満の JavaScript コードを、外部ファイルではなく、すべてのページのスクリプト タグ間にインラインで配置するのが最善だと思います。.js余分な帯域幅の消費 (ページ間を移動するとき) は、おそらく HTTP 要求全体を削除する価値があります。

反対に、同じ Web サイトに 200 KB の JavaScript がある場合、サイトのページ間を移動するときの帯域幅を減らすために、これを別のファイルに入れることは間違いありません。

しかし、「カットオフポイント」がどこにあるべきかわかりません。5KB の JS がある場合、これを HTML にインラインで配置する必要がありますか? 10KBはどうですか？20KB?

明らかに、「カットオフ ポイント」は状況によって異なります。たとえば、モバイル サイトでは異なる場合があります。しかし、誰かがこの決定を導くのに役立つ一般的な指針を持っているなら、私はそれらを聞きたい.

(注:ここではパフォーマンスのみに関心があり、保守性などには関心がありません。コードを別のファイルに保持できますが、ある種のビルド プロセスまたはサーバーサイド ミドルウェアを使用して自動的にインライン化するため、保守性は問題になりません。)

（ボーナスポイント：すべての考慮事項がインラインと外部CSSでまったく同じかどうか教えてください。）

4

3 に答える 3

3

私はここで厳密にパフォーマンスについて話しているのですが、より思考実験として話しているのです (厳密な実験に欠けていることをお許しください)。

JavaScript をインライン化する場合は、すべてが 1 つの http 要求で行われるため、時間を節約できます。ただし、サーバーが必要な Web ページを動的に生成するのにかかる時間を考慮に入れる必要があります (SSL もこれに時間を追加します)。

最良の場合

縮小された JavaScript を生成し、gzip 圧縮と組み合わせて HTML ページに挿入するビルドを作成できれば、帯域幅が大幅に削減されるはずです。圧縮に含めるテキストが多いほど、リクエストごとに個別に gzip する場合と比較して、見返りが大きくなります。最終的に、これは、すべての javascript/css インラインで単一の html ページを静的にロードできる場合、これは間違いなく高速になることを意味します。

通常の場合 (動的 html および共有 js ライブラリを使用)

いくつかのスタックオーバーフロー投稿の小さなサンプルと、それらが自分の帯域幅にどのように影響するか:

304ms 9.67KB
204ms 11.28KB
344ms 17.93KB
290ms 17.19KB
210ms 16.79KB
591ms 37.20KB
229ms 30.55KB

このことから判断すると、(ファイルサイズを無視して) 発生するオーバーヘッドは、おそらく最悪の場合、各 http 接続で約 150 ミリ秒のようです。さて、問題は、帯域幅が 150 ミリ秒かかるには、テキスト (あなたの場合は JavaScript) がどれくらいの大きさでなければならないかということです。この記事 (http://www.telecompetitor.com/akamai-average-us-broadband-connection-speed-is-now-5-3-mbps/) によると、ブロードバンド ユーザーの場合、平均で5.3 mbps (これは .6625 MB/s または 678.4 KB/s または .6784 KB/ms)。これは、平均的なブロードバンド ユーザーの場合、gzip 圧縮 + 縮小された JavaScript を約 100 KB ダウンロードして、同等にする必要があることを意味します。

パラメータを自分で調整して、視聴者にとってこれが何を意味するかを確認してください。この数値は、どのように計算しても、インラインで (サーバー生成の応答を介して) 提供する方が、外部で取得/キャッシュするよりも優れている可能性があるポイントです。

全体として、パフォーマンス上の理由から、これがボトルネックになるとはまったく思いません。圧縮 + 縮小された JavaScript のサイズは、通常は無視できる程度であり、維持できないほどの大きさでなければなりません。

于 2012-04-11T21:04:02.350 に答える
0

短い答え: それは依存します!

仮定:

  • スクリプトを実際にすべての HTML ページにコピー アンド ペーストしてインライン化することはありません。
  • 別のファイルが適切にキャッシュされます

数字を実行します。追加の HTML によって生成される追加のトラフィックの量を、残りのトラフィックに比例して概算し、それが許容できる妥協点であるかどうかを判断します。

1%なら気にしなくていいです。ただし、50% の場合は、スクリプトを別のファイルに入れることでトラフィックを半分にすることができます。

于 2012-04-11T20:11:15.743 に答える
0

カットオフ ポイントは 0KB です。「JavaScript がインライン化する価値があるほど小さいのはいつか」に対する答えは「絶対にありません」です。

考慮したくないと言う保守性の問題は別として、とにかくパフォーマンスに優れています。はい、最初にファイルを参照するときに余分な HTTP 要求が 1 つあり.jsますが、その後はキャッシュされるため、全体的なトラフィック/帯域幅は時間の経過とともに減少します。

CSSファイルも同様です。

インライン JS または CSS を使用してページを重くすることは、ファイルの最初のフェッチに対する余分な要求よりもコストがかかります (.htmlページ全体が長時間キャッシュされる完全に静的なものを提供している場合を除く) 。

于 2012-04-11T19:42:13.903 に答える