當Web訪問效能出現問題，如何深探？

標籤：資源載入   用戶端   採集   感受   http請求   技術分享   角度   nbsp   問題   

對營運或開發工程師來說，遇到訪問效能問題時，最先需要定位的是問題出現在哪個環節，是網路的問題，服務端的問題，還是用戶端的問題？

往往技術人員喜歡把精力放在保障後端服務的可用性方面，而對前端介面是否能正常裝載，是否能完整渲染不是太關心。但從業務的角度來說，介面承載的才是最終的業務，業務是通過人機互動來實現的。

日常我們遇到哪些情境需要定位訪問效能瓶頸？

·不同地區訪問同一應用速度的差異性較大時

·不同時段訪問同一應用速度的差異性較大時

·低版本瀏覽器導致介面載入速度慢或失敗時

·不同的作業系統（特別是手機）導致介面載入速度慢或失敗時

·外鏈資源或第三方服務拖慢介面載入速度時

 

還有更多情境需要定位。我們是否有簡單的辦法來定位是網路的問題、服務端的問題還是用戶端的問題？答案是肯定的。現代的瀏覽器提供給我們一些便利的條件可以擷取從請求開始到頁面渲染完成各個環節的時間，注意這裡說的必須是現代瀏覽器，他們有個共同的特點，即遵循W3C的TimingAPI。

 

之前與大家交流過《監控真實的使用者體驗，從一行代碼開始》。通過一行代碼來實現資料擷取，Web實現訪問效能定位就相對簡單，請看。

 

讓我們來看下如何解讀這些資料。

從使用者操作角度來衡量使用者體驗

首先是操作名稱，比如“開啟首頁”，這是一個重新導向的操作，對應的URL是http://

這裡"開啟首頁"的操作是如何來呢？在這裡先賣個關子下回再聊，這就是優雲Web與其他任何產品不一樣的地方，其他產品往往是給你一個URL地址，內容是什麼，上下文操作是什麼需要你自己去猜，非技術猿類無法理解。

·聚焦關鍵度量指標

oApdex

o平均回應時間

o平均使用者可操作時間

o吞吐率

其中平均回應時間可以分解為

o用戶端時間

o網路時間

o服務端時間

 

在這個例子中，我們發現用戶端時間佔了15秒之多，而網路和服務端占的時間非常少，兩者僅1秒不到。說明頁面在前端耗費了大量時間來載入和渲染。出現這種情況的時候，使用者往往以為服務端很慢，其實不然，據我們瞭解，70%的訪問效能問題出在前端上，這個與我們的認知大相徑庭。因此這個鍋該誰來背？大機率來說，70%的鍋應該是開發人員來背，營運趕緊拿資料砸過去吧。

·對關鍵計量進行深度分析

o回應時間與運算元趨勢的關聯關係：分析兩者是否有正相關關係

o回應時間精細化分析：平均值、中位元、最慢的5%

o回應時間按滿意度分布：哪些操作滿意、哪些可以容忍、哪些不滿意

·抽樣調查

我們會對不滿意的使用者進行抽樣，通過抽樣我們可以看出哪些地區、哪些瀏覽器的使用者會比較容易出現訪問效能問題，具體還可以細化到頁面的資源載入時間。這些資料有什麼用呢？可以知道哪些頁面資源可以進一步壓縮最佳化，減少http請求數，可以讓我們來檢驗CDN是否真正有效，或沒有啟用CDN的應用可以考慮CDN加速等等。

 

以上是個人關於訪問效能體驗的一些心得，還是建議你親自來感受它的不一樣。

當Web訪問效能出現問題，如何深探？