對(duì)運(yùn)維或開發(fā)工程師來說，遇到訪問性能問題時(shí)，最先需要定位的問題是出現(xiàn)在哪個(gè)環(huán)節(jié)，是網(wǎng)絡(luò)的問題，服務(wù)端的問題，還是客戶端的問題？

往往技術(shù)人員喜歡把精力放在保障后端服務(wù)的可用性方面，而對(duì)前端界面是否能正常裝載，是否能完整渲染不是太關(guān)心。但從業(yè)務(wù)的角度來說，界面承載的才是最終的業(yè)務(wù)，業(yè)務(wù)是通過人機(jī)交互來實(shí)現(xiàn)的。

日常我們遇到哪些場(chǎng)景需要定位訪問性能瓶頸？

不同地域訪問同一應(yīng)用速度的差異性較大時(shí)

不同時(shí)段訪問同一應(yīng)用速度的差異性較大時(shí)

低版本瀏覽器導(dǎo)致界面加載速度慢或失敗時(shí)

不同的操作系統(tǒng)（特別是手機(jī)）導(dǎo)致界面加載速度慢或失敗時(shí)

外鏈資源或第三方服務(wù)拖慢界面加載速度時(shí)

還有更多場(chǎng)景需要定位。我們是否有簡(jiǎn)單的辦法來定位是網(wǎng)絡(luò)的問題、服務(wù)端的問題還是客戶端的問題？答案是肯定的。現(xiàn)代的瀏覽器提供給我們一些便利的條件可以獲取從請(qǐng)求開始到頁面渲染完成各個(gè)環(huán)節(jié)的時(shí)間，注意這里說的必須是現(xiàn)代瀏覽器，他們有個(gè)共同的特點(diǎn)，即遵循W3C的Timing API。

之前與大家交流過《監(jiān)控真實(shí)的用戶體驗(yàn)，從一行代碼開始》點(diǎn)擊參看此文。通過一行代碼來實(shí)現(xiàn)數(shù)據(jù)采集，優(yōu)云Web實(shí)現(xiàn)訪問性能定位就相對(duì)簡(jiǎn)單，請(qǐng)看下圖。

讓我們來看下如何解讀這些數(shù)據(jù)。

從用戶操作角度來衡量用戶體驗(yàn)

首先是操作名稱，比如“打開首頁”，這是一個(gè)重定向的操作，對(duì)應(yīng)的URL是http://這里"打開首頁"的操作是如何來呢？在這里先賣個(gè)關(guān)子下回再聊，這就是優(yōu)云Web與其他任何產(chǎn)品不一樣的地方，其他產(chǎn)品往往是給你一個(gè)URL地址，內(nèi)容是什么，上下文操作是什么需要你自己去猜，非技術(shù)猿類無法理解。

聚焦關(guān)鍵度量指標(biāo)

Apdex

平均響應(yīng)時(shí)間

平均用戶可操作時(shí)間

吞吐率

其中平均響應(yīng)時(shí)間可以分解為

客戶端時(shí)間

網(wǎng)絡(luò)時(shí)間

服務(wù)端時(shí)間

在這個(gè)例子中，我們發(fā)現(xiàn)客戶端時(shí)間占了15秒之多，而網(wǎng)絡(luò)和服務(wù)端占的時(shí)間非常少，兩者僅1秒不到。說明頁面在前端耗費(fèi)了大量時(shí)間來加載和渲染。出現(xiàn)這種情況的時(shí)候，用戶往往以為服務(wù)端很慢，其實(shí)不然，據(jù)我們了解，70%的訪問性能問題出在前端上，這個(gè)與我們的認(rèn)知大相徑庭。因此這個(gè)鍋該誰來背？大概率來說，70%的鍋應(yīng)該是開發(fā)人員來背，運(yùn)維趕緊拿數(shù)據(jù)砸過去吧。

對(duì)關(guān)鍵指標(biāo)進(jìn)行深度分析

響應(yīng)時(shí)間與操作數(shù)趨勢(shì)的關(guān)聯(lián)關(guān)系：分析兩者是否有正相關(guān)關(guān)系

響應(yīng)時(shí)間精細(xì)化分析：平均值、中位數(shù)、最慢的5%

響應(yīng)時(shí)間按滿意度分布：哪些操作滿意、哪些可以容忍、哪些不滿意

抽樣調(diào)查

我們會(huì)對(duì)不滿意的用戶進(jìn)行抽樣，通過抽樣我們可以看出哪些地域、哪些瀏覽器的用戶會(huì)比較容易出現(xiàn)訪問性能問題，具體還可以細(xì)化到頁面的資源加載時(shí)間。這些數(shù)據(jù)有什么用呢？可以知道哪些頁面資源可以進(jìn)一步壓縮優(yōu)化，減少http請(qǐng)求數(shù)，可以讓我們來檢驗(yàn)CDN是否真正有效，或沒有啟用CDN的應(yīng)用可以考慮CDN加速等等。

以上是個(gè)人關(guān)于訪問性能體驗(yàn)的一些心得，優(yōu)云Web體驗(yàn)還是建議你親自來感受它的不一樣。