## 前言 經過前面兩篇文章，相信你已經能從一些方面進行網頁的優化，下面從其他角度分享一些常用的策略。 一個頁面，會經歷過加載資源，執行腳本，渲染界面的過程。我們知道，100ms對于計算機來說，可以干很多事情了，但是對于網絡請求，可能一次RTT就沒了。因此，頁面加載對于Web性能是重中之重。 ## 加載性能分析 加載的快慢可以總結成受兩個因素影響：阻塞與延遲。 1、阻塞。瀏覽器在解析到腳本時，會阻塞頁面，等到腳本下載執行完才繼續解析文檔。此外，瀏覽器還會限制同域下的并行請求數，超過這個限制后的請求就會被阻塞住。 2、延遲。網絡請求都不可避免會有延遲，網頁上的延遲有兩種，一是DNS查詢，二是TCP連接。 * 克服這些缺點，我們有一些約定俗成的方案： * 靜態資源要支持304，開啟HTTP緩存控制 * 開啟gzip，壓縮HTTP body * css放在html的head里，js在body底部 * 合并請求 * 使用雪碧圖 * 域名分區（突破并行限制，也避免傳輸過多cookie） * 使用cdn 3、 加載過程圖解 定向--dns查詢--建立tcp連接--下載dom--頁面根據樣式和腳本渲染--交互流動性  ## 常見的解決方案 ### 避免重定向 重定向意味著要重新發起請求，當然我們沒事也不會亂跳。這里要說的一種重定向是，訪問HTTP站點，跳轉到HTTPS。 避免這種跳轉，我們可以用**HSTS策略**，就是告訴瀏覽器，以后訪問我這個站點，必須用HTTPS協議來訪問，讓瀏覽器幫忙做轉換，而不是請求到了服務器后，才知道要轉換。只需要在響應頭部加上 `Strict-Transport-Security: max-age=31536000` ### 預加載 DNS查詢需要個RTT時間，在瀏覽器級別，系統級別都會有層DNS緩存，之前解析過的可以直接從本機緩存獲取，以減少延遲。 Web標準提供了一種DNS預解析技術，因為服務器是知道頁面即將會發生哪些請求的，那我們可以在頁面頂部，插入 <link rel="dns-prefetch" href="//host/">，讓瀏覽器先解析一下這個域名。那么，后續掃到同域的請求，就可以直接從DNS緩存獲取了。 此外，Web標準也提供prefetch，prerender的預加載技術。prefectch會在瀏覽器空閑的時候，向所提供的鏈接發起請求，而prerender不僅會請求，還會幫你在后臺渲染頁面。如果在一個頁面中，你知道用戶有很大概率去點某個鏈接，可以嘗試把這個鏈接加到prefetch或prerender，那么用戶就會秒開這個頁面了。 ### 使用TCP、TLS最佳實踐 HTTP請求要經過建立TCP連接這一步，而TCP為了可靠傳輸，建立連接需要三次握手。如果網站又接入了HTTPS，那還要額外多兩次RTT時間以建立安全通道，這樣耗費了很多時間。HTTP是建立在TCP、TLS之上，那么TCP的最佳實踐，SSL的優化都是適用于HTTP的優化。 比如TCP慢啟動過程非常影響性能的，我們可以把初始窗口調大，讓慢啟動更快。對于TLS可用緩存session_ticket之類的優化可以減少一次RTT。 ### 內聯 對于一些簡單的頁面，CSS樣式和JavaScript腳本甚至圖片，可以不必使用外聯的方式引入，直接把子資源內嵌到HTML里，圖片可以用base64編碼內嵌，這相當于請求頁面時，服務器順便把子資源給一共推送過去了。傳輸的內容都一樣，但減少好多請求了，自然節省不少時間。 不過這樣做的缺點是瀏覽器無法緩存這些子資源，這種做法只能降低首次加載時間，所以需要看取舍了。可能比較適用于一次性的頁面，類似活動之類的。 ### 手動管理緩存 為了代碼架構清晰，便于維護，我們都會用模塊化的方式去編碼，每個模塊一個文件，這樣帶來的問題是一個頁面需要很多文件，要很多請求，這對頁面性能是不利的。合并是解決這個問題的好方法，但又因為HTTP緩存機制是基于URL的，只要某個模塊一改動，整個合并資源都要重新下載。 在對性能要求較高，比如在移動設備環境上，我們可以利用HTML5中的localStorage特性，來實現手動控制緩存。大概的思路是，在定義模塊時，同時將模塊的代碼和版本號分別儲存到localStorage，在下一次打算請求模塊之前，我們先判斷模塊的最新版本是不是在localStorage中，將不存在的模塊組合在一起，請求動態合并的資源。 不過，這種方案可能會引發安全問題。假如同域下的其他頁面被XSS攻擊，壞人就可以篡改localStorage的內容，可能導致原來的頁面代碼被植入惡意程序。解決的方法是，在執行模塊之前，算一下代碼摘要，對比下服務器給的該模塊的摘要，再決定是否使用。也可以使用SRI策略，由瀏覽器幫你做校驗。 ### HTTP持久連接 TTP持久連接可以重用已建立的TCP連接，減少三次握手的RTT延遲。瀏覽器在請求時帶上 `connection: keep-alive` 的頭部，服務器收到后就要發送完響應后保持連接一段時間，瀏覽器在下一次對該服務器的請求時，就可以直接拿來用。 以往，瀏覽器判斷響應數據是否接收完畢，是看連接是否關閉。在使用持久連接后，就不能這樣了，這就要求服務器對持久連接的響應頭部一定要返回content-length標識body的長度，供瀏覽器判斷界限。有時，content-length的方法并不是太準確，也可以使用 `Transfer-Encoding: chunked `頭部發送一串一串的數據，最后由長度為0的chunked標識結束。  ### HTTP管線化 HTTP管線化可以克服同域并行請求限制帶來的阻塞，它是建立在持久連接之上，是把所有請求一并發給服務器，但是服務器需要按照順序一個一個響應，而不是等到一個響應回來才能發下一個請求，這樣就節省了很多請求到服務器的時間。不過，HTTP管線化仍舊有阻塞的問題，若上一響應遲遲不回，后面的響應都會被阻塞到。  ### bigpipe 目前大部分應用是吧界面以及數據全部準備好之后再進行渲染，而實際上是可以按照分幀分別處理的，如果頁面包含多個較獨立部分，也可以每處理完一部分就馬上輸出，這樣可以縮短白屏。從用戶感受上可能會更好，頁面上一直有所反應，而不是一直白屏，完全不知道你在干嘛。 各種各樣的優化，都在填HTTP/1.x留下的坑，HTTP/2帶著填坑的使命，從根本上去解決這些問題。HTTP/1.x是一個文本協議，這注定它是非常冗余的協議，HTTP/2改變了這一點，在HTTP/1.x的語義上，將文本數據封裝在幀里，并采用二進制編碼。 HTTP/2的性能怎樣，akamai的這個demo(https://http2.akamai.com/demo)估計會讓你很興奮。 ## 服務器推送 作為HTTP/2的一個重磅新功能，我們不要簡單理解字面意思，其實不是你想推，想推就能推的，服務器要遵循請求-響應這個模型，只不過服務器對同一請求可以推送多個響應。客戶端在交換 SETTINGS 幀時，設置字段 SETTINGS_ENABLE_PUSH（0x2） 為1顯式允許服務器推送。 在HTTP/1.x時代，其實我們已經體驗過了“服務器推送”，就是資源內嵌到HTML里。服務器在響應HTML時，就已經知道瀏覽器會請求哪些子資源了，這時一并響應這些子資源，可以節省了服務器到瀏覽器以及瀏覽器解析再發請求的這段延遲。但是內聯的問題是瀏覽器不會緩存這些數據，這意味要浪費很多流量，而且有緩存時網頁性能還是很好的。 服務器推送解決了這個問題。服務器在接受到請求時，分析出要推送的資源，先發個 PUSH_PROMISE 幀給瀏覽器。此幀包含一個新的流ID，還有header block fragment字段，內容是請求的頭部信息，可理解為服務器模擬瀏覽器發起請求，然后再發送各個response header和response body。瀏覽器收到 PUSH_PROMISE 幀時，根據header block fragment字段里的url，可以知道當前有沒有緩存，從而判斷是否要接收。如果不要，瀏覽器就要發送個 RST_STREAM 來終止服務器推送。 如果瀏覽器不要這個推送，就會出現浪費流量的現象，因為整個過程都是異步的，在服務器接收到RST_STREAM時，響應很有可能部份發出或者全部發出了。這種情況只能視場景而定，若是流量浪費不能容忍，我們可以使用prefetch來替代，讓瀏覽器盡早發現需要的資源，而HTTP/2中創建新的請求并不需要多少時間，所以大概多了個RTT的時間。