Fiddler Timeline 如圖右邊區域，主要用法是直觀的顯示頁面各個元素的加載時間和順序，其中fiddler的Timeline相比Chrome 的developer tools更為強大的地方是可以直觀的顯示tcp網絡連接與斷開情況。
每個網絡請求都會經歷域名解析、建立連接、發送請求、接受數據等階段。把多個請求以時間作為 X 軸，用圖表的形式展現出來，就形成了瀑布圖。在 Fiddler 中，只要在左側選中一些請求，右側選擇“Timeline”標簽，就可以看到這些請求的瀑布圖，如下（點擊查看大圖）：
看到這張圖，你是否可以回答這些問題：
a.圖標的 Y 軸上顯示的是簡化后的 URL。為什么有些是綠色的，有些是黑色的？
b.為什么第一個請求用陰影線來表示，其它請求卻都是實心的？
c.請求條的不同顏色分別代表什么？
d.每個請求中的黑色豎線表示什么？
e.請求后面的圖標（如閃電和軟盤）代表了什么？
f.每個請求前面兩個小圓圈是什么，為什么有的是紅色，有的是綠色？
如果其中一個或者多個你不知道答案也沒關系，下面將一一揭曉。
1、綠色的請求表示這是一個“有條件的請求”。HTTP 協議定義了 5 個條件請求頭部，最常見的兩個是“If-Modified-Since”和“If-None-Match”。服務器根據這兩個頭部來驗證本地緩存是否過期，如果過期則正常返回資源的最新版本；否則僅返回 304 Not Modified，瀏覽器繼續使用本地緩存。包含條件請求頭部的請求用綠色顯示，否則用黑色。
2、有陰影線的請求是緩沖模式下的請求，實心的是流模式下的請求。Fiddler 提供了緩沖（Buffering）和流（Streaming）兩種抓包模式：緩沖模式下，Fiddler 會在響應完成時才將數據返回給應用程序（通常是瀏覽器），這種模式下可以控制響應，方便地修改響應內容；流模式下，Fiddler 會實時返回響應數據給瀏覽器，但沒辦法控制響應。一般使用流模式，瀑布圖會更真實一些。這兩種模式可以通過 Fiddler 的工具欄選擇。特別的，通過 Fiddler 的“AutoResponder”功能返回的響應，只能是緩沖模式。
開啟流模式：流模式比緩沖模式在客戶端響應稍快一些，因為數據包不會在fiddler中停留，而是直接同步的代理給瀏覽器（fiddler的工作模式就是本地代理），所以如果不需要Fiddler的“AutoResponse 和 Filters”功能的話，一般建議使用Stream模式。
3、請求條的不同顏色對應着不同元素類型的響應，根據響應頭的 MIME Type 來歸類。如淺綠色表示圖片類型的響應；深綠色是 JavaScript；紫色是 CSS；其它都是藍色。
4、Timeline中的黑色豎線，表示的是瀏覽器收到服務端響應的第一個字節這一時刻。這個時間受 DNS 解析、建立連接、發送請求、等待服務端響應等步驟的影響，一般用來觀察服務器返回給瀏覽器的數據傳輸效率。
5、請求條后面的圖標表示響應的某些特征。如軟盤圖標表示這個響應正文從本地獲得，也就是說服務端返回了 304；閃電表示這是 Fiddler 的“AutoResponder”的響應；向下的箭頭表示響應是 302，需要重定向；紅色感嘆號說明這個請求有錯誤發生（狀態碼是 4XX 或 5XX）。
特別的，如果請求條后面有一個紅色的X，說明服務端響應完這個請求之后，斷開了連接。出現這種情況一般有兩種可能：HTTP/1.0 的響應中沒有 Connection: Keep-Alive；或者是 HTTP/1.1 的響應中包含了 Connection: close。使用持久連接可以省去建立連接的開銷，也可以減小 TCP 慢啟動和其它擁塞控制機制帶來的影響，總之是好處多多。
6、請求前面的紅色圓圈表示這個連接是新建的，綠色表示是復用的。上面的圓圈表示的是瀏覽器到 Fiddler 的連接，下面的圓圈是 Fiddler 到服務端的連接。
現在，再看到 Fiddler 的瀑布圖就一目了然了吧。最后再來兩張瀑布圖自己練習下：
根據這些小細節，前端開發人員可以更容易的觀察頁面元素加載情況。