一個慢騰騰的網(wǎng)站，可能會讓許多關(guān)鍵的訪客和用戶失去耐心，造成交易量降低、品牌形象變差，以及更高的“跳出率”。目前看來，無論網(wǎng)站是否提供在線交易的功能和服務(wù)，性能優(yōu)化都已經(jīng)不再是可選項，而是必選項。
那么，應(yīng)該如何更加科學(xué)地評價Web性能優(yōu)化技術(shù)及其背后的CDN廠商呢？
性能評價方法：“模擬測試” 和 “RUM”
在討論“性能評價”這個話題的時候，我們都會非常頻繁地說到這樣一個詞：模擬測試（Synthetic Measurements）。
盡管現(xiàn)在業(yè)界都在使用真實客戶監(jiān)測（RUM：Real User Monitor）的數(shù)據(jù)，來衡量真實的用戶體驗，但RUM并不是一個放之四海而皆準的一個標準。因為：
在某些場景下，我們無法得到真實用戶的數(shù)據(jù)，因此，“模擬測試”就成為了我們的另外一個選擇。
”模擬測試“怎么做？本文列舉一些方法，希望能夠幫助大家更好地分析、評價。
考慮到CDN已然是Web網(wǎng)站的標配，因此在如下案例方法中，都假設(shè)已使用CDN，而且都處于“上線前（Pre-Production）”的環(huán)境之下。
性能評測及優(yōu)化的5個步驟

步驟1：搭建環(huán)境
當對某一Web站點可能使用的多個CDN廠商進行評估時，每一個廠商都應(yīng)該提供一個不需要客戶進行任何改動的模擬環(huán)境。
并且，CDN廠商應(yīng)該提供“測試”域名，來盡可能真實地模擬生產(chǎn)環(huán)境的網(wǎng)站。
舉個例子：假設(shè)待評測網(wǎng)站域名是 www.customer.com，CDN廠商服務(wù)域名是 xxxx.com，那么廠商應(yīng)提供的臨時測試域名通常為：
www.customer.com.xxxx.com

步驟2：環(huán)境確認
臨時測試域名應(yīng)該是“完全”與生產(chǎn)用站點對應(yīng)匹配的。我們建議的檢查清單如下，大家可按此進行檢查：
對象數(shù)量一致，在測試域名下的對象數(shù)量，應(yīng)該和真實網(wǎng)站所包含的對象數(shù)量一致；
文件總大小一致，測試網(wǎng)站的字節(jié)數(shù)應(yīng)該和真實網(wǎng)站一致。當然，由于每一個廠商采用的壓縮方式不同，其字節(jié)數(shù)可以比真實網(wǎng)站“略小”；
緩存規(guī)則一致，所有CDN廠商使用的緩存規(guī)則應(yīng)該要一致，因為有一些廠商可以緩存動態(tài)請求（比如緩存html頁面的整體框架）。
如果某個廠商可以做到這一點但是其他廠商不行，那么這個測試的公允性就值得質(zhì)疑，因為那些采取更加激進的緩存策略的廠商就會獲得優(yōu)勢。所以在正式開始之前，我們必須對配置進行一次全面的核查。

