所謂快速的瀏覽器到底是什么意思？
原創【51CTO精選譯文】本文從技術和用戶體驗的角度，一一介紹了影響瀏覽器速度的因素，以及如何判定一個瀏覽器是否快速。本文作者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也只找到這樣一個頁面）。
為了使測試數據可以重現，通常的測試方式都是從本地讀取一個頁面文件，而不是從網絡上讀取加載（51CTO編者注：記得Google那個切土豆的視頻么？有細心的網友發現視頻中的測試頁面是本地地址，這實際上是瀏覽器速度測試的通用做法）。目前討論的基準測試當中，還沒有一個將網絡速度包含在測試因素內。這是一個遺憾，因為這是個很有趣的領域。比如說，不同的瀏覽器如何使用不同的單個host連接限制，或者Chrome如何在啟動時進行DNS預讀取（這個DNS預讀取的行為事實上比任何Web渲染或JS處理造成的影響都要大。你可以在Chrome中輸入about:dns進行進一步了解）。
網速之外，仍然有其它影響瀏覽器性能的環節，比如網絡協議層以及緩存。我記得在Chrome開發前期，Mike還是Nagle曾經發現過一個網絡層的bug，這個bug造成Chrome讀取網頁的速度遲于IE。上面所有的這些測試都無法呈現出這個bug的效果。另外從某種角度而言，將像素呈現在屏幕之上所花費的時間也可以算作一個環節。Gmail的加載更是一個瘋狂的多重過程，這個過程在例常的JavaScript和呈現的步驟之外還包含了好幾次重新導向、進度條等部分；而就我所知，似乎還沒有哪個測試是針對Gmail的加載速度而進行的。
#p#
秒表
所有的測試在本質上都是虛幻的，并不能代表真正的瀏覽過程。人們終于意識到這一點似乎是從微軟發布IE8開始，當時微軟的基準測試聲稱IE8是最快的瀏覽器。基準測試的某一項叫做“我們付錢雇了一些志愿者仔細的看，他們說我們是最快的”，然而不幸的是，而這一項測試的結果無論動機如何純潔，都無法使大多數人接受。事實上，這樣的測試比任何一種性能基準測試都更接近于我們的目標，但糟糕的是，這種測試的結果數據完全無法重現。也許瀏覽器開發者們會針對這點進行優化？
心理作用和Jank
人們稱一個瀏覽器為快速的原因不僅是上面提到的這些。從可測量的數字到模糊的秒表測試，我可以確認一點：比測試性能更重要的是，用戶感覺你快不快。下面我來講講這幾個和網頁無關的有趣因素。
其中一個叫做UI延遲（我們稱之為jank）。當你在地址欄里輸入的時候，瀏覽器的反應快么？創建新標簽頁的時候呢？Peter曾經就此做過一次演講，雖然我沒看，但應該是十分深入的一次課程。在對Ubuntu開發者演講時我也十分希望強調此點，那就是即使你的應用能夠在一秒之內呈現上千頁面，一個小小的問題仍會讓用戶感覺你的應用很慢（比如Ubuntu的軟件包更新工具在這方面我覺得就做的很糟）。我覺得這才是我們在性能上“超越”Mozilla，以及我們在Linux上日益流行的最大原因。當然，這是一個很難量化的因素。
減少jank的一個很好的例子就是Chrome中自動完成的實現。當你輸入URL時，我們從您的瀏覽歷史中提取URL的自動完成，以及相似地址的推薦。當你按下Enter鍵時，我們讓Chrome進行了同步自動完成，以確保你進入的地址正是你所看到的地址。當然這也便意味著我們不能從磁盤讀取數據，因為從磁盤讀取的過程會令自動完成有所延時。因此我們的做法是，將整個自動完成的數據在瀏覽器啟動時加載到內存當中（相比你的所有瀏覽歷史，這部分數據并不是很大）。
啟動
另一個有關性能的環節和上面所有的因素幾乎完全沒有關系，那就是啟動速度。我在之前的演講中提到了GNOME的計算器，不過他們現在已經修復了這個問題。好在類似的問題很多，比如Ubuntu的菜單也是，我每次都要數到5才能彈出菜單。對于Chrome的啟動我寫過十分詳細的技術文檔，從基準測試和適應低配系統等兩個方面闡述。現在我們來看看為什么這十分重要。
我相信一個應用的啟動速度確立了用戶對其性能的期待。事情總是這樣的：用戶認為你很快總是要比你事實上快不快來的重要。當你的啟動速度和輕量級應用一樣快時，用戶會覺得他們在使用一個輕量級應用，盡管事實并非如此（事實上，任何一個可以呈現頁面的瀏覽器都是龐大的應用，包括我們的Chrome）。比如說，即使到今天我還是習慣時不時的使用vi編輯器，因為emacs啟動實在太慢了。我甚至沒有意識到我在下意識的拒絕使用emacs。
當然，快速的啟動意味著在啟動時做更少的工作，因此整個代碼都需要進行仔細的工程。
結論
在Chrome工作三年，我從中學到的一大原則就是：如果你沒有考慮某個性能，那么這項性能必然會退步。這是軟件開發的一個自然現象，因為我們總是在為應用添加而非減少東西。因此，我們使用buildbots來為所有的性能測試創建圖表（該頁面巨大，當心瀏覽器崩潰）。每個退步的性能項都會變紅，這事經常發生，然后我們就要修改代碼。
總之一句話：基準測試僅僅在你了解該測試的技術細節時才有他的用處。如果你并非一個瀏覽器開發者，那么身為一個“專業人士”，我要說的是，自己打開網頁嘗試一下才是判斷哪個瀏覽器最快的最佳方法。
原文：http://neugierig.org/software/chromium/notes/2010/05/fast.html
【51CTO.com譯稿，合作站點轉載請注明原文譯者和出處。】
【編輯推薦】
