2012-04-11 1 views
1

私はクライアントのために静的な10ページのウェブサイトを構築しており、サイト全体(わずか1KB未満)に数行のJavaScriptしかありません。このような状況では、外部の.jsファイルではなく、すべてのページのスクリプトタグの間に< 1KBのJavaScriptコードインラインを置くのが最善の策だと思います。余分な帯域幅の消費(ページ間を移動するとき)は、HTTP要求全体を削除するためにおそらくそれに値するでしょう。最適なパフォーマンスを得るには、JavaScriptをインライン展開するに足るほど小さいですか?

同じWebサイトで200KBのJavaScriptを使用していた場合は、サイトのページ間を移動するときに帯域幅を減らすために別のファイルに入れます。

しかし、私は「カットオフポイント」がどこにあるべきか分かりません。私が5KBのJSを持っていれば、私はHTMLの中にこのインラインを置くべきですか? 10KBはどうですか? 20KB?明らかに、「カットオフポイント」は状況に依存することになる。モバイルサイトでは異なる場合があります。しかし、誰かがこの決定を導く助けになる一般的な指針を持っているなら、私はそれらを聞きたいと思います。

NB:私はのみ性能がここに興味、私は別々のファイルに自分のコードを保つことができるなど、メンテナンスが、それを自動的にインライン化するビルドプロセスまたはサーバー側ミドルウェアのいくつかの種類を使用するので、メンテナンス性はしません。。問題になることはない)

ボーナスポイント:すべての考察は、外部CSS対インラインと全く同じである場合は私に知らせてください)

+9

私は* always * Javascriptを別のファイルに入れています。 *例外はありません。これまで –

+8

私は1KBのJavascriptについても、それをリンクするほうが好きです。なぜなら、これはちょうど*一度だけ*フェッチされなければならないからです。あなたがあなたのHTMLの中に入れたら、それはすべての要求のためにフェッチする必要があります –

+1

短い答え:それは異なります。 –

答えて

3

私はここでパフォーマンスについて厳密に話しています。これは思考実験としてのものです(実験的厳しさの欠如を許してください)。

JavaScriptをインライン展開する場合は、すべてが1つのhttp要求で実行されるという事実に時間を節約します。ただし、サーバーが必要なWebページを動的に生成するのにかかる時間を考慮する必要があります(SSLにも時間がかかる)。

ベストケース

あなたが縮小さジャバスクリプトを生成し、gzip圧縮と組み合わせたhtmlページ、にそれを注入ビルドを作成することができた場合は、はるかに低い帯域幅を生じるはずです。より多くのテキストを圧縮すると、要求ごとに個別にgzippingするよりも、あなたの利益が大きくなります。結局のところ、これは、すべてのjavascript/cssインラインで静的に単一のhtmlページを読み込ませることができれば、これは間違いなく高速になることを意味します。

ノーマルケース(ダイナミックHTMLと共有JSライブラリを使用)

小さないくつかのStackOverflowの記事のサンプルおよびそれらがどのように自分自身の帯域幅に影響します。このことから判断すると

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

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

パラメータを自分で調整して、視聴者にとって何が意味するのかを確認してください。この数値は、あなたが計算するものであれば、インラインで(サーバが生成したレスポンスを使って)、それをフェッチ/キャッシュする方が良い場合があります。

パフォーマンス上の理由から、これはボトルネックではないと私は思っています。圧縮された+縮小されたjavascriptのサイズは、通常はごくわずかであり、重要ではない維持不可能な大きさのオーダーでなければなりません。

0

カットオフポイントは0キロバイトである - への答え「JavaScriptがインライン展開のために十分に小さいのはいつですか」は「nevエル "。

あなたが考慮したくないと言っている保守性の問題とは別に、とにかくパフォーマンスの方が優れています。はい、初めてのHTTPリクエストがで、初めてというファイルを参照していますが、それ以降は全体のトラフィック/帯域幅がになるようにキャッシュされますので、時間の経過とともにが減少します。

CSSファイルについても同様です。インラインJSやCSSを含むページが重く作る

は、ファイルの最初のフェッチのための余分な要求よりも高価である

+0

それは0以上でなければならない、そうでなければJavaScriptを最適化するためのルールは無限に任意のjavascriptを追加することになります!;) – badunk

+1

"インラインJSまたはCSSは、ファイルの最初のフェッチに対する余分な要求よりもコストがかかります" - これは必ずしも真実ではありません。小さなファイルに対する要求のオーバーヘッドは、資料。これは、特に、TCPスロースタートフェーズを経なければならない早期ページ要求の場合に当てはまります。 –

+1

またレイテンシが悪ければ悪化します。モバイル版のbing.comのようなサイトはCSS&JSをインライン化してからlocalStorageにキャッシュします。 –

0
(あなたは、ページ全体を長時間キャッシュされ、完全に静的 .htmlにサービスを提供している場合を除き)

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

と仮定:

  • をあなたが実際に別のファイルが正常に

は数字を行い、キャッシュされたことになる

  • すべてのHTMLページにコピー&ペーストして、スクリプトをインライン化しません。残りのトラフィックに比例して、追加のHTMLによって生成される余分なトラフィックの量()を概算して、それが許容可能な妥協策であると判断するかどうかを判断してください。

    1%の場合、おそらくそれほど心配する価値はありません。しかし、50%であれば、スクリプトを別のファイルに入れてトラフィックを半分にすることができます。

  • 関連する問題