20

私は常に JavaScript を下部と外部に維持しようとするため、Web サイトで外部 JavaScript を使用します。

しかし、Googleのページ速度はこの提案をしています

次の外部リソースには、小さなレスポンス ボディがあります。HTML で応答をインライン化すると、ページ レンダリングのブロックを減らすことができます。

http://websiteurl/は、次の小さなリソースをインライン化する必要があります: http://websiteurl/script.js

この外部 js ファイルには、このコンテンツのみが含まれています

$(document).ready(function() {
    $("#various2").fancybox({
        'width': 485,
        'height': 691,
    });
});

しかし、Yslowでは、この提案を受け取ります

JavaScript と CSS を外部化する上で等級なし

プロパティが一般的なユーザーのホームページである場合にのみ、これを考慮してください。

There are a total of 3 inline scripts

HTML ドキュメントにインライン化された JavaScript と CSS は、HTML ドキュメントが要求されるたびにダウンロードされます。これにより、HTTP 要求の数が減りますが、HTML ドキュメントのサイズが大きくなります。一方、JavaScript と CSS がブラウザーによってキャッシュされた外部ファイルにある場合、HTTP 要求の数を増やすことなく、HTML ドキュメントのサイズが縮小されます。

グーグルとヤフー、どっちが正しい？

4

7 に答える 7

15

これは、かなりの数の面で、少し問題のある例です。

その JS をインライン化する必要がないように、スクリプトを編成できます。たとえば、そのスニペットや他の同様のスニペットを実行し、コードを簡素化する common.js ファイルを作成できます。

さらに、これにより「JavaScript を決してインライン化しない」というアーキテクチャ警察が目覚めたようです。JavaScript をインライン化することがベスト プラクティスである場合があることがわかります。たとえば、Google アナリティクスの一般的なスニペットを見てください。

この小さなスクリプトをインライン化するようにGoogle が提案するのはなぜですか?

  • ページ訪問の 20% はプライミングされていないキャッシュを持っているためです。
  • キャッシュ ミスが発生した場合は、サイトへの新しい接続を開き (1 ラウンド トリップ)、2 回目のラウンド トリップでデータを配信する必要がある可能性があります。(運が良ければ、キープアライブ接続を使用でき、1 往復に短縮されます。
  • 一般的な「グローバル」な英語の Web アプリケーションの場合、米国でホストされているサービスの典型的な往復時間は 110 ミリ秒です。CDN を使用している場合、その数はおそらく半分になります。
  • リソースがローカルにある場合でも、Web ブラウザはディスクにアクセスしてその小さなファイルを取得する必要がある場合があります。
  • 非非同期または遅延 JavaScript スクリプト タグがブロックされています。このスクリプトがページの途中にある場合、スクリプトがダウンロードされるまでそこに留まります。

パフォーマンスの観点から、オプションが 2 つだけの場合:

  1. 50 文字の JavaScript ビットをインラインに配置する
  2. 50 文字を別のファイルに配置して提供します。

あなたが Web の善良な市民であり、すべてのコンテンツを圧縮していることを考えると、これによって追加されるペイロードの量は、人々にかなりの遅延を与える 20% のリスクに比べれば無視できるものです。私はいつも＃1を選びます。

不完全な世界では、これほど明快で簡単な選択肢があることはめったにありません。オプション 3 には、jQuery の非同期読み込みと、共通領域からのこの機能の取得が含まれます。

于 2012-03-15T05:41:48.003 に答える
2

これは正しくありません。Web サーバー (少なくとも apache) を構成して、スクリプト/cc が提供されるときにインライン化することができます。

ここに便利なリンクがあります

http://www.websiteoptimization.com/speed/tweak/mod_pagespeed/

于 2011-08-26T13:21:25.497 に答える
2

スクリプトをインラインにすると、いくつかの悪影響が生じる可能性があります -

a) コードの編成 - コードがマークアップの間に散らばり、可読性に影響を与える

b) コードの縮小化と難読化が困難になる

js を別々のファイルに保存し、ビルド時にそれらすべてを 1 つのファイルに統合し、これを縮小して難読化するのが最善です。

于 2011-08-26T13:25:11.243 に答える
1

ここで考慮すべき 2 つの要因があります。1 つはダウンロード時間、もう 1 つは保守性です。これらは両方とも、Javascript が何回必要になるかによって影響を受けます。

ダウンロード時間に関しては、明らかに 2 つの選択肢があります。ページの本文に JS を含めるか、外部ファイルとして含めるかです。ボディに JS を含めると、余分な HTTP リクエストを節約できますが、HTML が少し肥大化し、複数の異なるページにインラインで配置する複数のスクリプトがある場合は、維持するのが面倒になる可能性があります。

もう 1 つの重要な考慮事項は、JS がページ上ですぐに必要かどうかです。ページが読み込まれるとすぐに小さな JS が必要な場合は、インラインに配置することをお勧めします。将来的に非同期で使用する場合は、外部ファイルに配置することをお勧めします。

于 2011-08-26T13:23:02.160 に答える
0

昨年の Velocity EU での Aaron Peters の講演では、オプションと選択すべきコースについての優れた洞察が得られます - http://www.slideshare.net/startrender/fast-loading-javascript

js の非常に小さなスニペットの場合、それらを取得するためのネットワーク オーバーヘッドがメリットを小さくするため、それらを外部ファイルに入れる価値はありません。

待ち時間によっては、大きなスクリプトを含める価値があるかもしれません。たとえば、Bind モバイルは最初にロードされたページに大量の js を持っており、その後のページのために localstorage にキャッシュします。

Addy Osmani は最近、実験的なライブラリをまとめて、人々が localstorage のキャッシング スクリプトを操作できるようにしました - http://addyosmani.github.com/basket.js/

于 2012-03-15T09:25:39.040 に答える
0

スクリプトをインライン化するとリクエストが保存されますが、Yslow が提案するように、HTML ドキュメントのサイズが大きくなり、コンテンツ/マークアップとコード/ロジックが混在するため、一般的にはできるだけ避けたいと考えています。

Yslow がこの警告を与える理由:

プロパティが一般的なユーザーのホームページである場合にのみ、これを考慮してください。

ページが頻繁に読み込まれる場合は、ファイルがブラウザにキャッシュされるため、javascript を外部に置く価値があります。そのため、JS を 1 つのファイルに結合すると、最初のリクエストで 1 つの余分なリクエストが発生し、後続のリクエストでファイルがキャッシュから読み込まれます。

于 2011-08-26T13:39:09.670 に答える
0

特にスクリプトがこれほど小さい場合は、通常、JavaScript をインラインで記述します。コードに貼り付けるだけです。httpドキュメントのサイズが大幅に増加することはありません。

于 2011-08-26T13:20:56.797 に答える