前方指路：
面經：騰訊前端一二三面
手寫代碼題：github
前端面試之JavaScript篇
前端面試之ES6篇
前端面試之HTML&CSS篇
前端面試之網絡篇
前端面試之瀏覽器篇
前端面試之webpack篇
前端面試之vue篇
前端面試之性能優化篇
目錄
從輸入URL到瀏覽器顯示頁面經過了什麼
1、首先，在瀏覽器地址欄中輸入url
2、瀏覽器先查看瀏覽器緩存-系統緩存-路由器緩存，如果緩存中有，會直接在屏幕中顯示頁面內容。若沒有，則跳到第三步操作。
3、在發送http請求前，需要域名解析(DNS解析)，解析獲取相應的IP地址，DNS具體解析過程在前端面試之網絡篇中有介紹。
4、瀏覽器向服務器發起tcp連接，與瀏覽器建立tcp三次握手，三次握手在前端面試之網絡篇中也有介紹。
5、握手成功後，瀏覽器向服務器發送http請求，請求數據包。
6、服務器處理收到的請求，將數據返回至瀏覽器。
7、瀏覽器收到HTTP響應。
8、讀取頁面內容，開始瀏覽器渲染。
9、解析HTML，生成Dom樹，解析css樣式，生成CSSOM樹，兩者結合生成Render樹。解析包括標記化和生成樹兩個過程，這期間還可能存在js和css阻塞，具體的過程可以在用Chrome Performance分析瀏覽器渲染原理中查看。
10、客戶端和服務器交互
11、ajax查詢
另外，如果是HTTPS協議，還會在TCP通信之前利用SSL協議的加密傳輸。這個具體過程也可以在前端面試之網絡篇中看到。
window.onload、documentloaded、document.ready
documentloaded（document.ready）：文檔結構加載完成
window.onload：資源全部加載完成
瀏覽器渲染原理
簡單說就是解析HTML文檔，生成DOM樹，解析CSS文檔生成CSSOM樹，DOM樹與CSSOM樹結合會生成Render樹，然後發生迴流，頁面渲染。在解析HTML文檔的時候，如果遇到js，就暫停解析，等script執行完在繼續解析，如果樣式表正在解析的話，js會先等樣式表解析完成。也就是說，css解析優先於js解析，js解析優先於html解析。原因當然就是前者會影響後者的解析。
這塊挺常考的，建議大家把用Chrome Performance分析瀏覽器渲染原理看一下。
迴流和重繪
其實知道了瀏覽器渲染原理，迴流和重繪也就知道了。這裏在囉嗦一下。
當render樹中發生元素的規模、位置、顯示隱藏等變化時就會發生迴流（也叫重排），頁面第一次渲染的時候一定會發生迴流。
當render樹僅僅發生外觀變化而不影響佈局時會發生重繪。
比如，元素的margin、padding、display、width、height改變會引起迴流，background-color改變會引起重繪。
迴流必引起重繪，重繪不一定會引起迴流。
由於發生迴流和重繪時，瀏覽器需要重新構建render樹，因此這是很影響性能的，我們在寫代碼時要儘量減少迴流和重繪。比如在添加DOM節點時，試着用一個變量接收要添加的所有節點，然後一次全部添加上去。
瀏覽器緩存機制
這裏借鑑一下實踐這一次，徹底搞懂瀏覽器緩存機制這裏面的內容。
訪問緩存優先級：
- 內存（memory cache）
- 磁盤（disk cache）
- 網絡請求
強緩存
瀏覽器在加載資源時，會先根據本地緩存資源的 header 中的信息判斷是否命中強緩存，如果命中則直接使用緩存中的資源不會再向服務器發送請求。
這裏的 header 中的信息指的是 expires 和 cahe-control。
Expires
該字段是 http1.0 時的規範，它的值爲一個絕對時間的 GMT 格式的時間字符串，比如 Expires:Mon,18 Oct 2066 23:59:59 GMT。這個時間代表着這個資源的失效時間，在此時間之前，即命中緩存。這種方式有一個明顯的缺點，由於失效時間是一個絕對時間，所以當服務器與客戶端時間偏差較大時，就會導致緩存混亂。
Cache-Control
Cache-Control 是 http1.1 時出現的 header 信息，主要是利用該字段的 max-age 值來進行判斷，它是一個相對時間，例如 Cache-Control:max-age=3600，代表着資源的有效期是 3600 秒。cache-control 除了該字段外，還有下面幾個比較常用的設置值：
no-cache：需要進行協商緩存，發送請求到服務器確認是否使用緩存。
no-store：禁止使用緩存，每一次都要重新請求數據。
public：可以被所有的用戶緩存，包括終端用戶和 CDN 等中間代理服務器。
private：只能被終端用戶的瀏覽器緩存，不允許 CDN 等中繼緩存服務器對其緩存。
Cache-Control 與 Expires 可以在服務端配置同時啓用，同時啓用的時候 Cache-Control 優先級高。
協商緩存
當強緩存沒有命中的時候，瀏覽器會發送一個請求到服務器，服務器根據 header 中的部分信息來判斷是否命中緩存。如果命中，則返回 304 ，告訴瀏覽器資源未更新，可使用本地的緩存。
這裏的 header 中的信息指的是 Last-Modify/If-Modify-Since 和 ETag/If-None-Match。
Last-Modify/If-Modify-Since
瀏覽器第一次請求一個資源的時候，服務器返回的 header 中會加上Last-Modify，Last-modify是一個時間標識該資源的最後修改時間。
當瀏覽器再次請求該資源時，request 的請求頭中會包含If-Modify-Since，該值爲緩存之前返回的 Last-Modify。服務器收到 If-Modify-Since 後，根據資源的最後修改時間判斷是否命中緩存。
如果命中緩存，則返回 304，並且不會返回資源內容，並且不會返回 Last-Modify。
ETag/If-None-Match
與 Last-Modify/If-Modify-Since 不同的是，Etag/If-None-Match返回的是一個校驗碼。ETag 可以保證每一個資源是唯一的，資源變化都會導致ETag變化。服務器根據瀏覽器上送的 If-None-Match 值來判斷是否命中緩存。
與 Last-Modified不一樣的是，當服務器返回 304 Not Modified 的響應時，由於 ETag 重新生成過，response header 中還會把這個ETag 返回，即使這個ETag 跟之前的沒有變化。
Last-Modified與 ETag是可以一起使用的，服務器會優先驗證 ETag，一致的情況下，纔會繼續比對 Last-Modified，最後才決定是否返回 304。
last-modified缺點
-
一些文件也許會週期性的更改，但是他的內容並不改變(僅僅改變的修改時間)，這個時候我們並不希望客戶端認爲這個文件被修改了，而重新get；
-
某些文件修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了N次)，if-modified-since能檢查到的粒度是秒級的，這種修改無法判斷(或者說UNIX記錄MTIME只能精確到秒)；
-
某些服務器不能精確的得到文件的最後修改時間。