0

NSFW：サイトは大麻の種を販売しているので、リンクはNSFWであることに注意してください。

同じまたは非常に類似したシステムで実行されているWebサイトがいくつかあり、それらはすべて1つから離れて非常に高速に実行され、理由を理解できません。これは主に私の経験不足によるものですが、Firebugの[ネット]タブを確認しました。よく理解できているかわかりません。

高速なWebサイトの1つが製品ページのサイズとコンテンツが80.33kbであり、表示に1.28秒の待機と598ミリ秒の読み込みが必要であり、低速のWebサイトのサイズとコンテンツが158kbであることがわかります。レイテンシは4.75秒で、そのうち4.55秒が待機しています。

この待ち時間を短縮する方法と、サイズとコンテンツの数値が大きく異なる理由を本当に知りたいです。このページで問題を確認できます。

4

2 に答える 2

2

あなたはページ全体にJavaScriptの真のがらくたトンを持っています。

目標は、JSをまったく使用せずに可能な限り物理的にロードしてから、すべてのJSロードを一番下で実行することです。

また、さまざまなJSスクリプトがたくさんあります。のように...本当にたくさん。

表示する必要のある順序を把握し、その順序で1つのファイル（または半ダースなど）に貼り付けることを検討してください。ただし、Googleは、その1ページに数十のJSファイルがあることを示唆しています。 ）、ページの下部にロードします。

これは、ページへの読み込みを延期することについてもう少し学ぶ必要があることを意味する可能性があり、関心の分離をもう少し学ぶ必要があることを意味する可能性があります（私はそれを見るためにあなたの旗よりも詳しく調べませんでした誰もがonclickハンドラーを持っていましたが、これは間違いなく巨大なことを行います。すべてのフラグを保持するコンテナーに1つのリスナーを追加し、それがどれであるかを識別してそこから実行する方がよいでしょう）。

ただし、JSファイルがダウンロードされると、ブラウザは一時停止してすべてをコンパイルします。これは通常、ほんの一瞬です。しかし、数十のファイルが次々に並んでいる場合は、ファイルをロードするための一時停止、ファイルの内容にアクセスするための一時停止、ファイル内のJSをコンパイルするための一時停止、そしてJSを実行します。サイトの次の部分の表示に移ります...

したがって、これらの小さな一時停止はすべて合計されます。

そのため、必要なJSだけを提供し、ページの下部で提供し、その後少しで便利なものをロードする必要があります。数百行のコードを含む単一のファイルをコンパイルする場合でも、数十行しかない10個のファイルをコンパイルするよりも時間がかかりません。

結局のところ、それはユーザーが何をしているのかということであり、ダウンロードのベンチマークの速さではありません。

于 2012-09-29T04:22:01.767 に答える
1

開発ツールの[Chromeネットワーク]タブを使用してページの読み込みを見ると、次のリンクで次のタイミングを受け取ります。

http://www.seed-city.com/barneys-farm-seeds/liberty-haze

102 requests | 131.24KB | 8.41s (onload: 8.50s, DOMContentLoaded: 6.61s)
102 requests | 131.47KB | 8.47s (onload: 8.56s, DOMContentLoaded: 6.82s)
102 requests | 131.45KB | 8.71s (onload: 8.79s, DOMContentLoaded: 7.06s)

ここで、1つの（やや単純な）変更を行います。

103 requests | 110.16KB | 3.77s (onload: 3.86s, DOMContentLoaded: 2.03s)
103 requests | 110.17KB | 3.85s (onload: 3.94s, DOMContentLoaded: 2.21s)
103 requests | 110.16KB | 4.20s (onload: 3.50s, DOMContentLoaded: 2.28s)

現在のページの[ネットワーク]タブから出力される一般的なHARログは次のとおりです。

http://pastebin.com/pM5Dd1Fw

重要なのは、ブラウザが何かを実行するのに5秒近く待機していることを理解することです（関連する行を表示するためだけに挿入されます）。

{
  "startedDateTime": "2012-09-29T04:58:07.861Z",
  "time": 4831,
  "request": {
    "method": "GET",
    "url": "http://www.seed-city.com/barneys-farm-seeds/liberty-haze",
    "httpVersion": "HTTP/1.1",
    ...
  },
  "cache": {},
  "timings": {
    "blocked": 0,
    "dns": 16,
    "connect": 129,
    "send": 0,
    "wait": 4677,        // <<< Right here
    "receive": 8,
    "ssl": -1
  }
}

そして、slow.htmlページのタイミング：

{
  "startedDateTime": "2012-09-29T05:04:51.624Z",
  "time": 92,
  "request": {
    "method": "GET",
    "url": "http://example.com/t/slow.html",
    "httpVersion": "HTTP/1.1",
    ...
  },
  "timings": {
    "blocked": 0,
    "dns": 7,
    "connect": 38,
    "send": 0,
    "wait": 44,           // <<< Right here
    "receive": 1,
    "ssl": -1
  },
  "pageref": "page_3"
}

それは4677ms対44msです。その更新されたページの典型的なHARログは次のとおりです。

http://pastebin.com/Jgm1YyU3

では、これらの（非常に現実的で具体的な）改善を達成するために私は何をしましたか？Javascriptをbodyタグの一番下に移動しました：

http://pastebin.com/H9ajG99H

これにより、2倍の改善が見られます。scriptまず、ブラウザがブロックプロセス（呼び出し）との対話を開始する前に、ブラウザが続行してコンテンツをロードできるようにします。したがって、ページの読み込みが速いように見えるという理由だけで、顧客はより高速なサイトに「気付く」でしょう（実際には、ページの読み込みを許可しているだけの場合）。次に、bodyタグが基本的に完全にロードされるまで待ってから、そのコンテンツでモンキーを開始します。

また、ファイルの更新を長時間チェックしないようにブラウザに指示するキャッシュディレクティブをヘッダーで使用していないようです。つまり、TwitterとFacebookのアイコンは、ブラウザがサーバーに再確認する必要があると考えているように見えます。これにより、理論的には、それほど頻繁ではない場合を除いて、ラウンドトリップが不要になります。しかし、「待機」に費やした時間：

twitter_aqu_64.png 1.32s
ajax-loader.gif    1.31s
ssl-icon.jpg       1.31s

現在、私はキャッシュ制御の専門家ではありません。それは少し暗い芸術です。しかし、それらのタイミングは、そこで何かが起こっているのではないかと私に思わせます。

キャッシュ制御の詳細については、次の回答を試してください。

HTMLキャッシュコントロール

于 2012-09-29T05:20:23.807 に答える