インラインと外部Javascriptをいつ使用する必要がありますか？
パフォーマンスとメンテナンスの容易さの観点から、外部スクリプトを含めるか、HTMLコードとインラインで記述する必要があるかを知りたいです。
これの一般的な慣行は何ですか？
Real-world-scenario-クライアント側のフォーム検証が必要なHTMLページがいくつかあります。このために、これらすべてのページに含めるjQueryプラグインを使用します。しかし、問題は、私は：
- このスクリプトをインラインで構成するコードの一部を記述しますか？
- これらのすべてのhtmlページで共有される1つのファイルにすべてのビットを含めますか？
- htmlページごとに1つずつ、個別の外部ファイルに各ビットを含めますか？
ありがとう。
この回答が最初に投稿された時点（2008年）では、ルールは単純でした。すべてのスクリプトは外部である必要があります。メンテナンスとパフォーマンスの両方。
（パフォーマンスが必要な理由は、コードが分離されていると、ブラウザーで簡単にキャッシュできるためです。）
JavaScriptはHTMLコードに属しておらず、特殊文字（<、>）問題を引き起こすことさえあります。
現在、Webのスケーラビリティは変化しています。要求の数を減らすことは、複数のHTTP要求を行うレイテンシーのために、有効な考慮事項になりました。これにより、答えがより複雑になります。ほとんどの場合、外部JavaScriptを使用することはstillが推奨されます。ただし、特定の場合、特に非常に小さなコードの場合、サイトのHTMLにインライン化することは理にかなっています。
保守性はそれらを外部に保持する理由であることは間違いありませんが、構成が1ライナー（または一般にこれらのファイルを外部にするために得られるHTTPオーバーヘッドよりも短い）である場合、それらをインラインに保つ方がパフォーマンスの面で優れています。 HTTPリクエストごとに、実行時間とトラフィックの観点からオーバーヘッドが発生することを忘れないでください。
当然、コードが数行より長くなり、実際には単一のページに固有ではない瞬間に、これはすべて無関係になります。そのコードを再利用できるようにしたい瞬間、それを外部にします。そうでない場合は、そのサイズを見て決定します。
JavaScriptの外部化は、yahooのパフォーマンスルールの1つです。 http://developer.yahoo.com/performance/rules.html#external
通常、常にスクリプトを外部化するという厳重なルールが最善の策ですが、場合によっては、スクリプトとスタイルの一部をインライン化することもできます。ただし、パフォーマンスを向上させることがわかっているものだけをインライン化する必要があります（これを測定したためです）。
パフォーマンスだけに関心がある場合、このスレッドのアドバイスのほとんどは完全に間違っており、SPA時代にはますます間違っています。JSコードがないとページが役に立たないと仮定できます。 SPAページの読み込み時間を最適化し、これらの結果をさまざまなブラウザーで検証するために、何時間も費やしました。全体的に、HTMLの再編成によるパフォーマンスの向上は非常に劇的です。
最高のパフォーマンスを得るには、ページを2段ロケットと考える必要があります。これらの2つの段階は、ほぼ<head>および<body>段階ですが、代わりに<static>および<dynamic>。静的な部分は基本的に文字列定数であり、可能な限り高速で応答パイプを突き落とします。 Cookieを設定するミドルウェアをたくさん使用する場合（httpコンテンツを送信する前に設定する必要があります）、これは少し難しいかもしれませんが、原則として応答バッファーをフラッシュするだけで、できればテンプレートコード（razor、php、など）サーバー上。これは難しいように思えるかもしれませんが、私はそれを間違っていると説明しています。ご想像のとおり、この静的部分にはインライン化および縮小されたすべてのJavaScriptが含まれている必要があります。それは次のようになります
<!DOCTYPE html>
<html>
<head>
<script>/*...inlined jquery, angular, your code*/</script>
<style>/* ditto css */</style>
</head>
<body>
<!-- inline all your templates, if applicable -->
<script type='template-mime' id='1'></script>
<script type='template-mime' id='2'></script>
<script type='template-mime' id='3'></script>
この部分を送信するのにほとんどコストがかからないため、クライアントは、サーバーに接続した後、約5ms +遅延のどこかでこれを受信し始めると予想できます。サーバーが適度に近いと仮定すると、この遅延は20ミリ秒から60ミリ秒の間になる可能性があります。ブラウザはこのセクションの処理を開始するとすぐに処理を開始し、処理時間は通常、転送時間の20倍以上を占めます。これは、サーバー側での<dynamic>部分。
インラインjquery + signalr + angular + ng animate + ng touch + ng routes + lodash。）を処理するには、ブラウザ（クロム、残りは20％遅い）で約50msかかります。ほとんどのWebアプリは、人気のあるすべてのライブラリを組み合わせた場合よりもコードが少ないですが、同じくらい多く持っているとしましょう。そのため、クライアントでのレイテンシ+ 100ミリ秒の処理を獲得します（このレイテンシの向上は2番目の転送チャンクから発生します）。 2番目のチャンクが到着するまでに、すべてのjsコードとテンプレートを処理し、dom変換の実行を開始できます。
このメソッドがインライン化の概念に直交していることに反対するかもしれませんが、そうではありません。インライン化する代わりに、cdnsまたは独自のサーバーにリンクする場合、ブラウザは別の接続を開いて実行を遅らせる必要があります。この実行は基本的に無料であるため（サーバー側がデータベースと通信しているため）、これらのジャンプはすべて、ジャンプをまったく行わない場合よりもコストがかかることを明確にする必要があります。外部jsの実行速度が速いというブラウザの癖がある場合、どの要素が支配的かを測定できます。私の測定では、この段階で余分なリクエストがパフォーマンスを低下させることが示されています。
SPAアプリの最適化に取り組んでいます。人々は、データ量が大したことだと考えるのが一般的ですが、実際にはレイテンシーであり、実行がしばしば支配的です。私がリストした縮小ライブラリは合計300kbのデータを追加し、それはわずか68kbのgzip圧縮、または2mbit 3g/4gの携帯電話での200msのダウンロードです。これは、同じ携帯電話で同じデータがあるかどうかを確認するのにかかる待ち時間ですモバイルレイテンシ税（電話からタワーへのレイテンシ）が引き続き適用されるため、プロキシキャッシュであったとしても、そのキャッシュには既にあります。一方、最初のホップの待ち時間が短いデスクトップ接続では、通常、帯域幅が広くなります。
要するに、今（2014年）、すべてのスクリプト、スタイル、およびテンプレートをインライン化するのが最善です。
編集（2016年5月）
JSアプリケーションが成長し続け、私のペイロードの一部が3メガバイト以上の縮小コードをスタックするにつれて、少なくとも一般的なライブラリがインライン化されないことが明らかになってきています。
1ページに固有、短いスクリプトケース はインラインスクリプトの（唯一の）防御可能なケースだと思います
実際、インラインjavascriptを使用するかなり堅実なケースがあります。 jsが十分に小さい場合（1行）、私は2つの要因からjavascriptインラインを好む傾向があります：
常に外部スクリプトを使用する必要があるもう1つの理由は、 コンテンツセキュリティポリシー（CSP） への移行を容易にするためです。 CSPのデフォルトでは、すべてのインラインスクリプトが禁止されているため、XSS攻撃に対するサイトの耐性が高まります。
必要なコードを見て、必要な数の個別のファイルに分割します。すべてのjsファイルは、関数などの「論理セット」を1つだけ保持します。すべてのログイン関連機能用の1つのファイル。
次に、各htmlページのサイト開発中に、必要なもののみを含めます。サイトをライブで使用する場合、ページに必要なすべてのjsファイルを1つのファイルに結合して最適化できます。
インラインjavascriptに対して提供できる唯一の防御は、.net MVCで強く型付けされたビューを使用するときに、javascriptの中間でc＃変数を参照できることです。
3つの考慮事項：
- どれくらいのコードが必要ですか（ライブラリは一流の消費者である場合があります）？
- 特異性：このコードは、この特定のドキュメントまたは要素のコンテキストでのみ機能しますか？
- 文書内のすべてのコードは、文書を長くする傾向があるため、遅くなります。それに加えて、SEOの考慮事項により、内部スクリプトを最小限に抑えることが明らかになります...
JavaScriptを外部に保つという点で：
ASP.NET 3.5SP1は最近、複合スクリプトリソースを作成する機能を導入しました（多数のjsファイルを1つにマージします）。これのもう1つの利点は、Webサーバーの圧縮がオンになっている場合、わずかに大きいファイルをダウンロードすると、多くの小さいファイルよりも圧縮率が高くなることです（httpオーバーヘッド、ラウンドトリップなども小さくなります）。これにより、最初のページの読み込みが節約され、前述のようにブラウザーのキャッシュが開始されます。
ASP.NETは別として、このスクリーンキャストでは利点について詳しく説明しています。 http://www.asp.net/learn/3.5-SP1/video-296.aspx
外部スクリプトのもう1つの隠れた利点は、 jslint のような構文チェッカーを使用して簡単に実行できることです。これにより、多くの悲痛で見つけにくいIE6のバグからあなたを救うことができます。
Firebugを使用すると、外部スクリプトのデバッグも簡単になります。 JavaScriptを単体テストし、すべての外部ヘルプを使用するのが好きです。 JavaScriptをPHP=コードとHTMLで見るのは大嫌いです。
Googleはページランキングの測定にロード時間を含めています。多くのインラインを使用すると、スパイダーがページをクロールするのに時間がかかります。これを含める必要がある場合、ページランキングに影響する可能性があります。いずれにしても、異なる戦略がランキングに影響を与える可能性があります。
あなたのシナリオでは、ページ間で共有される1つのファイルに外部のものを書くことはあなたにとって良いと思われます。上記のすべてに同意します。
初期のプロトタイピング中は、コードをインラインに保ち、高速な反復を実現しますが、本番環境に到達するまでにコードをすべて外部にしてください。
すべてのJavascriptを外部に配置できない場合、悪いデザインが手元にあるので、データとスクリプトをリファクタリングする必要があるとさえ言ってしまいます
スクリプトを複数のページで共有する必要がないため、単一ページのWebサイトを作成する場合はインラインを使用する必要があると思います
インラインjsは常に維持するのが難しいため、常に外部Jsを使用するようにしてください。
さらに、開発者の大半はjsを外部で使用することを推奨しているため、外部jsを使用することが専門的に必要です。
私自身は外部jsを使用しています。