一、背景
我們要監測網站的加載情況，可以使用?window.performance 來簡單的檢測。
window.performance?是W3C性能小組引入的新的API，目前IE9以上的瀏覽器都支持。一個performance對象的完整結構如下圖所示：
memory字段代表JavaScript對內存的占用。
navigation字段統計的是一些網頁導航相關的數據：
redirectCount:重定向的數量（只讀），但是這個接口有同源策略限制，即僅能檢測同源的重定向；- type 返回值應該是0,1,2 中的一個。分別對應三個枚舉值:
- 0 : TYPE_NAVIGATE (用戶通過常規導航方式訪問頁面，比如點一個鏈接，或者一般的get方式)
- 1 : TYPE_RELOAD (用戶通過刷新，包括JS調用刷新接口等方式訪問頁面)
- 2 : TYPE_BACK_FORWARD (用戶通過后退按鈕訪問本頁面)
最重要的是timing字段的統計數據，它包含了網絡、解析等一系列的時間數據。
timing的整體結構如下圖所示：
二、痛點
我們通過window.performance來檢測加載情況，并不能非常直觀的分析出影響網站加載速度的具體因素，因此，我們需要專業的工具來輔助我們完成。
三、在線監測工具
1、GTmetrix? https://gtmetrix.com/ （不需要FQ，需要人工自己分析）
2、PageSpeed Insights https://developers.google.com/speed/pagespeed/insights/（需要FQ，無需人工分析，會自動分析出優化相關內容） ?
?
四、GTmetrix 使用簡介
以淘寶網分析為例
?得分情況
一般互聯網的網站，得分要達到C（包含A和B）以上，最好能達到B。
切換到?PageSpeed?選項卡
1. 可用的用戶名2. 避免使用著陸頁面重定向3. 指定緩存驗證4. 優化圖片5. 利用瀏覽器Cache，加過期時間6. 請求最小化7. 重定向最小化8. 指定圖像尺寸9. 壓縮js10. 延遲解析js11. 壓縮html12. 啟用GZIP壓縮13. 盡早指定字符集14. 壓縮css15. 從靜態資源中刪除查詢字符串16. 如果壓縮了，指定Accept-Encoding的頭17. 避免不良請求18. 使用Keep-Alive19. 使用網上css20. ....
切換到?YSlow?選項卡
1. 減少HTTP請求次數
合并圖片、CSS、JS，改進首次訪問用戶等待時間。
2. 使用CDN
就近緩存==>智能路由==>負載均衡==>WSA全站動態加速
3. 避免空的src和href
當link標簽的href屬性為空、script標簽的src屬性為空的時候，瀏覽器渲染的時候會把當前頁面的URL作為它們的屬性值，從而把頁面的內容加載進來作為它們的值。
4. 為文件頭指定Expires
使內容具有緩存性。避免了接下來的頁面訪問中不必要的HTTP請求。
5. 使用gzip壓縮內容
壓縮任何一個文本類型的響應，包括XML和JSON，都是值得的。舊文章
6. 把CSS放到頂部
7. 把JS放到底部
防止js加載對之后資源造成阻塞。
8. 避免使用CSS表達式
9. 將CSS和JS放到外部文件中
目的是緩存，但有時候為了減少請求，也會直接寫到頁面里，需根據PV和IP的比例權衡。
10. 權衡DNS查找次數
減少主機名可以節省響應時間。但同時，需要注意，減少主機會減少頁面中并行下載的數量。
IE瀏覽器在同一時刻只能從同一域名下載兩個文件。當在一個頁面顯示多張圖片時，IE 用戶的圖片下載速度就會受到影響。所以新浪會搞N個二級域名來放圖片。
11. 精簡CSS和JS
12. 避免跳轉
同域：注意避免反斜杠 “/” 的跳轉；
跨域：使用Alias或者mod_rewirte建立CNAME（保存域名與域名之間關系的DNS記錄）
13. 刪除重復的JS和CSS
重復調用腳本，除了增加額外的HTTP請求外，多次運算也會浪費時間。在IE和Firefox中不管腳本是否可緩存，它們都存在重復運算JavaScript的問題。
14. 配置ETags
它用來判斷瀏覽器緩存里的元素是否和原來服務器上的一致。比last-modified date更具有彈性，
例如某個文件在1秒內修改了10次，Etag可以綜合Inode(文件的索引節點(inode)數)，MTime(修改時間)和Size來精準的進行判斷，
避開UNIX記錄MTime只能精確到秒的問題。 服務器集群使用，可取后兩個參數。使用ETags減少Web應用帶寬和負載
15. 可緩存的AJAX
“異步”并不意味著“即時”：Ajax并不能保證用戶不會在等待異步的JavaScript和XML響應上花費時間。
16. 使用GET來完成AJAX請求
當使用XMLHttpRequest時，瀏覽器中的POST方法是一個“兩步走”的過程：首先發送文件頭，然后才發送數據。因此使用GET獲取數據時更加有意義。
17. 減少DOM元素數量
是否存在一個是更貼切的標簽可以使用？人生不僅僅是DIV+CSS
18. 避免404
有些站點把404錯誤響應頁面改為“你是不是要找***”，這雖然改進了用戶體驗但是同樣也會浪費服務器資源（如數據庫等）。
最糟糕的情況是指向外部 JavaScript的鏈接出現問題并返回404代碼。首先，這種加載會破壞并行加載；
其次瀏覽器會把試圖在返回的404響應內容中找到可能有用的部分當作JavaScript代碼來執行。
19. 減少Cookie的大小
20. 使用無cookie的域
比如圖片 CSS 等，Yahoo! 的靜態文件都在主域名以外，客戶端請求靜態文件的時候，減少了 Cookie 的反復傳輸對主域名的影響。
21. 不要使用濾鏡
png24的在IE6半透明那種東西，別亂使，淡定的切成PNG8+jpg
22. 不要在HTML中縮放圖片
23. 縮小favicon.ico并緩存
切換到?Waterfall?選項卡
?
首先，看下頁面加載時間軸
1.URL重定向時間（Redirect duration）
包括：
Redirect from a non-www to www (eg. example.com to www.example.com)
Redirect to a secure URL (eg. http:// to https://)
Redirect to set cookies
Redirect to a mobile version of the site
說明：一個網站可能會執行多個重定向鏈，這個時間為總時間；如果沒有重定向，則為0。
優化：即通過減少重定向 
2.連接時間（Connection duration）
包括：即阻塞時間+DNS時間+連接時間+發送請求時間說明：即第一個200OK的發送時間優化：一般時間很短，無優化！ 
3.后端持續時間（Backend duration）
包括：后端處理數據的時間說明：后端響應時間優化：后端代碼優化（重中之重）
推薦：Why is my page slow? 
4.接收到第一個字節的時間（Time to First Byte (TTFB)）
包括：顧名思義，前三個時間的加和說明：即從開始測試到頁面接收到響應的時間優化：優化應用程序代碼，實施緩存機制，微調Web服務器配置或升級服務器硬件。 ?
5.DOM交互時間點（DOM interactive time）（不重要）
說明：與下面的DOM內容加載時間點非常接近，沒有標記
6.DOM內容加載時間點（DOM content loaded time）
說明：如果沒有阻止JS執行樣式并且沒有解析器阻止JS，它將于上面的DOM interactive time 相同許多JavaScript框架使用這個時間點作為開始執行他們的代碼的起點。優化：由于這個時間經常被js用作起點，并且這個時間的延遲代表著延遲渲染，故確保樣式、js的加載順序和js延遲是非常重要的 推薦：?style and script order is optimized? and that parsing of JavaScript is deferred.
7.第一次渲染時間點（First paint time）
說明：在這一時間點前，瀏覽器將只顯示一個空白頁面
8.第一個內容被渲染完時間點（First contentful paint time）
說明：當任何內容被渲染時，可以是文本，圖像或畫布渲染。目的是為了更好的體現用戶的體驗，因為它會在實際的內容被加載到頁面上時進行標記，
而不僅僅是任何改變 - 但是通常可能與First Paint相同。所以這個指標是讓你了解你的用戶什么時候收到消費信息（文本，視覺等）
對于性能評估來說，比背景改變或者應用風格更有用。如果瀏覽器沒有執行渲染（即HTML結果為空白頁），則渲染時間可能會丟失。
9.加載完成時間點（Onload time）
說明：當頁面處理完成并且頁面上的所有資源（圖像，CSS等）已經完成加載時。
此時，JavaScript window.onload事件觸發，括號中的時間是執行由Onload事件觸發的JavaScript的時間
?
五、?PageSpeed?Insights?使用簡介
以淘寶網分析為例
給出的優化建議
?
?
?
?
?
?
