頁面渲染性能的優化衡量指標
window.performance是w3c提供的用來測量網頁和Web應用程序的性能api。其中performance timing提供了延時相關的性能信息，可以高精度測量網站性能 。
白屏時間=頁面開始展示的時間點(PerformanceTiming.domLoading)-開始請求時間點(PerformanceTiming.navigationStart)
首屏時間=首屏內容渲染結束時間點(視業務具體情況而定)-開始請求時間點(PerformanceTiming.navigationStart)
可交互時間=用戶可以正常進行事件輸入時間點（PerformanceTIming.domInteractive）-開始請求時間點(PerformanceTiming.navigationStart)。
頁面渲染性能的優化策略
1. 防止阻塞渲染：
css 放在首部，提前加載 ；js文件放在底部，防止阻塞解析 ；一些不改變dom和css的js 使用 defer 和 async 屬性告訴瀏覽器可以異步加載，不阻塞解析 。
2. 減少重繪和迴流：
重繪和迴流在實際開發中是很難避免的，我們能做的就是儘量減少這種行爲的發生。
js儘量少訪問dom節點和css 屬性
儘可能的爲產生動畫的 HTML 元素使用 fixed 或 absolute 的 position ，那麼修改他們的 CSS 是不會 Reflow 的。
img標籤要設置高寬，以減少重繪重排
把DOM離線後修改，如將一個dom脫離文檔流，比如display：none ，再修改屬性，這裏只發生一次迴流。
儘量用 transform 來做形變和位移，不會造成迴流
3. 提高代碼質量：
1）html：
dom的層級儘量不要太深，否則會增加dom樹構建的時間，js訪問深層的dom也會造成更大的負擔。
meta標籤裏需要定義文檔的編碼，便於瀏覽器解析
2）css：
減少 CSS 嵌套層級和選擇適當的選擇器
對於首屏的關鍵css 可以使用style標籤內聯
3）js：
減少通過JavaScript代碼修改元素樣式，儘量使用修改class名方式操作樣式或動畫
訪問dom節點時需要對dom節點轉存，防止循環中重複訪問dom節點造成性能損耗。
慎用 定時器 和 計時器， 使用完後需要銷燬。
用於複雜計算的js代碼可以放在worker進程中運行。
靜態資源:
1）拼接、合併、壓縮、製作雪碧圖：
由於HTTP的限制，在建立一個tcp請求時需要一些耗時，所以，我們對資源進行合併、壓縮，其目的是減少http請求數和減小包體積，加快傳輸速度 。
2）CDN資源分發：
將一些靜態資源文件託管在第三方CDN服務中，一方面可以減少服務器的壓力，另一方面，CDN的優勢在於，CDN系統能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上，保證資源的加載速度和穩定性。
3）緩存：
緩存的範圍很廣，比如協議層的DNS解析緩存、代理服務器緩存，到客戶端的瀏覽器本地緩存，再到服務端的緩存。一個網絡鏈路的每個環節都有被緩存的空間。緩存的目的是簡化資源的請求路徑，比如某些靜態資源在客戶端已經緩存了，再次請求這個資源，只需要使用本地的緩存，而無需走網絡請求去服務端獲取。
4）分片：
將資源分佈到不同的主機上，可以建立更多的tcp請求，降低請求耗時，從而提升網頁速度。
5）升級協議：
可以升級我們的網絡協議，比如使用HTTP2，quic 之類的，代替之前的http1.1，從協議層優化資源的加載。
業務數據：
1）首屏直出：
爲了提升用戶體驗，我們認爲首屏的渲染速度是極爲重要的，用戶進來頁面，首頁可見區域的加載可以由服務端渲染，保證了首屏加載速度，而不可見的部分則可以異步加載，甚至做到子路由頁面的預加載。業界已經有很多同構直出的方案，比如vue的nuxt ， react的beidou等。
2）接口合併：
前端經常有這樣的場景，完成一個功能需要先請求第一個接口獲得數據，然後再根據數據請求第二個接口獲取第二個數據，然後第三、第四…前端通常需要通過promise或者回調，一層一層的then下去，這樣顯然是很消耗性能的 。
參考：頁面渲染性能的優化