1

複数のインライン スクリプト:

<script type="text/javascript">/* some codeblock 1 */</script>
<script type="text/javascript">/* some codeblock 2 */</script>
<script type="text/javascript">/* some codeblock 3 */</script>

結合された単一のインライン スクリプト:

<script type="text/javascript">
    /* some codeblock 1 */
    /* some codeblock 2 */
    /* some codeblock 3 */
</script>

複数のインライン スクリプトは遅くなりますか?

4

3 に答える 3

2

外部 JS をロードするのではなく、実際の HTML でコードを記述することについて話している場合、答えは、それは実際には問題ではないということです。

...ブラウザが視覚的な刺激のために 60fps でリクエストを処理しようとすると、必要に応じて変更されます... ...数マイクロ秒の違いは大きな影響を与えません。

非常に古いブラウザで、非常に多くのコード (おそらくタグごとに数千行、またはタグごとに数万行) を書こうとすると、倍数を使用すると顕著な違いが生じる可能性があります... ...しかし、その場合、単一の要素は依然として愚かなほど遅いでしょう。

于 2012-10-03T01:47:11.643 に答える
1

それが測定可能である可能性がある方法を見ることができません。

最新のブラウザのパーサーは非常に高速です-本質的にエンジンをソートしています。このブロックはHTMLエンジンに、このブロックはCSSエンジンに、このブロックはJavaScriptエンジンに送られます。これらのエンジンは処理に時間がかかる場合がありますが、ブロックを適切な場所に配置することはパフォーマンスの問題ではありません。

小さなページをダウンロードする際のパフォーマンスへの影響は、コードブロックを収集してエンジンに見送る場合のパフォーマンスへの影響よりも世界的に大きくなります。

さらに、JavaScript(および他の多くの相互作用言語)は、ロードおよび実行時にそれらをマシンコードに変換するプリプロセッサーを介して実行されます。今ではおそらくもっとファッショナブルな名前がありますが(おそらく「クラウド」が含まれています)、以前は「Just-in-TimeCompilation」(JIT)と呼ばれていました。

それはすべて非常に絡み合っていますが、基本的にページがロードされているときに、検出したすべてのスクリプトをこのJITエンジンに送信するだけです。この男はコードを収集し、それを最適化してメモリに保存し、実行する必要のあるものはすべて実行エンジンに渡します。物事が実行されて追加されると、物事を可能な限り合理化することが最もひどいことになります。

したがって、遅延したコード(たとえば、後で呼び出される関数)の場合、ブロックの数はまったく問題になりません。JITコンパイラは、とにかくブロック構造を無視するメモリ内で最適化されたコードを作成します。検出されたときにすぐに実行されるインラインコードの場合、スクリプトエンジンを使用するパーサーが非常に高速であるため、合理的な場合に違いを確認することはできません。

つまり、違いを示す可能性のあるテストケースを作成できる可能性があります。しかし、測定可能な違いが見られる前に、数千(または数万)のブロック範囲に向かう必要があると思います。その時点で、ファイルサイズ(新しいスクリプトブロックごとにファイルサイズに約40バイトが追加されます)やレンダリング時間などの他の変数が大きな影響を与えるため、実際には違いを確認できない場合があります。

結論:クリーンで文書化された論理コードを記述し、その下にあるコンパイラーを忘れてください。これにより、わずかな、気付かれないパフォーマンスの向上をもたらすのではなく、実際の時間とお金を節約できます。

于 2012-10-03T03:38:18.453 に答える
0

結合された単一のインラインスクリプトの方が少し速いと思います

于 2012-10-03T01:27:00.393 に答える