所謂快速的瀏覽器到底是什么意思？
原創(chuàng)【51CTO精選譯文】本文從技術(shù)和用戶體驗(yàn)的角度，一一介紹了影響瀏覽器速度的因素，以及如何判定一個(gè)瀏覽器是否快速。本文作者Evan Martin是Google Chrome項(xiàng)目的開發(fā)者，文章來自他的個(gè)人博客，與Google官方并無關(guān)系。以下為原文編譯：
所謂快速的瀏覽器，到底是什么意思？事實(shí)上這是個(gè)挺困難的問題。我在最近的Ubuntu開發(fā)者峰會(huì)上被邀請(qǐng)談?wù)勥@方面的問題，并寫下這篇文章進(jìn)行補(bǔ)充。
基準(zhǔn)測試
很多人會(huì)先想到基準(zhǔn)測試?？萍济襟w喜愛基準(zhǔn)測試，因?yàn)榛鶞?zhǔn)測試提供了數(shù)字，可以用來描繪美麗的對(duì)比圖。然而從本質(zhì)上而言，基準(zhǔn)測試衡量的都是十分具體的參數(shù)，僅能用來模仿用戶可能將經(jīng)歷的過程。瀏覽器最重要的基準(zhǔn)測試就是JavaScript基準(zhǔn)測試，然而雖然沒人會(huì)否認(rèn)JavaScript的重要性，但JavaScript畢竟不是大多數(shù)簡單網(wǎng)頁加載速度的決定性因素。我認(rèn)為現(xiàn)在針對(duì)JavaScript引擎所作的改進(jìn)主要是為了未來將被創(chuàng)建的站，比如這個(gè)JavaScript NES模擬器。當(dāng)然了，像是Gmail這樣大大得利于快速JS引擎的站也不算少了。
通過JavaScript基準(zhǔn)測試得出的結(jié)論往往是令人乏味的，比如：“Wine實(shí)現(xiàn)的Mozilla比Linux編譯的Mozilla快，所以Mozilla并不重視Linux”。JavaScript基準(zhǔn)測試就是能夠得出這樣缺乏引導(dǎo)性的結(jié)論，而事實(shí)是，瀏覽器對(duì)于JavaScript的實(shí)現(xiàn)代碼在各個(gè)平臺(tái)上都是幾乎完全一樣的！上面這個(gè)測試的速度差很可能來自編譯器質(zhì)量的不同，所以Mozilla遇到的差別在其他跨平臺(tái)瀏覽器上應(yīng)該也能夠看到。這樣的評(píng)論從各個(gè)層面來看都是十分無聊的。第一，該結(jié)論毫無依據(jù)；第二，JavaScript基準(zhǔn)測試從設(shè)計(jì)而言和平臺(tái)毫無瓜葛；最后，這些基準(zhǔn)測試甚至沒有針對(duì)每個(gè)平臺(tái)特有的代碼進(jìn)行測試。
新的基準(zhǔn)測試正嘗試覆蓋JavaScript之外的內(nèi)容。Dromaeo是個(gè)不錯(cuò)的例子，這個(gè)測試有一部分是針對(duì)DOM的。不過，我們要小心第三方的基準(zhǔn)測試！對(duì)于Dromaeo還好，它的作者John比其他大多數(shù)瀏覽器開發(fā)者對(duì)Web開發(fā)的理解要來的更深入；但對(duì)其他人我就不怎么放心了。寫一個(gè)看起來不錯(cuò)的性能測試并不難，但它測試的不一定是有用的東西。好比說，SunSpider 0.9.1發(fā)布聲明中就有一段內(nèi)容，有關(guān)測試框架與能源管理之間交互的一個(gè)bug。要知道，這個(gè)bug涉及到的作者是一個(gè)經(jīng)驗(yàn)豐富的瀏覽器開發(fā)者，而不是隨便哪個(gè)Web開發(fā)愛好者。
周期計(jì)時(shí)
一個(gè)更好的測量方法可能是觀察瀏覽器從頭至尾加載一個(gè)真實(shí)的網(wǎng)頁的性能，這個(gè)過程包含了JavaScript引擎以及其他部件的工作：HTML解析，字體測量等等。我們和Mozilla（我想其他瀏覽器廠商應(yīng)該也都有）都有針對(duì)本地頁面的測試工具。對(duì)于第三方測試者而言，通過使用這些工具來測試比較瀏覽器的加載速度是很自然的選擇，唯一的不同在于他們的測試對(duì)象是真實(shí)的網(wǎng)頁（如Yahoo主頁），其測試結(jié)果也往往是有版權(quán)而無法公開的（就我所知，我們的測試頁都被設(shè)為隱私；而我在Mozilla也只找到這樣一個(gè)頁面）。
為了使測試數(shù)據(jù)可以重現(xiàn)，通常的測試方式都是從本地讀取一個(gè)頁面文件，而不是從網(wǎng)絡(luò)上讀取加載（51CTO編者注：記得Google那個(gè)切土豆的視頻么？有細(xì)心的網(wǎng)友發(fā)現(xiàn)視頻中的測試頁面是本地地址，這實(shí)際上是瀏覽器速度測試的通用做法）。目前討論的基準(zhǔn)測試當(dāng)中，還沒有一個(gè)將網(wǎng)絡(luò)速度包含在測試因素內(nèi)。這是一個(gè)遺憾，因?yàn)檫@是個(gè)很有趣的領(lǐng)域。比如說，不同的瀏覽器如何使用不同的單個(gè)host連接限制，或者Chrome如何在啟動(dòng)時(shí)進(jìn)行DNS預(yù)讀?。ㄟ@個(gè)DNS預(yù)讀取的行為事實(shí)上比任何Web渲染或JS處理造成的影響都要大。你可以在Chrome中輸入about:dns進(jìn)行進(jìn)一步了解）。
網(wǎng)速之外，仍然有其它影響瀏覽器性能的環(huán)節(jié)，比如網(wǎng)絡(luò)協(xié)議層以及緩存。我記得在Chrome開發(fā)前期，Mike還是Nagle曾經(jīng)發(fā)現(xiàn)過一個(gè)網(wǎng)絡(luò)層的bug，這個(gè)bug造成Chrome讀取網(wǎng)頁的速度遲于IE。上面所有的這些測試都無法呈現(xiàn)出這個(gè)bug的效果。另外從某種角度而言，將像素呈現(xiàn)在屏幕之上所花費(fèi)的時(shí)間也可以算作一個(gè)環(huán)節(jié)。Gmail的加載更是一個(gè)瘋狂的多重過程，這個(gè)過程在例常的JavaScript和呈現(xiàn)的步驟之外還包含了好幾次重新導(dǎo)向、進(jìn)度條等部分；而就我所知，似乎還沒有哪個(gè)測試是針對(duì)Gmail的加載速度而進(jìn)行的。
#p#
秒表
所有的測試在本質(zhì)上都是虛幻的，并不能代表真正的瀏覽過程。人們終于意識(shí)到這一點(diǎn)似乎是從微軟發(fā)布IE8開始，當(dāng)時(shí)微軟的基準(zhǔn)測試聲稱IE8是最快的瀏覽器。基準(zhǔn)測試的某一項(xiàng)叫做“我們付錢雇了一些志愿者仔細(xì)的看，他們說我們是最快的”，然而不幸的是，而這一項(xiàng)測試的結(jié)果無論動(dòng)機(jī)如何純潔，都無法使大多數(shù)人接受。事實(shí)上，這樣的測試比任何一種性能基準(zhǔn)測試都更接近于我們的目標(biāo)，但糟糕的是，這種測試的結(jié)果數(shù)據(jù)完全無法重現(xiàn)。也許瀏覽器開發(fā)者們會(huì)針對(duì)這點(diǎn)進(jìn)行優(yōu)化？
心理作用和Jank
人們稱一個(gè)瀏覽器為快速的原因不僅是上面提到的這些。從可測量的數(shù)字到模糊的秒表測試，我可以確認(rèn)一點(diǎn)：比測試性能更重要的是，用戶感覺你快不快。下面我來講講這幾個(gè)和網(wǎng)頁無關(guān)的有趣因素。
其中一個(gè)叫做UI延遲（我們稱之為jank）。當(dāng)你在地址欄里輸入的時(shí)候，瀏覽器的反應(yīng)快么？創(chuàng)建新標(biāo)簽頁的時(shí)候呢？Peter曾經(jīng)就此做過一次演講，雖然我沒看，但應(yīng)該是十分深入的一次課程。在對(duì)Ubuntu開發(fā)者演講時(shí)我也十分希望強(qiáng)調(diào)此點(diǎn)，那就是即使你的應(yīng)用能夠在一秒之內(nèi)呈現(xiàn)上千頁面，一個(gè)小小的問題仍會(huì)讓用戶感覺你的應(yīng)用很慢（比如Ubuntu的軟件包更新工具在這方面我覺得就做的很糟）。我覺得這才是我們?cè)谛阅苌?ldquo;超越”Mozilla，以及我們?cè)贚inux上日益流行的最大原因。當(dāng)然，這是一個(gè)很難量化的因素。
減少jank的一個(gè)很好的例子就是Chrome中自動(dòng)完成的實(shí)現(xiàn)。當(dāng)你輸入U(xiǎn)RL時(shí)，我們從您的瀏覽歷史中提取URL的自動(dòng)完成，以及相似地址的推薦。當(dāng)你按下Enter鍵時(shí)，我們讓Chrome進(jìn)行了同步自動(dòng)完成，以確保你進(jìn)入的地址正是你所看到的地址。當(dāng)然這也便意味著我們不能從磁盤讀取數(shù)據(jù)，因?yàn)閺拇疟P讀取的過程會(huì)令自動(dòng)完成有所延時(shí)。因此我們的做法是，將整個(gè)自動(dòng)完成的數(shù)據(jù)在瀏覽器啟動(dòng)時(shí)加載到內(nèi)存當(dāng)中（相比你的所有瀏覽歷史，這部分?jǐn)?shù)據(jù)并不是很大）。
啟動(dòng)
另一個(gè)有關(guān)性能的環(huán)節(jié)和上面所有的因素幾乎完全沒有關(guān)系，那就是啟動(dòng)速度。我在之前的演講中提到了GNOME的計(jì)算器，不過他們現(xiàn)在已經(jīng)修復(fù)了這個(gè)問題。好在類似的問題很多，比如Ubuntu的菜單也是，我每次都要數(shù)到5才能彈出菜單。對(duì)于Chrome的啟動(dòng)我寫過十分詳細(xì)的技術(shù)文檔，從基準(zhǔn)測試和適應(yīng)低配系統(tǒng)等兩個(gè)方面闡述?，F(xiàn)在我們來看看為什么這十分重要。
我相信一個(gè)應(yīng)用的啟動(dòng)速度確立了用戶對(duì)其性能的期待。事情總是這樣的：用戶認(rèn)為你很快總是要比你事實(shí)上快不快來的重要。當(dāng)你的啟動(dòng)速度和輕量級(jí)應(yīng)用一樣快時(shí)，用戶會(huì)覺得他們?cè)谑褂靡粋€(gè)輕量級(jí)應(yīng)用，盡管事實(shí)并非如此（事實(shí)上，任何一個(gè)可以呈現(xiàn)頁面的瀏覽器都是龐大的應(yīng)用，包括我們的Chrome）。比如說，即使到今天我還是習(xí)慣時(shí)不時(shí)的使用vi編輯器，因?yàn)閑macs啟動(dòng)實(shí)在太慢了。我甚至沒有意識(shí)到我在下意識(shí)的拒絕使用emacs。
當(dāng)然，快速的啟動(dòng)意味著在啟動(dòng)時(shí)做更少的工作，因此整個(gè)代碼都需要進(jìn)行仔細(xì)的工程。
結(jié)論
在Chrome工作三年，我從中學(xué)到的一大原則就是：如果你沒有考慮某個(gè)性能，那么這項(xiàng)性能必然會(huì)退步。這是軟件開發(fā)的一個(gè)自然現(xiàn)象，因?yàn)槲覀兛偸窃跒閼?yīng)用添加而非減少東西。因此，我們使用buildbots來為所有的性能測試創(chuàng)建圖表（該頁面巨大，當(dāng)心瀏覽器崩潰）。每個(gè)退步的性能項(xiàng)都會(huì)變紅，這事經(jīng)常發(fā)生，然后我們就要修改代碼。
總之一句話：基準(zhǔn)測試僅僅在你了解該測試的技術(shù)細(xì)節(jié)時(shí)才有他的用處。如果你并非一個(gè)瀏覽器開發(fā)者，那么身為一個(gè)“專業(yè)人士”，我要說的是，自己打開網(wǎng)頁嘗試一下才是判斷哪個(gè)瀏覽器最快的最佳方法。
原文：http://neugierig.org/software/chromium/notes/2010/05/fast.html
【51CTO.com譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處。】
【編輯推薦】
