從輸入url到頁面載入完成，發生了什麼？
這個問題非常重要，因為後續的內容都將以這個問題答案為骨架展開。我們現在站在效能優化的角度一起簡單地複習一下這個經典的過程：首先我們通過DNS將url解析為對應的IP地址，然後與這個IP地址確定的那臺伺服器建立起TCP網路連線，隨後我們向服務端丟擲我們的HTTP請求，服務端處理完我們的請求後把目標資料放在HTTP相應裡面返回給客戶端，拿到相應資料的瀏覽器就可以開始渲染的過程，渲染完畢就可以呈現給使用者，並等待相應使用者操作（如下圖）。
我們將這個過程切分為如下的過程片段：
- DNS解析
- TCP連線
- HTTP請求丟擲
- 服務端處理請求，HTTP相應返回
- 瀏覽器拿到相應資料，解析響應內容，把解析的結果展示給使用者
大家謹記，我們任何一個使用者端的產品，都需要把這 5 個過程滴水不漏地考慮到自己的效能優化方案內、反覆權衡，從而打磨出使用者滿意的速度
從原理到實踐：各個擊破
我們接下來要做的事情，就是針對這五個過程進行分解，各個提問，各個擊破。
具體來說，DNS解析花時間，能不能儘量減少解析次數或者把解析前置？能——瀏覽器DNS快取和DNS prefetch。TCP每次的三次握手都急死人，有沒有解決方案？有——長連結，預連結，接入SPDY協議。如果說這兩個優化往往都需要我們和團隊的服務端工程師協作完成，前端單方面努力很有限，那麼HTTP請求呢？——在減少請求次數和減少請求體積方面，我們應該是專家！再者伺服器越遠，一次請求就越慢，那部署時把靜態資源放在離我們更近的CDN上是不是就能夠快一些？
以上提到的都是網路層面的效能優化，再往下走就是瀏覽器端的效能優化——這部分涉及資源載入優化、服務端渲染、瀏覽器快取機制的作用、DOM樹的構建、網頁排版和渲染過程、迴流與重繪的考量、DOM操作的合理規避等等——這才是前端工程師可以真正施展拳腳的地方，學習這些知識，不僅可以幫助我們從根本上提升頁面效能，更能夠大大加深個人對瀏覽器底層原理、執行機制的理解，一舉兩得！
我們整個的知識圖譜，用思維導圖展示如下：
本文轉自《前端效能優化原理與實踐》