重複の可能性:
ページの下部に Javascript がありますか?
Twitterのブートストラップの例でコメントを見ました。それは言う
JavaScript をドキュメントの最後に配置して、ページの読み込みを高速化
これは本当ですか??はいの場合、どのように機能しますか??
重複の可能性:
ページの下部に Javascript がありますか?
Twitterのブートストラップの例でコメントを見ました。それは言う
JavaScript をドキュメントの最後に配置して、ページの読み込みを高速化
これは本当ですか??はいの場合、どのように機能しますか??
数々のメリットがあります
- DOM がロードされているかどうかを確認する必要はありません。最後にスクリプトを配置することで、DOM がロードされていることが確実にわかるからです。
- JavaScript スクリプト ファイルは、Web ブラウザが次の JavaScript ファイルを開始する前に、完全にロードする必要があります。この結果、JavaScript ファイルがドキュメントの上部に含まれている場合、エンド ユーザーが実際のページを見る前に視覚的な遅延が発生します。ドキュメントの最後に JavaScript ファイルを含めると、これは完全に回避されます。
いくつかの制限もあります
下部に JavaScript ファイルを含めると、ページのレンダリングが遅れるという問題を回避するのに役立ち、Web サイトの各ページの読み込みが速くなるという印象を与えますが、欠点もあります。
ページがエンド ユーザーに表示されていても、JavaScript ファイルの読み込みが完了していない場合、要素にはまだイベントが適用されておらず (誰もが目立たないアプローチを使用しているためですよね?)、ユーザーはあちこちクリックして、期待される結果を得る。
JavaScript がサポートされていて、適切なイベントが適用されている場合に AJAX 経由でコンテンツを取得するリンク要素など、適切なフォールバックがある場合、それ以外の場合は別のページにつながる通常のリンクである場合、問題はそれほど悪くありません。それでもやや面倒ですが。
お役立ち記事はこちら
ブラウザーが<script>
タグに遭遇すると、HTMLRendererはデフォルトで停止し、ECMAscriptパーサーがその仕事をします。HTMLRendererは、すべての Javascript コードが完全に評価されるまで続行されません。
そのため、 「上部<script>
」の HTML コードに多数のタグと多数の Javascript コードがある場合、サイトの閲覧者は読み込みプロセスが遅いことに気付く可能性があります。
この問題を回避するには、いくつかの方法があります。1つ目は、あなたが述べたように、すべてのJavascriptコードとタグを要素<script>
の一番下に配置することです. <body>
これにより、少なくともすべてのHTML マークアップとスタイルシート定義が完全に読み込まれたことが保証されます。
別のオプションは、要素自体のタグ名です。や など<script>
は、ブラウザ/ JS パーサーに、この塗りつぶしがロードされてすぐに評価される必要がないことを示します。例えばasync
defer
<script async defer src="/foo/bar.js"></script>
HTML レンダラーはタグを認識してキューに格納しますが、直接停止して評価することはありません。
ほとんどのブラウザーは、JavaScript を実行し、同じスレッドを使用してページを読み込みます。したがって、JavaScript の実行中はページを読み込めません。したがって、ページに多数の画像や埋め込みコンテンツが含まれている場合、これらのアセットは JavaScript の実行が完了するまでロードを開始しません。
これが、長時間実行される同期コードをドキュメントの最後に配置するか、ページの読み込み時または DOM コンテンツの読み込み時に読み込みを遅らせることをお勧めする理由です。ただし、最新のブラウザーは通常、長時間実行されているブロック スクリプトについてユーザーに通知し、必要に応じてスクリプトを終了できるようにします。
ページの最後に配置することと同じくらい重要なのは、HTML5属性を使用して非同期として指定することです。async
これにより、パーサーがそれらを停止して解析するのではなく、ページの読み込みフローを続行し、JS を並行してダウンロード/解析することが保証されます。
この概念の背後にあるロジックは、ブラウザーがスクリプトの前にすべての html 要素を配置することによってその場でコードをレンダリングするため、処理するスクリプトの量が天文学的であると仮定すると、最初にスクリプトを用意した場合よりも理論的には高速にロードできるということです。と。
ただし、実際には、D/L 帯域幅などの差し迫ったボトルネックを介して Web サイトの読み込み時間に影響を与えるほど多くのスクリプト時間が必要になるような状況に遭遇することはありません。