鏈接：https://www.zhihu.com/question/41184156/answer/135195798
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
如果不會被重復加載，機制是什么？
這個問題其實就是web的cache問題，首先加載是肯定的，但是接下來的過程會有不同，
我們看看加載的時候發生了什么：
1. 客戶端請求一個js文件（a.js）。
2. 服務器返回a.js，並在給它加上一個Last-Modified/ETag。
3. 客戶端獲取到a.js，並將它連同Last-Modified/ETag一起緩存。
4. 客戶再次請求該文件（比如說刷新頁面，或是同站跳轉），並將上次請求時服務器返回的Last-Modified/ETag 作為請求頭的If-Modified-Since/If-None-Match一起傳遞給服務器。
5. 服務器檢查該If-Modified-Since/If-None-Match(即前一次響應頭中的Last-Modified或ETag），並判斷出該頁面自上次客戶端請求之后還未被修改，直接返回響應304和一個空的響應體。
由上面可以看出，雖然在客戶端還是發起了一次請求，但是可以避免接下來更多的服務器操作，並且沒有返回該文件而只是一個 HTTP Header，從而大大的降低帶寬的消耗，提高用戶體驗。
這里的講下304狀態碼。304狀態碼表示客戶端有緩沖的文檔並發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔）。如果客戶端在請求一個文件的時候，發現自己緩存的文件有 Last Modified ，那么在請求中會包含 If Modified Since ，這個時間就是緩存文件的 Last Modified 。服務器只要判斷這個時間和當前請求的文件的修改時間就可以確定是返回 304 還是 200 。對於靜態文件，例如：CSS、圖片，服務器會自動完成 Last Modified 和 If Modified Since 的比較，完成緩存或者更新。
還有一種情況：
對於動態頁面，就是動態產生的頁面，往往沒有包含 Last Modified 信息，這樣瀏覽器、網關等都不會做緩存，也就是在每次請求的時候都完成一個 200 的請求。因此，對於動態頁面做緩存加速，首先要在 Response 的 HTTP Header 中增加 Last Modified 定義，其次根據 Request 中的 If Modified Since 和被請求內容的更新時間來返回 200 或者 304 。