ブラウザのJavascript機能を見積もるにはどうすればよいですか？

Question

私は、クライアントがヒットするとすぐに非常に多くのJavaScriptの仕事をするウェブページを提供します。作業量はコンテンツの量に比例しますが、その量は大きく異なります。

膨大な量のコンテンツがある場合、クライアントが「応答しないスクリプト - キャンセルしますか？」のいずれかでクライアントを発行するのに時間がかかることがあります。メッセージ。内容がほとんどない場合、作業は目の瞬きで終わります。

私は、コンテンツがある値Xより大きい場合、ハードワークが始まる前に表示される「これはしばらく時間がかかる」というメッセージをユーザーに表示する機能を追加しました。

この特定のページでは、ChromeはFirefoxよりも非常に高速で、IEよりも速いため、Xには良い値があります。私はすべてのユーザーに適切なときに警告したいと思いますが、気を散らすので100msの間だけそこにいるときにメッセージを置いてはいけません。言い換えれば、私はXの値がブラウザのJavascriptの能力にも依存することを望みます。

誰もブラウザの機能を理解する良い方法はありますか？私は現在、ブラウザを明示的にオフラインにすることを検討していますが、それはハッキーに見えますが、他の要因が関係していると思います。

Answer 1

データが比較的均質である場合、データの特定のサブセットがどのくらいの期間経過したかを確認し、セット全体の時間を控えめに見積もるヘルパー機能を持つ方法があります。

そこからメッセージを表示するかどうかを決定します。

Answer 2

これはあなたが行きたいところではないかもしれませんが、あなたは良いアイデアを持っていますかなぜ JavaScriptが長時間かかるのですか？それは有線を介してコンテンツの束をダウンロードしているか、ブラウザ上の遅い部分の実際のフォーマット/チャニングですか？

シバン全体が長い時間がかかりますが、ユーザーがコンテンツ 'ビルド'を見て警告する必要がないように、段階的に何かを行うことさえできるかもしれません。

Answer 3

Xが何であるかをユーザーに決定させるのはなぜですか？ （たとえば、ページ選択機能では「display 10 | 20 | 50 | 100」のように表示されます）次に、測定/推測をまったく行う必要はありません。最適なレイテンシ/情報コンテンツのトレードオフを行うことができます。

Answer 4

これはやや誤解を招きます。通常、ブラウザのJS機能について説明するとき、ネイティブXMLHTTPをサポートしているかなど、ブラウザの実際の機能を参照していますか？それはActiveXをサポートしていますか？

に関係なく、ブラウザの処理能力やスピードを確実に推定する方法はありません。単純なストレステストを実行し、結果を計算し、過去のパフォーマンスのリストと比較して、現在のユーザーのブラウザがランク付けされている場所を確認し、この情報を使用して推定時間に到着する可能性があると考えるかもしれません。ここでの問題は、これらの計算がブラウザー（または単にOS）のアクティビティーによって影響を受けるだけでなく、たとえば、プロファイリングスクリプトを実行すると、ユーザーのAVスキャナーは、午後5時に起動します。通常は2秒かかるかもしれないが、20秒かかる。

あなた自身に尋ねることは、次のようなことです：この処理は今すぐ実行する必要がありますか？ n8wrlとBeskaが指摘しているように、独自のメソッドをコーディングする必要があるかもしれません。その場合、チャンクにまとめる作業を分割し、一度に1つずつsetTimeout（）などの操作を行います。これは、エンジンの時間を「呼吸」させることになり、うまくいけば「応答しないスクリプト」の警告を避けることができます。これらのチャンクのそれぞれは、作業が完了していることをユーザに示すプログレスバー（または同様のもの）を更新するために使用することもできます。

また、GMailのようなアプローチをとることもできます。ウィンドウの隅に赤色の「読み込み中の...」テキストエリアが点滅します。時には数秒間そこにあることもありますが、それを読むのに十分な時間がないこともあります。それ以外の場合は、何度か点滅します。しかし、あなたはを知っています何かをしているとき。

最後に、ページを徐々に「ビルド」する時点でも、Chromeの新しいタブページのソースを調べることができます。注：これは "ソースの表示"を使って見ることはできません。代わりに、 "javascript console"オプションを選択して（新しいタブページで）HTMLソースを見てください。このようように、彼らの一般的な戦略を説明するコメントがあるはずです：

<!-- This page is optimized for perceived performance. Our enemies are the time 
taken for the backend to generate our data, and the time taken to parse 
and render the starting HTML/CSS content of the page. This page is 
designed to let Chrome do both of those things in parallel. 

1. Defines temporary content callback functions 
2. Fires off requests for content (these can come back 20-150ms later) 
3. Defines basic functions (handlers) 
4. Renders a fast-parse hard-coded version of itself (this can take 20-50ms) 
5. Defines the full content-rendering functions 

If the requests for content come back before the content-rendering functions 
are defined, the data is held until those functions are defined. --> 

わからないという場合に役立ちますが、私はそれは大きな選手の一部は、このような課題をどのように処理するかの洞察を与えるんだと思います。