headセクションで参照されるJavaScriptは、メインドキュメントと同じホスト名から提供されるべきですか？

最高のパフォーマンスを得るには、JavaScriptを静的コンテンツとして扱い、CSSファイル、画像などとともにCookieのないドメインから提供する必要があるという印象を受けました。

ただし、Googleは次のように述べています：Cookieのないドメインから早期にロードされた外部JSファイルを提供しないでください

ドキュメントの先頭で参照され、ページの起動に必要なJavaScriptの場合、メインドキュメントと同じホスト名から提供される必要があります。ほとんどのブラウザは、すべてのJavaScriptファイルがダウンロード、解析、実行されるまで、他のダウンロードとレンダリングをブロックするため、この処理ポイントで追加のDNSルックアップのリスクを回避する方が良いでしょう。

だから今私は対立しています。「ページの起動に必要」が何を意味するのか明確ではありません。

通常、2つのJavaScript参照があります。ajax.googleapis.comから提供されるJQueryと、主に$（document）.ready（）関数にイベントハンドラーを含むmaster.jsファイルです。これはページの起動に必要ですか？

利用可能なオプション（ajax.googleapis.com、静的cookielessドメイン、元のホスト名）が与えられた場合、JavaScriptはどこに配信されるべきですか？

だから今私は対立しています。「ページの起動に必要」が何を意味するのか明確ではありません。

これは、サイトの機能に大きく依存します。基本的に、誰かがWebページを利用する前に実行する必要があるのはJavaScriptです。

たとえば、http：//www.weather.com/にアクセスすると、天気の良い検索フォームにヒントを提供するために、JavaScriptのマジックを使用することに決定したことがわかります。つまり、単語Enter Zip, City or Place (e.g. Disney World)はテキスト入力フィールドに表示されます。残念ながら、少なくとも私の側では、ページの読み込み中にわずかな遅延があります。したがって、ページの読み込みが遅く、JavaScriptが実行される前にテキスト入力の入力を開始するのに十分な速さであれば（これはストレッチではありません）、入力が盲目的にヒントを配置するJavaScriptによって台無しになる可能性があります入力ボックス内のテキスト。

確かに、これは最初にテキストボックスでユーザー入力を確認するか、単にこの時代錯誤的な手法をあきらめることで回避できます。ただし、それは非常に良い例としては機能しません。

利用可能なオプション（ajax.googleapis.com、静的cookielessドメイン、元のホスト名）が与えられた場合、JavaScriptはどこに配信されるべきですか？

あなたのJavaScriptが何をするのかを知らなければ、これに答えることはできません。また、bpeterson76が示すように、サイトの特定の状況に依存します。つまり、ページの大きさはどれくらいですか？ホストの需要はどの程度満たされていますか？どのくらいのCSSファイル、画像などがロードされますか？どのくらいの外部リソースがロードされていますか？

特定の状況に応じて、これは時期尚早な最適化になる場合があります。

「ページがレンダリングを開始する前に必要なものは、同じサーバーからのものでなければならない」のルールは一般的に適用されますあなたのサーバーまたはその他の小さなリソース-DNSルックアップに1秒未満の顕著な時間がかかる状況（オブジェクトが多数のドメインに散らばっている場合、すぐに追加される可能性があります）。GoogleのjQueryキャッシュや他のライブラリなどの一般的なパブリックリソースを使用すると、訪問者のブラウザーが既にDNSルックアップを実行している可能性が高くなります（他のサイトがそのサービスのコンテンツを参照しているため）転送を行う必要があります（または、リクエストが行われた場合、短い「304-not modified」レスポンスが返される場合があります）。オブジェクトの完全なダウンロードが必要な場合でも、ほとんどのユーザーにとって、Googleのコンテンツ配信ネットワークは小規模な操作よりも高速です。

1つの関連ルール：ページの正しい機能に必要ではないオブジェクト（ユーザーが見るように）は、メインHTTP応答で可能な限り遅く参照される必要があります。たとえば、広告/統計サービスに必要なスクリプト（例：Googleアナリティクスとその同類）-ユーザーにできるだけ早くコンテンツを提供し、本当に興味のあるバックグラウンドのものをロードします。ホストファイルで127.0.0.1にマッピングすることにより、いくつかの広告/統計サービスをブロックしました。それらはしばしば遅すぎるため、スクリプトを待機している間、それらを参照するサイトが空白ページを表示するだけです後でそれらを参照することで、私がそこにいるコンテンツを読むことができますが、他のものはバックグラウンドで動いています。

