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