步驟3：性能測試方案的設(shè)定
在測試環(huán)境妥善搭建之后，下一步就是要對真實的性能測試方案進行設(shè)定。建議在設(shè)置“正確”的測試方案之前，應(yīng)思考如下問題：
1.測試的類型是什么？
就像我們提及的，在對沒有處于真實生產(chǎn)階段的網(wǎng)站配置進行評估的時候，是沒有“真實用戶”的，沒有真實用戶，就沒有真實用戶數(shù)據(jù)。這時候，我們就需要采取綜合測試的方式來進行衡量。
綜合測試可以提供一個“清潔屋”式的測試環(huán)境，來方便我們對性能進行衡量。但是，即便是綜合測試，也是分許多種類的，如：骨干網(wǎng)絡(luò)性能測試、最后一公里測試、蜂窩網(wǎng)絡(luò)測試（也稱移動網(wǎng)絡(luò)測試）等等。
相對于骨干網(wǎng)絡(luò)性能測試，最后一公里測試可能更加能夠反映真實的用戶體驗情況；而如果網(wǎng)站或者公司擁有大量的移動端接入客戶，那么就一定要在移動網(wǎng)絡(luò)下進行性能測試。這也會引發(fā)關(guān)于不同供應(yīng)商對移動端進行加速的能力和技術(shù)的討論。
2.采用什么樣的性能測試平臺？
總體來說，推薦使用在你所處行業(yè)內(nèi)有一定業(yè)務(wù)經(jīng)驗和業(yè)績的第三方測試平臺。做一些簡單的調(diào)查，看看有哪些公司在你所處的行業(yè)內(nèi)發(fā)布過與性能有關(guān)的信息、指數(shù)或者文章。
不要使用某個廠商內(nèi)部的特定測試工具，否則測試的結(jié)果會帶有非常明顯的傾向性。一個好的模擬測試平臺應(yīng)該擁有一批穩(wěn)定的分布于全國/全球的測試節(jié)點，這些測試節(jié)點最好能和您業(yè)務(wù)重點區(qū)域相一致。
注意：這些測試節(jié)點應(yīng)該在瀏覽器上模擬真實用戶的種種行為。有些測試平臺使用仿真瀏覽器，而不是真實瀏覽器。仿真瀏覽器只能捕捉網(wǎng)絡(luò)時間，而真實的瀏覽器則可以獲取前端（或“渲染”）時間、瀏覽器緩存和并行鏈接等數(shù)據(jù)。
因此，如果有條件，還是要使用“真實瀏覽器”進行測試。
3.測試應(yīng)該在哪里進行？
測試地點應(yīng)該包括“跨域分發(fā)”（也就是說跨越洲際和國家）以及“域內(nèi)分發(fā)”兩種情況。在這里，需要再次強調(diào)的是，由于業(yè)務(wù)不同和所面對的用戶類型不同，這兩種測試都需要進行考慮。
如果是面向全球的業(yè)務(wù)，源站服務(wù)器位于北美，而需要向全球用戶進行分發(fā)，那么就應(yīng)該對美國和美國以外的遠距離地點進行性能測試，而不是只關(guān)注美國國內(nèi)的用戶體驗。
如果是僅僅面向國內(nèi)的業(yè)務(wù)，則也需要考慮不同運營商的問題，至少目前為止，電信、聯(lián)通之間的”墻“，還很牢固。
4.測試對象應(yīng)該包括什么？
典型的網(wǎng)站交互行為會包含對多個頁面的訪問和使用，這是用戶在網(wǎng)站上完成一個任務(wù)或行為的通常模式，這也是我們需要進行測試的對象，這樣做是出于兩個目的：
首先，這能夠模擬一個最終用戶可能在真實情景下所體會到的性能；
其次，這能夠幫助您了解一個優(yōu)化解決方案可以給網(wǎng)站帶來怎樣的收益。
可能有個優(yōu)化方案A可以給某一種特定類型的頁面帶來好處，而另一種優(yōu)化方案B可能會給其他類型頁面帶來改善，這取決于站點的結(jié)構(gòu)、數(shù)據(jù)或者對象的特性。
如果僅局限于對單個對象進行測試、并以此判斷緩存的收益，或者僅僅關(guān)注“基礎(chǔ)”的html頁面、而不對其他種種特性復(fù)雜的對象、微小的API交互行為進行測試，這樣很可能導(dǎo)致以偏概全，也無法觀測到解決方案的真實效果，以及是否真的適用。
5.測試應(yīng)該跑多久？
測試時間應(yīng)該包括高峰時段和非高峰時段。一般來說，3到5天的數(shù)據(jù)總和是比較具有參考價值的。如果測試的時間過短，比如說只有幾個小時，那么由于網(wǎng)絡(luò)狀況的不穩(wěn)定和用戶數(shù)量的變化沒有得到真實反映，測試得到的數(shù)據(jù)也很難是真實的。
6.測試的頻率應(yīng)該是怎樣？
高頻率的測試能夠反映流量高峰時的場景，在這種情況下，緩存中的內(nèi)容總是新的，且可以命中；而低頻率的測試則反映出非流量高峰時的情況，此時，內(nèi)容可能是從你的源站一次一次抓取回來的。
一般情況下，我們建議每30分鐘發(fā)起一次測試，這樣可以反映出一個比較真實的流量模擬。
最后還要注意，測試期間源站帶寬的用量可能有所上升，請?zhí)崆白龊脺蕚洹?/p>

