查看網絡面板
響應比較慢能夠從兩個層次去考慮html
- 鏈接初始化階段耗時
- 請求和響應耗時
查看關鍵指標:前端
-
排隊web
- 達到瀏覽器最大併發數量限制
- 有更高優先級的請求插隊,低優先級的任務被延後
- 系統內存空間不足,瀏覽器使用磁盤空間
- 擁堵 緣由和排隊中相似
- DNS查詢 花在DNS查詢上的時間
- Proxy negotiation. 代理協商
- Request sent. 請求被髮送
- Request to ServiceWorker. 請求被髮送到ServiceWork
- Waiting (TTFB). 等待收到響應的第一個字節
- Content Download. 內容下載
- Receiving Push. 瀏覽器經過HTTP/2 Server Push接受數據
- Reading Push. 瀏覽器讀取以前收到的數據
常見問題現象及解決方法
出現長時間的排隊或者擁堵
緣由 瀏覽器對同一域名最大的TCP連接數有限制,超過限制的請求會被排隊。ajax
參見瀏覽器同域名請求的最大併發數限制。sql
爲何會達到最大併發數?
chrome
- 一次性獲取的資源數量太多
- 資源體積太大,不少都在下載中
- 有些請求響應太慢或者無響應。例如1分鐘以內,每隔10秒鐘發送一個無響應的請求,隨着可用的請求慢慢被佔滿,正常的請求排隊數量會愈來愈多。
解決方法後端
問題1和問題2比較容易發現,也比較好處理。主要從兩個角度解決瀏覽器
- 減小請求數量。能夠移除沒必要要的請求,或者將多個請求合併成1個。例如雪碧圖
- 使用域名分片。例如使用不一樣的域名指向相同的資源,從而突破單域名的限制。例如img1.tt.cc/1.jpg和img2.tt.cc/1.jpg
- 前端給每一個ajax請求設置超時 防止過多的無響應請求佔據着鏈接資源,能夠在超時以後釋放鏈接。有些ajax庫,例如jQuery的ajax, 默認是沒有設置超時時長的,當你在使用這些庫時,最好明確的設置
- 後端設置請求處理超時 後端接口應當設置最大超時時長
長時間的TTFB
出現這種問題要從兩個方面排查網絡
- 客戶端到服務端之間的網絡通訊比較慢
- 服務端的響應比較慢,多是服務端壓力太大,到達帶寬上線,內存溢出,高CPU, IOwait高, Recv-Q高,或者sql查詢慢等各類緣由。
注意:對於同一個源的請求,若是有些請求很快,有些請求很慢。那麼問題通常是服務端的問題。由於若是是出現網絡通訊比較慢,那麼則全部的請求都會變慢。併發
解決方案
知道問題的真實緣由,其實問題也就解決了一半了。
參考