瀏覽器請求響應慢,該從哪些方面分析

查看網絡面板

clipboard.png

響應比較慢能夠從兩個層次去考慮html

  1. 鏈接初始化階段耗時
  2. 請求和響應耗時

查看關鍵指標:前端

  • 排隊web

    • 達到瀏覽器最大併發數量限制
    • 有更高優先級的請求插隊,低優先級的任務被延後
    • 系統內存空間不足,瀏覽器使用磁盤空間
  • 擁堵 緣由和排隊中相似
  • DNS查詢 花在DNS查詢上的時間
  • Proxy negotiation. 代理協商
  • Request sent. 請求被髮送
  • Request to ServiceWorker. 請求被髮送到ServiceWork
  • Waiting (TTFB). 等待收到響應的第一個字節
  • Content Download. 內容下載
  • Receiving Push. 瀏覽器經過HTTP/2 Server Push接受數據
  • Reading Push. 瀏覽器讀取以前收到的數據

常見問題現象及解決方法

出現長時間的排隊或者擁堵

clipboard.png

緣由 瀏覽器對同一域名最大的TCP連接數有限制,超過限制的請求會被排隊。ajax

參見瀏覽器同域名請求的最大併發數限制sql

爲何會達到最大併發數?chrome

  1. 一次性獲取的資源數量太多
  2. 資源體積太大,不少都在下載中
  3. 有些請求響應太慢或者無響應。例如1分鐘以內,每隔10秒鐘發送一個無響應的請求,隨着可用的請求慢慢被佔滿,正常的請求排隊數量會愈來愈多。

解決方法後端

問題1和問題2比較容易發現,也比較好處理。主要從兩個角度解決瀏覽器

  1. 減小請求數量。能夠移除沒必要要的請求,或者將多個請求合併成1個。例如雪碧圖
  2. 使用域名分片。例如使用不一樣的域名指向相同的資源,從而突破單域名的限制。例如img1.tt.cc/1.jpg和img2.tt.cc/1.jpg
  3. 前端給每一個ajax請求設置超時 防止過多的無響應請求佔據着鏈接資源,能夠在超時以後釋放鏈接。有些ajax庫,例如jQuery的ajax, 默認是沒有設置超時時長的,當你在使用這些庫時,最好明確的設置
  4. 後端設置請求處理超時 後端接口應當設置最大超時時長

長時間的TTFB

clipboard.png

出現這種問題要從兩個方面排查網絡

  1. 客戶端到服務端之間的網絡通訊比較慢
  2. 服務端的響應比較慢,多是服務端壓力太大,到達帶寬上線,內存溢出,高CPU, IOwait高, Recv-Q高,或者sql查詢慢等各類緣由。

注意:對於同一個源的請求,若是有些請求很快,有些請求很慢。那麼問題通常是服務端的問題。由於若是是出現網絡通訊比較慢,那麼則全部的請求都會變慢。併發

解決方案

知道問題的真實緣由,其實問題也就解決了一半了。

參考

相關文章
相關標籤/搜索