步驟4：性能指標的評估
以下為一個測試結(jié)果的示例，其中包含了各種評估性能測試結(jié)果的參數(shù)，供大家參考。
其中一個非常有用的參數(shù)，就是展示一個完整用戶交互過程的一系列頁面響應(yīng)時間的加總數(shù)值。同樣，在使用了前端優(yōu)化技術(shù)的場景下，W3C專有的完整 DOM數(shù)值也非常有用。
直方圖：測試結(jié)果直方圖可以幫助你了解在優(yōu)化之前和優(yōu)化之后的測試結(jié)果分布。

我們來看上面兩個圖表。
從第一張圖，兩個CDN廠商的測試結(jié)果，很難看出來哪個更好；但是，從第二張直方圖上，我們可以清楚地看到，藍色這家CDN廠商的效果更好，因為：
加載時間小于7秒的所有用戶（包括6秒、6.5秒和7秒）的占比總和，藍色比橙色多了15%。
這種圖表同樣也可以幫助我們排除測試中的異常值。
深入分析：除了總體測試參數(shù)之外，我們還應(yīng)該在如下方面多花一些時間：
1.以測試地點為維度對結(jié)果進行細分
如果單純只看“表現(xiàn)好”和“表現(xiàn)不好”這兩個簡單的參數(shù)，那測試結(jié)果可能會被曲解。所以按地點對性能測試結(jié)果進行分析，對于業(yè)務(wù)來說就非常重要。
2.以交互步驟為維度對結(jié)果進行細分
某些性能優(yōu)化解決方案可能不會對交互行為的某一個或者某幾個步驟起作用。
比如，一個交互動作可能包括上傳一個文件。但是并不是所有的CDN供應(yīng)商都有能夠幫助上傳提速的能力。
按照不同的交互步驟來觀察相應(yīng)的時間，可以幫助我們選擇更加符合自己業(yè)務(wù)需求的CDN廠商。
3.可用性
大家不要被自己誤導(dǎo)了！有時，測試結(jié)果顯示的可用性下降很有可能是由于腳本錯誤，而不是CDN廠商的問題。
根據(jù)經(jīng)驗，性能指標僅應(yīng)該從測試的健康可用性（90%+）這個角度進行衡量，另外10%，可能是因為測試平臺自身的問題。
4.帶寬負載
CDN廠商應(yīng)該能夠提供全面的點擊及帶寬負載數(shù)據(jù)，只有這樣才能對節(jié)省下來的費用進行測算。這也可以幫助客戶在選定某個廠商之后，對其源站基礎(chǔ)設(shè)施的投資力度進行規(guī)劃。

步驟5：其他需要考慮的因素
除了解決方案的性能之外，還應(yīng)該從如下一些維度對每個CDN廠商進行考評：
1.CDN節(jié)點覆蓋
許多廠商都宣稱自己的節(jié)點能夠覆蓋全國或全球，但是他們可能在某一個區(qū)域的覆蓋率較低，而這個區(qū)域恰恰是你業(yè)務(wù)的重點。所以必須要對廠商的網(wǎng)絡(luò)規(guī)模進行調(diào)查。
2.業(yè)務(wù)吻合程度
一個良好的、專業(yè)的廠商的解決方案路線圖，應(yīng)該是目光長遠的。隨著業(yè)務(wù)的擴展，廠商必須在那些對于客戶業(yè)務(wù)大有裨益的領(lǐng)域擴展其服務(wù)。
3.客戶解決方案和支持能力
許多公司都選擇和那些有專門服務(wù)團隊的廠商合作，旨在獲取其平臺上的定制化支持服務(wù)：
有些公司希望廠商提供7x24的客戶服務(wù)支持；有些公司則希望廠商提供大量API，以充分發(fā)揮自己團隊的技術(shù)能力，更靈活地處理和解決問題。
哪一種方式更合適您？這往往取決于您自身業(yè)務(wù)特點和您自有技術(shù)團隊的支持能力。

最后
一個好的CDN廠商，應(yīng)遵循這些建議，來幫助其客戶評價各種優(yōu)化解決方案的真實性能，特別是在市場上的同類產(chǎn)品比較多的情況下。
在上述實踐方式的指引下，相信用戶會做出適合自己的選擇。