1、後端的問題

看請求瀑布圖，如果第一個請求特別長、特別長，明顯比其他請求放到一起不和諧。一般網頁第一個請求是動態請求的概率比較大，如果這個請求特別耗時，那肯定不是前端的責任，html都沒載入完呢，你怎麼就能說是前端的問題呢。作為一個後端RD，優化程式碼、優化資料庫、優化一切可以優化的東西。

2、請求數太多

數一下瀑布圖總共有多少行，on load之前如果有幾百行，那麼請求就太多了。一下子載入那麼多資源真的好麼？css，js該合併的合併，圖示該精靈的精靈，有些不重要的東西不用放到on  load之前載入，放到後面也一樣嘛。

3、老鼠屎

看到圖中的這個請求沒？再看看其他請求，這個請求比其他請求的時間大出一個數量級。這種情況一般是因為某一個資源太慢了，它就是一顆老鼠屎，壞掉了整鍋湯，導致網頁整體變慢。資源慢的原因，概率比較大的幾個可能是：（a）資源在第三方站點上，他們很慢；（b）這個資源太大了；（c）這個資源使用的域名有問題。

4、網路問題

仔細看一下一個單獨的HTTP請求，他們會分為好幾段，分別是域名解析、建立連線、傳送請求、等待響應和接收資料幾個階段。理論上域名解析和建立連線應該佔用的時間很小才對，主要的時間應該用在後面幾個階段上。上圖中，淺灰色和灰色分別代表域名解析和建立連線，可以看出這兩個請求中花費在網路層上的時間太長了，超過總時間的一半還要多。網路層時間過長除了可能和底層網路有關之外，還可能和站點的服務端效能有關（後端RD的事情哦）。當然，如果這種情況發生在向第三方站點發送的請求上（實際上也經常發生），可以建議取消或者更換某些站點功能從而避免這樣的請求了。

5、接收資料時間過長

HTTP請求的大部分時間應該花在後面幾個階段，比如等待響應和接收資料。但是，如果接收資料的時間太長了，長到數百毫秒甚至以秒計算的時候，那也是有問題的。這種情況一般是因為下載的內容太重了，例如大圖片、大指令碼等。這類問題可以使用GZIP壓縮、圖片壓縮或者JS/CSS的minify等手段來解決。

6、js阻塞請求

兩個連續的請求之間出現了一個很大的空隙，為啥會出現這個空隙呢？可能js效能有問題，解析執行js花了很長時間，導致這段時間的資源載入都被阻塞住了。

7、如果以上都沒有

可以翻看每個HTTP請求，仔細研究每個請求頭響應頭，看看是不是沒有設定快取啦，圖片優化的不夠好啦之類的。

轉載於http://blog.csdn.net/mysouling/article/details/51210297