傳統的網站性能監測通常有以下幾種方式：
1、借助傳統的開發者工具查看網絡請求，例如瀏覽器的F12工具、Fiddler、Charles等等。基本方式是通過追蹤HTTP請求與響應的時間，以圖形的方式列出所有資源的下載情況。這種方式依賴於人為操作，難以實現批量測試與統計。
2、使用侵入式的JavaScript代碼檢測DOM事件的發生時間。例如DOMContentLoaded和document.onreadystatechange等等。這種方式會在頁面中引入額外的代碼，加重了開發者與測試人員的負擔，還有可能因為檢測代碼本身的潛在問題影響頁面的性能。
3、使用第三方的服務與工具，例如WebPagetest、Pingdom等等，這些服務通常能夠實現在不同瀏覽器和不同地域進行測試，並且為用戶提供一些優化建議。但某些服務需要排隊等待，並且多次測試結果之間往往區別較大。第一條方式的問題也同樣存在。
Network
請求等待時間（TTFB）:waiting時間就是處理數據的時間 請求到達服務器 服務器根據請求內容去執行程序，引入文件載入類什么的都在這段時間內執行得出結果后反饋回來。框架復雜度問題，越復雜的框架 請求時間越長
TTFB (Time To First Byte)，是最初的網絡請求被發起到從服務器接收到第一個字節這段時間，它包含了 TCP連接時間，發送HTTP請求時間和獲得響應消息第一個字節的時間。 注意：網頁重定向越多，TTFB越高，所以要減少重定向
TTFB優化的方法有：
1.減少DNS查詢
2.使用CDN
3.提早Flush
4.添加周期頭
TimeLine
Timeline更多的是用在性能優化方面，它的作用就是記錄與分析應用程序運行過程中所產生的活動
渲染流程如下
* JavaScript。一般來說，我們會使用JavaScript來實現一些視覺變化的效果。比如用jQuery的animate函數做一個動畫、對一個數據集進行排序、或者往頁面里添加一些DOM元素等。當然，除了JavaScript，還有其他一些常用方法也可以實現視覺變化效果，比如：CSS Animations, Transitions和Web Animation API。
* 計算樣式。這個過程是根據CSS選擇器，比如.headline或.nav > .nav_item，對每個DOM元素匹配對應的CSS樣式。這一步結束之后，就確定了每個DOM元素上該應用什么CSS樣式規則。
* 布局。上一步確定了每個DOM元素的樣式規則，這一步就是具體計算每個DOM元素最終在屏幕上顯示的大小和位置。web頁面中元素的布局是相對的，因此一個元素的布局發生變化，會聯動地引發其他元素的布局發生變化。比如，元素的寬度的變化會影響其子元素的寬度，其子元素寬度的變化也會繼續對其孫子元素產生影響。因此對於瀏覽器來說，布局過程是經常發生的。
* 繪制。繪制，本質上就是填充像素的過程。包括繪制文字、顏色、圖像、邊框和陰影等，也就是一個DOM元素所有的可視效果。一般來說，這個繪制過程是在多個層上完成的。
* 渲染層合並。由上一步可知，對頁面中DOM元素的繪制是在多個層上進行的。在每個層上完成繪制過程之后，瀏覽器會將所有層按照合理的順序合並成一個圖層，然后顯示在屏幕上。對於有位置重疊的元素的頁面，這個過程尤其重要，因為一旦圖層的合並順序出錯，將會導致元素顯示異常。
記錄了首次加載頁面時，所經歷的Loading -> Scripting -> Rendering -> Painting流程。可見CPU中首先顯示了黃色（代表Scripting）的峰形區域，隨后顯示了紫色（代表Rendering）的峰形區域，表示了頁面在響應點擊事件后所進行的流程。
cpu
記錄瀏覽器內核的運行情況,以曲線區域圖的形式展示。黃色的表示對js的操作所占內存(js代碼評估及函數調用)，藍色表示對html操作所占的內存(主要是html編譯)，紫色表示對css操作所占的內存(css樣式計算等)，灰色表示其他操作所占的內存
由此可見，當在頁面已經得到生成了之后，利用JS去更改個別元素的內容（DOM結構變化），或者是調整元素屬性（CSSOM屬性變化），都會引起頁面重新進行Rendering -> Painting流程。如果這些是不必要的操作，則必定會導致網頁性能降低。因此，對於開發者來說，應該要知道如何去定位網頁中發生重繪的區域。
Rendering界面5個選項的意思如下：
1、Show paint rectangles 顯示繪制矩形
2、Show composited layer borders 顯示層的組合邊界（注：藍色的柵格表示的是分塊）
3、Show FPS meter 顯示FPS幀頻
4、Enable continuous page repainting 開啟持續繪制模式 並 檢測頁面繪制時間
5、Show potential scroll bottlenecks 顯示潛在的滾動瓶頸。
定位網頁中發生重繪的區域
開啟方式：在控制欄的右上角屬性按鈕中，選擇More tools — Rendering，然后在彈出的面板中選擇 Paint Flashing。
在勾選了Paint Flashing后，可以觀察到該行文本在刷新內容過程中，有綠色的方框進行高亮包圍，說明了這一部分區域發生了重新繪制。
說明了個別元素的重新繪制，一般會影響到父元素或者是周圍的元素，造成區域性重繪，因此在頁面中避免不必要的重繪顯得至關重要。
影響頁面重繪的因素主要有2大類:
1、頁面滾動
2、互動操作
1).Dom節點被Javascript改變，導致Chrome重新計算頁面的layout。
2).動畫不定期更新。
3).用戶交互，如hover導致頁面某些元素頁面樣式的變化。
4).調整窗口大小 和 改變字體
5).內容變化，比如用戶在input框中輸入文字
6).激活 CSS 偽類，比如 :hover
7).計算 offsetWidth 和 offsetHeight 屬性
8).增加或者移除樣式表
當發現頁面中，如果存在一些不必要的重繪現象，而又不能夠定位到具體的原因，可以對該區域中的各個元素，依次進行隱藏(在Element面板中設置visibility:hidden)，觀察效果來定位。
More tools — Rendering settings中，還可以開啟 Layer Borders，觀察頁面中的各個區域繪制情況。通過這一項功能，開發者能夠發現頁面中發生動畫或者是CSS transforms/transitions等發生了形狀或位置變化的元素，進而優化其渲染時間。
在頁面最終是由多個“圖層”渲染而成。勾上這個選項，頁面上的“layer(層)”會加上一個黃色的邊框顯示出來
- 黃色邊框：用於顯示頁面上的layer
- 藍色柵格線：表示的是分塊，這些分塊可以看作是比層更低一級的單位
當然，還有其他顏色的邊框線，比如圖片如果單獨有個layer的話，邊框線是藍色的。
使用這個工具，可以查看當前頁面的layer情況，更好的發現頁面不需要的layer將之清除。
show fps meter可以理解為顯示FPS幀頻/幀數。開啟這個選項后，右上角會實時顯示當前頁面的FPS。FPS全稱叫 Frames Per Second (每秒幀數)。幀數越高，動畫顯示的越流暢。一般的液晶顯示器的刷新頻率也就是 60HZ。也就是說，要想頁面上的交互效果及動畫流暢。那么FPS穩定在60左右，是最佳的體驗。
幀模式中最重要的就是右邊的參考線，大於30fps時比較流暢，再大於60fps人眼分辨不出，但是小於30fps時就會有明顯的卡頓感。然后我們可以點擊鼠標在矩形集中的地方，定位問題。瀏覽器對每一幀畫面的渲染工作需要在16毫秒（1秒 / 60 = 16.66毫秒）之內完成。但實際上，在渲染某一幀畫面的同時，瀏覽器還有一些額外的工作要做（比如渲染隊列的管理，渲染線程與其他線程之間的切換等等）。因此單純的渲染工作，一般需要控制在10毫秒之內完成，才能達到流暢的視覺效果。如果超過了這個時間限度，頁面的渲染就會出現卡頓效果，也就是常說的jank，它是很糟糕的用戶體驗。效果圖：當FPS過大時，會顯示紅色的長條，代表有個長幀
當在Flame框圖中點擊了 一個Paint事件（墨綠色），則會在詳情面板中出現一個Paint專有標簽：Paint Profiler。通過Paint Profiler面板，開發者可以知道該次Paint事件的繪制時間、繪制位置和大小等信息，並且能夠具體到某一個元素的繪制耗時：當拖動標尺，直至內容框中僅有目標元素Image的繪制時，即可觀察到其耗時(0.14ms/0.2ms)，以及圖片區域的大小、位置等等信息。
參考