考慮頁面性能可以從兩種場景，第一個場景也是因素最多的場景，即首次通路。第二個場景則是重複通路，緩存将起決定性作用。
不同的頁面類型的性能優化政策也是不一樣的，比如富文本頁面，富多媒體頁面，響應式設計的頁面，遊戲頁面等。
浏覽器也提供了很多工具和插件，比如Chrome DevTools, YSlow和PageSpeed Insight都有相應的插件，可以為開發者提供頁面優化建議，這是最為簡捷的方式。我在這裡也主要使用Chrome進行分析，部分會配合WebPageTest工具。
要優化頁面性能，了解浏覽器如何渲染頁面是非常重要的。以下是浏覽器加載的整套流程,特别強調了對首次打開性能影響很大的網絡加載流程：
其中如果HTTPS，建立連接配接的過程中還需要進行身份認證。
通過Chrome Inspect中的網絡也可以看到整個加載資料量，以及耗時:
上圖是新浪首頁的資料，共發出415請求，收到6.5MB的資料，主要是圖檔大多，果然是個大站!
點開可以看到細節的資料耗時:
上面可以看到為請求建立與伺服器的連接配接的開銷還是比較大的。特别是在移動網絡下，DNS解析，錯誤重連的成本都非常高，浏覽器廠商也都會針對性的進行優化。
無論是以前的Pipeline, 和現在的Http2都可以達到連接配接複用的目的，也可以省掉這部分的開銷。
Chrome的開發者工具提供了Audit, 可以提供網絡相關優化和頁面性能優化的建議, 比如:
在Chrome Web Store裡安裝YSlow和PageSpeed Insights插件，就可以進一步分析頁面的性能，以及提供相關的建議。下圖是YSlow的顯示頁面元件的内容:
在後面Statistics頁簽會顯示資源占比，以及啟用緩存（下次通路）時需要發送的請求數和資源大小:
可惜這隻是理想，新浪有些資源的url帶有随機數，也就是每次請求的url并不相同，會導緻http cache無法使用，會重新加載。
最終新浪首頁的性能顯示不怎麼樣，YSlow給出了D，附上一堆建議,點來Grade頁簽就可以看到。
PageSpeed Insights會給出相類似的建議，不過個人還是建議使用PageSpeed Insights, 它給出的建議會更加符合目前業界的标準。
除了TTFB這種主要由網絡環境和背景伺服器決定的因素外,頁面設計，以及包括User Agent(用戶端，如浏覽器)可能影響的因素包括:
<b>連接配接管理 （連接配接數和複用)</b>
在HTTP下本來有一個Pipeline的機制，用來達到一個HTTP連接配接來并發擷取多個資源，但是伺服器支援的少。
另一種方法是Keep alive的常連接配接。即User Agent嘗試保持若幹個連接配接，完成一個資源的加載後，這個連接配接可以繼續用來加載另一個資源。這樣就沒有重建立立連接配接的開銷。
而HTTP 2最大的特色就是讓每一個連接配接支援多個資源的并發請求。
<b>請求數</b>
<b>請求大小</b>
因為網絡裡上行和下行的速度差異，請求的大小也會對頁面性能有所影響， 是以要避免不必要的請求頭資訊，其中Cookie最為明顯。首先Cookie的存儲、檢索和提取就要耗費性能，再加上Cookie的應用往往是針對某個域名下或者路徑下的所有請求，會導緻性能的影響被放大。
<b>資源大小</b>
HTML5新的響應式圖檔更是允許根據用戶端(User Agent)的螢幕大小,而選擇不同的圖檔。
<b>HTTP Cache</b>
網絡層的緩存子產品，負責管理可緩存的資源，盡量複用緩存中已經有的可用資源。最快的請求就是不發請求，善于使用Http Cache，可以大大優化除首次打開外頁面性能。但是一些網站遇到一些緩存問題時，常常簡單的為url增加一個随機數，讓緩存失效，這樣既讓用戶端的整體緩存命中率下降（緩存了很多不必要的資源）,強烈建議不要使用這種方法。
開始加載頁面，到實際顯示出内容，有一個最小的路徑，即關鍵渲染路徑。盡量縮短這條路徑才能真正優化到使用者的體驗。
最核心的流程是浏覽器收到頁面資料後解析為DOM (Document Object Model), 加載CSS檔案，生成CSSOM，計算各個元素的排版資料生成Layout Tree, 結合者CSSOM生成Render Tree，再交由渲染子產品完成渲染顯示出頁面内容。
這過程中包括很多的并發行為，因為串行完成的性能不可能達到使用者體驗的要求。
CSS
在這個路徑主要是注意一些會阻塞頁面解析的元素，如CSS。前面提到CSS檔案放到head和body中的方式。
JavaScript
直接出現在頁面中的JavaScript會阻塞頁面解析, 是以需要将一些JavaScript可以改為異步加載和執行。
<b>定義:可操作時間 (Time To Interactivity)</b>
可操作時間是指從開始加載頁面到使用者可以在頁面進行操作（如搜尋，點選連結等）的時間。
通過優化關鍵渲染路徑可以減少可操作時間，包括以下方法:
異步加載内容
優先加載可見内容
遵循CSS/JS加載的最佳實踐 (看YSlow和PageSpeed Insights的報告)
緩存資源
優先保證主要使用者行為盡早可用
比如下面這個Chrome DevTools顯示出一個Long Frame, 從前面一個Frame這裡花去了很長的時間，這一般代表卡頓的出現 (隻有9fps)。
如果使用PageSpeed Insights，可以得到關于Blocking CSS的建議。