前面我寫了一篇 快速web app的關(guān)鍵 是使用Ajax、優(yōu)化Javascript和更好的緩存。

• 使用Ajax 可以減少網(wǎng)絡(luò)流量到只有少量的JSON請(qǐng)求。
• 優(yōu)化Javascript （異步下載腳本、分組DOM修改、對(duì)UI進(jìn)程作出讓步等）允許請(qǐng)求可以并行然后快速渲染。
• 更好的緩存 意味著web app的大部分資源是存儲(chǔ)在本地，然后并不會(huì)再有任何http請(qǐng)求了。

理解每種技術(shù)在哪里發(fā)揮作用很重要。使用Ajax，例如，不會(huì)讓頁(yè)面初始化加載更快（而且常常會(huì)不小心讓它更慢），但是后面的“頁(yè)面”（用戶操作） 會(huì)更爽。另一方面，優(yōu)化Javascript，會(huì)讓初始頁(yè)面和后面的頁(yè)面都更快，更好的緩存則位于中間：第一次訪問(wèn)不快，但后面的訪問(wèn)會(huì)更快。同時(shí)，即便 在用戶關(guān)掉瀏覽器之后再一次返回你的網(wǎng)站時(shí)初始化頁(yè)面也會(huì)更快——這樣性能優(yōu)勢(shì)要?jiǎng)龠^(guò)瀏覽器會(huì)話（sessions）。

?

這些網(wǎng)站性能優(yōu)化并不是互斥的——你應(yīng)該都使用！但我（或者你也）想知道哪一個(gè)才有最大的效果呢？所以我進(jìn)行了一次測(cè)試來(lái)測(cè)量這些不同的因素。我想要看看它們?cè)趯?shí)際網(wǎng)站中的效果，所以我使用了 WebPagetest ，這里我可以很方便的在Alexa排名前1000的網(wǎng)站中做一些測(cè)試。由于并沒(méi)有辦法讓一個(gè)網(wǎng)站直接“Ajax化”，所以我決定專注與網(wǎng)絡(luò)使用的時(shí)間。最后，我做了下面4項(xiàng)測(cè)試：

• 基準(zhǔn) ——用IE9和一個(gè)模擬的DSL連接速度(1.5Mbps下載、384Kbps上傳，50ms RTT)來(lái)運(yùn)行Alexa排名前1000的網(wǎng)站。每個(gè)URL加載3次取中間值（基于頁(yè)面加載時(shí)間）作為最終結(jié)果。只看“第一次”（無(wú)緩存）的頁(yè)面加載。
• 快速網(wǎng)絡(luò) ——除了使用一個(gè)模擬的FIOS網(wǎng)絡(luò)（20Mbps下載，5Mbps上行，4ms RTT）以外和基準(zhǔn)測(cè)試一致。
• 無(wú)JavaScript ——同基準(zhǔn)測(cè)試一樣，只是這次在 RESTful API 上使用了“noscript”選項(xiàng)。效果和在瀏覽器中禁用JavaScript一致。這并不是一個(gè)對(duì)“優(yōu)化JavaScript”的完美替代，因?yàn)樗械?JavaScript產(chǎn)生的HTTP請(qǐng)求都被跳過(guò)了，另一方面，所有在noscript標(biāo)簽里面的資源——如果有的話——又被加了進(jìn)來(lái)。我們后面會(huì)對(duì)比 HTTP請(qǐng)求數(shù)。
• 緩存模式 ——除了在“重復(fù)模式”下瀏覽以外其它和基準(zhǔn)測(cè)試一致。這個(gè)測(cè)試用來(lái)看在今天給到緩存頭（caching headers）的優(yōu)勢(shì)的最佳情況。然而并不是任何東西都可以緩存的，所以還是會(huì)有些網(wǎng)絡(luò)請(qǐng)求發(fā)生。

哪個(gè)測(cè)試會(huì)產(chǎn)生最快的頁(yè)面加載時(shí)間呢？思考一下然后寫下你的猜測(cè)。我在開(kāi)始測(cè)試前也猜測(cè)了一下，然后結(jié)果是我猜錯(cuò)了。。。

