這有點誤導;通常當討論瀏覽器的JS功能時,它指的是瀏覽器的實際功能,例如它是否支持本機XMLHTTP?它支持ActiveX嗎?等
無論如何,沒有辦法可靠地推斷出瀏覽器的處理能力或速度。有人可能會認爲您可以進行一些簡單的壓力測試,計算結果並與過去的表現進行比較,以查看當前用戶的瀏覽器排名,並可能使用此信息來估計時間。這裏的問題在於,這些計算不僅受瀏覽器中的活動(或僅在OS上)的影響;例如,你運行你的分析腳本,用戶的AV掃描器啓動,因爲它的下午5點;通常可能需要2s,需要20s。
在事情要問自己,是:是否這個處理必須發生的權利嗎?正如n8wrl和Beska所指出的那樣,您可能需要編寫自己的方法,從而將工作分解爲塊,然後逐個對它們進行操作並使用setTimeout()之類的方法。這會讓引擎有時間「呼吸」 - 因此希望避免「無響應的腳本」警告。這些塊中的每一塊都可以用來更新進度條(或類似的),使用戶可以指出正在進行的工作。
或者你可以採取像GMail這樣的方法 - 它們在窗口的角落閃爍一個非常小的紅色「加載...」文本區域。有時在那裏呆幾秒鐘,有時不夠長時間閱讀。其他時候它會多次閃爍。但你知道什麼時候做什麼事。
最後,在增量式構建頁面的時候,您可以查看Chrome新標籤頁的來源。注意:您無法使用「查看源代碼」查看此內容;相反,選擇「javascript控制檯」選項(在新標籤頁上),然後查看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. -->
不知道有沒有什麼幫助,但我認爲它確實給深入瞭解一些大牌球員處理像這樣的挑戰。
來源
2009-08-06 15:24:19
ken
正是我在想什麼。 – 2009-08-06 13:40:54