10

これは実際のコーディングの問題ではなく、実際のステートメントです。

私は以前、イベントが非常に遅いことを指摘しました。DOMReadyそのため、jQuery ソースを参照しているときに、jQuery domeready イベントを .xml を使用してトリガーできることに気付きました$.ready()。次に、本体を閉じる直前にこの単純な実行スクリプトを配置すると、以前に接続されていたすべての「onDomReady」リスナーがトリガーされるはずだと思いました。はい、期待どおりに動作します。

     <script>$.ready()</script>
</body>

以下に 2 つの例を示します。これは、DOMReady の待機中に費やされたミリ秒を測定します。

http://jsbin.com/aqifon/10

ご覧のとおり、DOMReady トリガーはネイティブに非常に遅く、ユーザーは domready スクリプトが起動するまで 200 ～ 300 ミリ秒待たなければなりません。

とにかく、タグを$.ready()閉じる直前に配置すると、次のようBODYになります。

http://jsbin.com/aqifon/16

違いを見ます？domready を手動でトリガーすることにより、100 ～ 300 ミリ秒の実行遅延をカットできます。jQuery を利用して DOM 操作を確認する前に処理できるため、これは大きな問題です。

さて、質問ですが、これが推奨されたり議論されたりしたことは一度もありませんが、それでもパフォーマンス上の大きな問題のようです。すべてはコード自体の最適化に関するものであり、もちろんそれは良いことですが、ユーザーが「unjQueryedContent」のフラッシュを見るほど実行が長時間遅れると無駄になります。

これがより頻繁に議論/推奨されない理由はありますか?

4

3 に答える 3

4

自分でイベントをトリガーすることにより、ready() ハンドラーに対して、DOM がロードされたが、ロードされていない可能性があることを示しています。DOM 準備完了イベントに近道はありません。実際に長い待ち時間がある場合は、firebug、chrome などの素晴らしいデバッグ ツールを使用してください。リソースとそのタイミング キューを確認してください。それはすべて白黒であり、何が非常に時間がかかっているかを示します (リクエスト、レンダリング、リソースの数など..)

于 2012-10-12T00:39:30.067 に答える
3

これがより頻繁に議論/推奨されない理由はありますか？

JavaScriptを直前に配置すること</body>については多くの議論がありましたが、ご存知のように、より高速なページの読み込みを探している場合は、JavaScriptを使用することをお勧めします。jQueryreadyハンドラーを手動でトリガーすることについては、実際にはあまり議論されていません。なんで？まあ、それに対する単一の客観的な答えはないと思いますが、ここでいくつかの可能性を概説しようと思います：

  1. パフォーマンスはjQueryの主な目標ではありません（それは間違いなく懸念事項ですが）。パフォーマンスフリークは通常、クロスブラウザーDOM操作とイベント処理用のより軽量なライブラリを探すか、独自のライブラリをロールバックします。

  2. これは余分な手順であり、きれいに見えません。jQueryはクリーンでエレガントなものを目指しており、スクリプトを初期化するための追加の手順を推奨することは、これから起こることのようには思えません。彼らはにバインドすることをready推奨しているので、実際のブラウザイベントを強制.ready()して無視することを推奨することは「間違っている」ように見えます。それを心配している人なら誰でも、直前にスクリプトを初期化する</body>方が速いことをおそらく知っているでしょう。

  3. 最適化DOMContentLoadedは、ブラウザベンダーの仕事のように聞こえます。ただし、なぜ遅くなるのかはわかりません。おそらく、最適化の余地はあまりありません。私の理解では、initスクリプトを呼び出すことが、常に初期化する最速の方法であるはずです（ブラウザーの場合、コンテナータグを</body>解析するとすぐに実行されるため）。<script>トリガーする前にファイル全体の解析を終了する必要がありますDOMContentLoaded）。

<script>少し前までは、HTMLのいたるところにブロックを分散させるのが一般的だったことを覚えているでしょう。その後、Web標準の動きが起こり、物事を行うためのより正気で保守可能な方法が推奨されました。これには、単一の場所からのブートストラップスクリプトが含まれていました。最初は、window.onload遅いために問題があると考えられていましたが、DOMContentLoadedIE8以下のエミュレーションです。ただし、StackOverflowでは、毎日どこにでもスクリプトを含むスパゲッティHTMLが表示されます。したがって、本文の最後の前にスクリプトを配置することをお勧めすることが、今日の良い呼びかけであるかどうかはわかりません。これは、本文内のどこにでもスクリプトを追加するためのライセンスとして解釈される可能性があるためです。

最後に、スクリプトを高速にロードすることに本当に関心があり、コードがDOMを操作しない場合、スクリプトをロードする最も速い方法は、<head>スタイルシートの前にスクリプトを配置することです。そして、特効薬はなく、すべてのシナリオで最も高速でエレガントなスクリプトを初期化する最適な方法はないと言っているだけです。だからこそ、コミュニティは、他のより優れたパフォーマンスの代替手段ではなく、正気に見え、より保守しやすいコードを作成する傾向があるものを推奨することに固執しているのだと思います。

于 2012-10-14T02:16:29.890 に答える
3

実際、タグの前に関数呼び出しを配置すると、</body>jQuery のready(). ドキュメントの準備ができたときに呼び出される必要がある他のすべての関数の呼び出しを含むネイティブ JS ラッパー関数呼び出しを配置するだけです。

一般に、作成者が jQuery をまったく使用する必要がない、または使用したくない場合の代替手段として機能します (ただし、HTML コードがやや散らかっているため、完璧主義者には受け入れられません)。DOMContentLoadedただし、そのような状況では、IE9+ を含むほとんどのブラウザーでサポートされているネイティブ イベント ハンドラーを使用することをお勧めします (IE8 の場合window.load()は、受け入れ可能なフォールバックとして使用できます)。

于 2012-10-12T00:52:01.603 に答える