所謂快速的瀏覽器到底是什麼意思？(1)

BKJIA精選譯文】本文從技術和使用者體驗的角度，一一介紹了影響瀏覽器速度的因素，以及如何判定一個瀏覽器是否快速。本文作者Evan Martin是Google Chrome項目的開發人員，文章來自他的個人部落格，與Google官方並無關係。以下為原文編譯：

所謂快速的瀏覽器，到底是什麼意思？事實上這是個挺困難的問題。我在最近的Ubuntu開發人員峰會上被邀請談談這方面的問題，並寫下這篇文章進行補充。

基準測試

很多人會先想到基準測試。科技媒體喜愛基準測試，因為基準測試提供了數字，可以用來描繪美麗的對比圖。然而從本質上而言，基準測試衡量的都是十分具體的參數，僅能用來模仿使用者可能將經曆的過程。瀏覽器最重要的基準測試就是JavaScript基準測試，然而雖然沒人會否認JavaScript的重要性，但JavaScript畢竟不是大多數簡單網頁載入速度的決定性因素。我認為現在針對JavaScript引擎所作的改進主要是為了未來將被建立的站，比如這個JavaScript NES模擬器。當然了，像是Gmail這樣大大得利於快速JS引擎的站也不算少了。

通過JavaScript基準測試得出的結論往往是令人乏味的，比如：“Wine實現的Mozilla比Linux編譯的Mozilla快，所以Mozilla並不重視Linux”。JavaScript基準測試就是能夠得出這樣缺乏引導性的結論，而事實是，瀏覽器對於JavaScript的實現代碼在各個平台上都是幾乎完全一樣的！上面這個測試的速度差很可能來自編譯器品質的不同，所以Mozilla遇到的差別在其他跨平台瀏覽器上應該也能夠看到。這樣的評論從各個層面來看都是十分無聊的。第一，該結論毫無依據；第二，JavaScript基準測試從設計而言和平台毫無瓜葛；最後，這些基準測試甚至沒有針對每個平台特有的代碼進行測試。

新的基準測試正嘗試覆蓋JavaScript之外的內容。Dromaeo是個不錯的例子，這個測試有一部分是針對DOM的。不過，我們要小心第三方的基準測試！對於Dromaeo還好，它的作者John比其他大多數瀏覽器開發人員對Web開發的理解要來的更深入；但對其他人我就不怎麼放心了。寫一個看起來不錯的效能測試並不難，但它測試的不一定是有用的東西。好比說，SunSpider 0.9.1發布聲明中就有一段內容，有關測試架構與能源管理之間互動的一個bug。要知道，這個bug涉及到的作者是一個經驗豐富的瀏覽器開發人員，而不是隨便哪個Web開發愛好者。

周期計時

一個更好的測量方法可能是觀察瀏覽器從頭至尾載入一個真實的網頁的效能，這個過程包含了JavaScript引擎以及其他組件的工作：HTML解析，字型測量等等。我們和Mozilla我想其他瀏覽器廠商應該也都有）都有針對本地頁面的測試載入器。對於第三方測試者而言，通過使用這些工具來測試比較瀏覽器的載入速度是很自然的選擇，唯一的不同在於他們的測試對象是真實的網頁如Yahoo首頁），其測試結果也往往是有著作權而無法公開的就我所知，我們的測試頁都被設為隱私；而我在Mozilla也只找到這樣一個頁面）。

為了使測試資料可以重現，通常的測試方式都是從本地讀取一個分頁檔，而不是從網路上讀取載入BKJIA編者註：記得Google那個切馬鈴薯的視頻嗎？有細心的網友發現視頻中的測試頁面是本地地址，這實際上是瀏覽器速度測試的通用做法）。目前討論的基準測試當中，還沒有一個將網路速度包含在測試因素內。這是一個遺憾，因為這是個很有趣的領域。比如說，不同的瀏覽器如何使用不同的單個host串連限制，或者Chrome如何在啟動時進行DNS預讀取這個DNS預讀取的行為事實上比任何Web渲染或JS處理造成的影響都要大。你可以在Chrome中輸入about:dns進行進一步瞭解）。

 

網速之外，仍然有其它影響瀏覽器效能的環節，比如網路通訊協定層以及緩衝。我記得在Chrome開發前期，Mike還是Nagle曾經發現過一個網路層的bug，這個bug造成Chrome讀取網頁的速度遲於IE。上面所有的這些測試都無法呈現出這個bug的效果。另外從某種角度而言，將像素呈現在螢幕之上所花費的時間也可以算作一個環節。Gmail的載入更是一個瘋狂的多重過程，這個過程在例常的JavaScript和呈現的步驟之外還包含了好幾次重新導向、進度條等部分；而就我所知，似乎還沒有哪個測試是針對Gmail的載入速度而進行的。