若是不會被重複加載,機制是什麼?
這個問題其實就是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,從而大大的下降帶寬的消耗,提升用戶體驗。html
這裏的講下304狀態碼。304狀態碼錶示客戶端有緩衝的文檔併發出了一個條件性的請求(通常是提供If-Modified-Since頭表示客戶只想比指定日期更新的文檔)。若是客戶端在請求一個文件的時候,發現本身緩存的文件有 Last Modified ,那麼在請求中會包含 If Modified Since ,這個時間就是緩存文件的 Last Modified 。服務器只要判斷這個時間和當前請求的文件的修改時間就能夠肯定是返回 304 仍是 200 。對於靜態文件,例如:CSS、圖片,服務器會自動完成 Last Modified 和 If Modified Since 的比較,完成緩存或者更新。web
還有一種狀況:
對於動態頁面,就是動態產生的頁面,每每沒有包含 Last Modified 信息,這樣瀏覽器、網關等都不會作緩存,也就是在每次請求的時候都完成一個 200 的請求。所以,對於動態頁面作緩存加速,首先要在 Response 的 HTTP Header 中增長 Last Modified 定義,其次根據 Request 中的 If Modified Since 和被請求內容的更新時間來返回 200 或者 304 。瀏覽器