Google Closure ライブラリ チームのメンバーは、DOMContentReady イベントを待機することは悪い習慣であると主張しています。
簡単に言うと、DOMContentReady (またはさらに悪いことに load イベント) を待ちたくないということです。これは、ユーザー エクスペリエンスの低下につながるからです。すべての DOM がネットワークからロードされるまで、UI は応答しません。そのため、できるだけ早くインライン スクリプトを使用することをお勧めします。
彼らはまだこれに関する詳細を提供していないので、IEでOperation Abortedダイアログをどのように処理するのだろうか. このダイアログは、DOMContentReady (またはロード) イベントを待機することがわかっている唯一の重要な理由です。
最初に少し説明します。インラインJavaScriptのポイントは、できるだけ早くそれを含めることです。ただし、その「可能性」は、そのスクリプトで宣言する必要があるDOMノードに依存します。たとえば、JavaScriptを必要とするナビゲーションメニューがある場合、メニューがHTMLで定義された直後にスクリプトを含めます。
<ul id="some-nav-menu">
<li>...</li>
<li>...</li>
<li>...</li>
</ul>
<script type="text/javascript">
// Initialize menu behaviors and events
magicMenuOfWonder( document.getElementById("some-nav-menu") );
</script>
宣言されていることがわかっているDOMノードのみをアドレス指定する限り、DOMが使用できないという問題が発生することはありません。IEの問題に関しては、開発者はこれが起こらないように戦略的にスクリプトを含める必要があります。それほど大きな問題ではなく、対処するのも難しいことではありません。これに関する本当の問題は、以下に説明するように、「全体像」です。
もちろん、すべてに長所と短所があります。
scriptプレゼンテーション全体でインクルードを混合しますが、どちらも管理が難しい場合があります。私の意見でも、コミュニティの大部分でも、どちらも受け入れられません。このテクニックを使用しますか？</body>いいえ。ページの最後、終了タグの直前にすべてのスクリプトをロードすることを好みます。ほとんどすべての場合、これは、エフェクトおよびイベントハンドラーの認識された実際の初期化パフォーマンスに対して十分に高速です。
他の人が使っても大丈夫ですか？開発者は、仕事を成し遂げるために、そしてクライアント/上司/マーケティング部門を幸せにするために、彼らが望む/必要なことをするつもりです。トレードオフがあり、それらを理解して管理している限り、どちらの方法でも大丈夫です。
インライン スクリプトの最大の問題は、適切にキャッシュできないことです。すべてのスクリプトを (コンパイラを使用して) 縮小された 1 つの js ファイルに保存している場合、そのファイルは、サイト全体に対して、ブラウザーによって 1 回だけキャッシュできます。
これにより、サイトが混雑する傾向にある場合、長期的にはパフォーマンスが向上します。スクリプト用に別のファイルを用意することのもう 1 つの利点は、「同じことを繰り返さず」、再利用可能な関数をできるだけ宣言する傾向があることです。DOMContentReady がユーザー エクスペリエンスの低下につながることはありません。少なくとも、UI が読み込まれるまでユーザーを待たせるのではなく、事前にユーザーにコンテンツを提供します。これは、ユーザーにとって大きなターンオフになる可能性があります。
また、インライン スクリプトを使用しても、DOMContentReady を使用した場合よりも UI の応答性が向上するとは限りません。ajax 呼び出しを行うためにインライン スクリプトを使用しているシナリオを想像してみてください。提出するフォームが 1 つしかない場合は、問題ありません。複数のフォームがあると、最終的に ajax 呼び出しを繰り返すことになります。したがって、毎回同じスクリプトを繰り返します。最終的に、ブラウザは、DOM の準備ができたときにロードされた js ファイルで分離された場合よりも多くの JavaScript コードをキャッシュすることになります。
インライン スクリプトを使用することのもう 1 つの大きな欠点は、開発用と運用用の 2 つの別個のコード ベースを維持する必要があることです。両方のコード ベースが同期していることを確認する必要があります。開発バージョンにはコードの縮小されていないバージョンが含まれ、製品版には縮小されたバージョンが含まれます。これは、開発サイクルにおける大きな頭痛の種です。これらのかさばる html ファイルに隠されているすべてのコード スニペットを手動で縮小バージョンに置き換える必要があります。ただし、開発サイクル中に別のファイルを維持すると、そのファイルを本番コードベースのコンパイル済み縮小バージョンに置き換えるだけで済みます。
YSlow を使用すると、次のことがわかります。
外部の JavaScript および CSS ファイルを使用すると、ファイルがブラウザーによってキャッシュされるため、通常は高速なページが生成されます。HTML ドキュメントにインライン化された JavaScript と CSS は、HTML ドキュメントが要求されるたびにダウンロードされます。これにより、HTTP 要求の数が減りますが、HTML ドキュメントのサイズが大きくなります。一方、JavaScript と CSS がブラウザーによってキャッシュされた外部ファイルにある場合、HTTP 要求の数を増やすことなく、HTML ドキュメントのサイズが縮小されます。
コードが頻繁に変更され、コードを別の js ファイルに入れることが重要でなく、最終的にこれらのインライン スクリプトと同じ影響を与える場合にのみ、インライン スクリプトを保証できます。それでも、これらのスクリプトはブラウザによってキャッシュされません。ブラウザーがスクリプトをキャッシュできる唯一の方法は、スクリプトがetagを使用して外部の js ファイルに保存されている場合です。
ただし、これは決して JQuery 対 Google の閉鎖ではありません。閉鎖には独自の利点があります。ただし、クロージャー ライブラリを使用すると、すべてのスクリプトを外部ファイルに含めることが難しくなります (ただし、不可能というわけではありませんが、難しくなるだけです)。インライン スクリプトを使用する傾向があります。
インラインスクリプトを回避する理由の1つは、ドキュメント内で依存関係ライブラリをそれらの前に配置する必要があるためです。これにより、インラインスクリプトのパフォーマンスの向上が無効になる可能性があります。私が精通しているベストプラクティスは、すべてのスクリプトを（単一のHTTPリクエストで！）ドキュメントの最後の直前に配置すること</body>です。これは、スクリプトの読み込みによって、スクリプトが完全に読み込まれ、解析され、実行されるまで、現在のリクエストとすべてのサブリクエストがブロックされるためです。
魔法の杖がなければ、常にこれらのトレードオフを行う必要があります。data:ありがたいことに、HTMLドキュメント自体はますますリソースをあまり消費しないリクエストになります（巨大なURLや巨大なインラインSVGドキュメントのようなばかげたものをやっていない限り）。私には、HTMLドキュメントの終わりを待つというトレードオフが最も明白な選択のように思われます。
このアドバイスはあまり役に立たないと思います。DOMContentReady は、現在過剰に使用されているため (おそらく jquery の使いやすい ready イベントのため)、単に悪い習慣である可能性があります。多くの人が、 JavaScript アクションの「開始」イベントとして使用します。jQuery の ready() イベントでさえ、DOM 操作の開始点としてのみ使用されることを意図していました。
ページ読み込み時の推論的な DOM 操作は、ユーザー エクスペリエンスの低下につながります!! それらは必要ないため、サーバー側は最初のページを完全に生成するだけで済みます。
ということは、閉鎖チームのメンバーは逆方向に舵を切り、人々がページの読み込み時に DOM 操作を行うのをまったく防ごうとしているのではないでしょうか?
自分で HTML を破棄する必要がある場合、Google のアプローチは非常に厄介に思えます。彼らはコンパイルされたアプローチを使用し、他の問題に頭脳サイクルを浪費する可能性があります。これは、アプリの複雑な UI を考えると正気です。要件がより緩和されたもの (その他のほとんどすべてを参照) に向かう場合は、努力する価値がないかもしれません。
GWT だけが Java を話しているのは残念ですが。
画像の読み込みを考慮せずにレイアウトの解析、読み込み、レンダリングにかかる時間 (domready が起動するポイント) に時間がかかりすぎて、UI の遅延が顕著になる場合は、おそらく、バックエンド、そしてそれがあなたの本当の問題です。
さらに、ページの最後の前の JavaScript は、JS が解析および評価されるまで、HTML 解析/DOM 評価を停止します。JavaScript についてアドバイスする前に、Google は Java に目を向けるべきです。
これはおそらく、Google が Javascript を持っていなくても気にしないためです。すでに機能している Web サイトに加えて Javascript を使用する場合は、スクリプトを DOMContentReady にロードするだけで十分です。重要なのは、Javascript を使用してユーザー エクスペリエンスを向上させることであり、Javascript を使用していない場合にユーザーを隔離することではありません。