静的コンテンツに対するCookieのないドメインの有用性は規模の問題です。Cookieに1つの10バイトセッションIDと1日あたり1万人の訪問者が1訪問あたり最大20個の静的オブジェクトをリクエストしている場合、1か月あたり最大118Mバイトの帯域幅（20 * 20 * 10000 * 31/1024/1024）しか節約できません。一方、サイトがCookieに1キロバイトまたは2キロバイト相当のものを保持している場合、特にユーザーが低速接続を介してサイトにアクセスする場合（モバイルへのテザリングによるGPRSまたは-高干渉エリアでの混雑したWi-Fiリンク）または1日あたり数百万の訪問がある場合。

要約すると、ページが私の設定をレンダリングする前にロードする必要があるスクリプトの場合は次のようになります。

1. ajax.googleapis.com、または同様のもの
2. 呼び出しページの元のホスト名
3. 静的なCookieのないドメイン

初期ページのレンダリングに不可欠ではないリソースについては、可能な限り遅く参照し、上記の設定リストを逆にします（ただし、元のホスト名とCookieのないドメインの違いは、大規模に運用している場合を除き、ほとんど重要ではありません）。

Googleは世界中に分散した巨大なコンテンツネットワークを運営しており、実行している可能性のある単一のサーバーよりもユーザーに近いコンテンツを提供しています（Akamiを考えていますが、Googleが所有しています）。そのため、速度の観点からは、 Googleは、ローカルサーバーよりも高速にファイルをユーザーに提供しますが、ユーザーが個人サーバーに非常に近い場合を除きます。

この質問はStackoverflowで何度も繰り返されており、上記の答えは常にコンセンサスのようです。しかし、現実的な観点からは、一方を他方でホストすることによる利益は、長期的にはごくわずかなものになるでしょう。物理的にどこにあるかを精査するよりも、全体的なhttpリクエストを最小化、最適化、および削減することで、はるかに優れたメリットが得られます。それが問題になり始める状況（ページが1日150万回以上読み込まれる仕事をしたので、5kの改善は帯域幅節約で5ギグを意味しました）これらの決定を精査する任務を負う意思決定者のチームが通常あります。

個人的には、私が探しているものの最新のコピーを提供してくれるという唯一の理由で、通常Googleでホストしています。

覚えておくべき重要なことの1つは、ブラウザーは同じドメインから同時にダウンロードするリソースの数に制限があることです。通常、ブラウザーに応じて2〜6です。別のドメインを使用すると、ブラウザーはドメインからより多くのものを同時にダウンロードできます。

したがって、最善の解決策は、ajax.googleapis.comのような一般的なCDNを使用することです。Cookieが存在しないためです。ユーザーはおそらく既にDNSルックアップを行っており、リソースをキャッシュしている可能性もあります。CDNは速度が最適化されており、おそらくユーザーの近くにサーバーがあります。

CDNがオプションではない場合、多くのCookieまたはダウンロードするリソース（イメージなど）がある場合は、Cookieフリードメインを使用します（とにかくDNSルックアップを1回だけ行う必要があります）。

同じドメインからのリソース（カスタムJavaScriptファイルが1つだけ）とCookie（セッションIDが1つだけ）が少ない場合。

良いリソース：

http://www.phpied.com/free-falling-waterfalls/

http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/

http://developer.yahoo.com/performance/rules.html

上記の回答はあなたの質問の大部分を分析しましたが、「ページの起動に必要」に貢献します。私はこれを次のように翻訳します：このスクリプトはWebサイトを使用するために不可欠ですか？経験から、通常、答えはノーです。ただし、次の場合：

• フォーム検証
• JavaScriptベースのナビゲーション（とにかく理想的ではありません）
• レイアウトがJavaScriptに依存する場合
• JavaScriptまたはライブラリ（jQueryなど）が重要なDOM変更に使用される場合

また、参照用のYahooのYSlowパフォーマンスガイドライン。