歡迎來到我的專題文章《前端面試題》系列，更多精彩內容持續更新中，歡迎關注！
正如標題，很多面試官喜歡問這類的問題。它主要考查的是前端開發者對於瀏覽器的渲染原理的理解程度。那麼目的是什麼呢？請往下看。
面試的時候，我只是簡單的回答了一個請求處理響應的模型，這很顯然不能讓面試官滿意，結果很明顯，面試失敗。後來回家後仔細研究一番，下面給出我個人的總結吧。
比如我們現在要訪問的是百度的首頁。
瀏覽器的渲染原理
一、域名解析
當用戶輸入一個網站敲了回車後，瀏覽器首先尋找你身邊最近的DNS服務器做域名解析，如果用戶不是第一次輸入這個網站，那麼瀏覽器可能從緩存中去拿到之前解析過的IP。這個緩存可以有以下幾種情況
- 瀏覽器dns緩存
- 系統的dns緩存
- 路由器dns緩存
- 網絡運營商dns緩存
二、建立TCP鏈接
域名解析完成後，瀏覽器和服務器之間就要開始建立tcp鏈接，也就是我們常說的三次握手的操作。
- 第一次握手，是由我們的瀏覽器發起的，目的是告訴服務器，我是否可以發起請求了。
- 第二次握手，是由服務器端發起，告訴瀏覽器，我已經準備好了，你可以發請求了。
- 第二次握手，是由我們的瀏覽器發起的，告訴服務器，我要準備開始發請求了。
這裡需要注意的是，有可能第二次握手的時候，有可能是服務器很忙，正在處理其它的業務需求導致不能立馬響應瀏覽器的請求，將會把瀏覽器的請求駁回。這時候，請求將中斷。
三、瀏覽器發送請求
瀏覽器將請求發送到服務器。然後接下來就是http協議的通信內容。這一塊本身也比較複雜，這裡不再展開了說。
四、接受響應
服務器開始處理瀏覽器提交過來的請求報文。比如瀏覽器每次提交的時候會帶著cookie相關的信息。
五、服務器處理響應
服務器接收到請求後，開始做出響應。並返回結果。比如我們訪問的是百度的首頁，這時候百度的服務器會將百度首頁的html以字符串的形式發送給瀏覽器。
六、渲染頁面
瀏覽器接收到服務器返回的內容後，開始解析響應報文。
- 當遇到html的時候，瀏覽器會調用html解析器，構建dom樹。
- 當遇到style或者link標籤的時候，瀏覽器會調用css解析器，構建cssom樹。
- 當遇到script標籤的時候，瀏覽器會調用js的解析器，進行相關的js操作。
- 瀏覽器將之前構建的dom樹和cssom樹進行合併，形成一個渲染樹(renderTree)。
- 瀏覽器會根據生成的渲染樹去生成佈局，並計算每一個節點的幾何信息，（比如節點的寬高，位置 等信息，注意，這一步比較消耗性能）
- 最後將渲染樹繪製到我們的屏幕上，我們看到了最終的頁面效果。
大概也就是這幾個步驟了吧。當然，瀏覽器的渲染過程要比我列舉的要複雜的多。
值得注意的是：我們可能能將這些步驟完整的說出來，但是在面試的時候，不能只是說出來這些步驟，我們還要去擴展我們自己的一些觀點。
不然面試官問這個瀏覽器的渲染原理有何意義呢？
前面的步驟中我有提到，當瀏覽器開始生成佈局計算每一個節點的幾何信息的時候，會比較消耗性能。
涉及到性能優化的問題，緊接著我們可以帶出與瀏覽相關的dom優化的觀點。比如，我們在做dom優化的時候，儘可能的減少頁面的重排和重繪。
頁面的重排和重繪
可以說，在前端開發過程中，頁面的重排和重繪，是絕對的性能殺手。尤其是重排。那麼哪些情況會帶來頁面的重排和重繪呢？
- 設置元素顯示和隱藏的時候，display屬性，一個元素如果沒有設置absolute或者fixed定位，那麼設置顯示隱藏的時候就會導致頁面的重排和重繪。每一次操作都會導致瀏覽器重新計算它的位置和顯示效果。
- 我們在做普通的動畫過程中儘量不要使用left top margin這些屬性。而可以使用css3中的transform來處理。
- 需要頻繁的切換元素的顯示隱藏的時候，可以考慮先將其進行定位，使其脫離文檔流，這時候只會觸發重繪操作。
到這裡，從瀏覽器的渲染原理，到我們引出瀏覽器相關的dom優化。這樣的回答應該才是面試官想聽到的吧。
總結：
瀏覽器的沉浸原理在網上可以搜到很詳細的資料大家酌情選擇回答即可，但是也不能直接照搬，從瀏覽器的渲染原理一定要引出自己的一些觀點。
只是一味的按網上的回答，也並不一定能使面試官滿意。希望我的回答能夠幫助到正在和即將要找工作的你們、
這裡是【暢哥聊技術】的《前端面試題》專題系列。更多內容持續更新中。
下期我們接著聊，未完待續。。。