?

結(jié)果：

這個(gè)表顯示了中間值和每個(gè)測(cè)試的window.onload時(shí)間的第95個(gè)百分位?；鶞?zhǔn)測(cè)試的中間加載時(shí)間是7.65秒(95百分位是24.88)。每個(gè)優(yōu)化都非常明顯的讓頁(yè)面加載快了。下面是它們的對(duì)比：

• 緩存模式是測(cè)試中最快的，3.46秒(95百分位是12.00).
• 快速網(wǎng)絡(luò)是第二快的，4.13秒 (95百分位是13.28).
• 無(wú)JavaScript第三，4.74秒(95百分位是15.76).

我很驚訝無(wú)JavaScript竟然不是最快的。禁用JavaScript移除在下載資源時(shí)可能發(fā)生的阻塞行為。盡管IE9中腳本和其它大部分資源一起并行下載(請(qǐng)看 Browserscope )，它們也會(huì)引起阻塞字體文件或者其它邊界情況。更重要地，禁用JavaScript減少了請(qǐng)求數(shù)量——從基準(zhǔn)測(cè)試的90個(gè)降到59個(gè)，總請(qǐng)求大小也從927kb降到577kb。

快速網(wǎng)絡(luò)的提升也超出了我的期待。請(qǐng)求的數(shù)量和帶寬大小和基準(zhǔn)測(cè)試一致，但是加載時(shí)間的中間值竟快了46%，從7.65秒降到4.13秒。這表明網(wǎng)絡(luò)環(huán)境（連接速度和延遲）會(huì)有明顯的影響。(難怪創(chuàng)建一個(gè)快速的移動(dòng)網(wǎng)絡(luò)體驗(yàn)很難。）

緩存贏得測(cè)試的關(guān)鍵是，請(qǐng)求數(shù)從90降到了32。有58個(gè)請(qǐng)求是從本地緩存讀取的——而沒(méi)有任何HTTP流量。HTTP Archive的關(guān)于 Alexa 前1000名網(wǎng)站的 max-age 表 顯示，59%的請(qǐng)求被配置了緩存(max-age > 0)。它們中的大部分有比較短的不超過(guò)10分鐘的緩存時(shí)間，但是由于“重復(fù)瀏覽”是立刻進(jìn)行的，所以它們是從緩存中讀取的——所以它確實(shí)是一個(gè)最佳案例 了。90的59%是53。另外的5個(gè)請(qǐng)求貌似由于啟發(fā)式緩存（ heuristic caching ）而被從緩存中丟掉了。

盡管結(jié)果很意外，但我很高興緩存被證明是如此有效的讓網(wǎng)站更快的因素（或許也是最有效的因素）。我最近開(kāi)始關(guān)注緩存。這是一個(gè)重要的開(kāi)端——提高認(rèn)識(shí)我們面前的謊言的機(jī)會(huì)。

?

僅僅使用今天的緩存頭部，資源請(qǐng)求數(shù)量就減少了64%。但也只是“重復(fù)瀏覽”是立即進(jìn)行的。如果我們等待了一天，19%的緩存就過(guò)期了，又會(huì)產(chǎn)生 17個(gè)新的If-Modified-Since請(qǐng)求。貌似那5個(gè)啟發(fā)式緩存也會(huì)產(chǎn)生新的請(qǐng)求。所以我們需要換個(gè)方向讓更多的資源緩存更長(zhǎng)的時(shí)間。然后，要 得到快速加載資源的優(yōu)勢(shì)的話我們需要調(diào)查預(yù)讀資源——甚至在瀏覽器請(qǐng)求它們之前——的方法。

PS：表示不太懂文中的“第95個(gè)百分點(diǎn)”（95th percentile），求高人解答~~

?

文章譯自： Cache is King
中文原文： 緩存為王
請(qǐng)尊重版權(quán)，轉(zhuǎn)載請(qǐng)注明來(lái)源，多謝~~