緩存重載

1. webpack 熱重載的3種方式

開發階段，如果每次文件變更後，都要手動去打包build是很不方便的，通常在開發階段採用以下三種方式進行熱重載（自動編譯）

配置文件提供一個入口和一個出口，webpack根據這個來進行js的打包和編譯工作。package.json文件增加watch腳本 --watch 動態監聽文件的改變並實時打包，輸出新的文件，這樣文件多了之後速度會很慢，而且此打包方式不會熱更新，即每次webpack編譯之後，你還需要手動刷新瀏覽器。
缺點： 需手動刷新瀏覽器
優點： 自動編譯

webpack-dev-server實際上相當於啟用了一個express的Http伺服器＋調用了webpack-dev-middleware【簡單的web伺服器和實時重載】。這個Http伺服器和client使用了websocket通訊協議，原始文件做出改動後，webpack-dev-server會用webpack實時的編譯，再用webpack-dev-middleware將webpack編譯後的文件輸出到內存中。【這邊注意，最後的編譯的文件並沒有輸出到目標文件夾，都保存到了內存】（適合純前端項目，很難編寫後端服務，進行整合）

優點： 自動編譯 + 實時重新載入瀏覽器
webpack-dev-server

缺點： 需手動刷新瀏覽器 + 配置文件和插件多
優點： 自動編譯

定義了webpack.config里的entry和output的關系脈絡，webpack-dev-middleware能在此基礎上形成一個文件映射系統，每當應用程序請求一個文件。它匹配到了就把內存中緩存的對應結果以文件格式返回，反之進入下一個中間件。

因為是內存型文件系統，所以重建速度非常快，很適合於開發階段用作靜態資源伺服器；因為webpack可以把任何一種資源當作是模塊來處理，因此能向客戶端反饋各種格式的資源，所以可以替代HTTP伺服器。

三者相比：觀察模式在開發中不實用;web伺服器實用性強；webpack中間件+express使用了2個插件，2個配置文件，配置復雜

事實上，大多數 webpack 用戶用過的 webpack-dev-server 就是一個 express＋webpack-dev-middleware 的實現。

二者的區別僅在於 webpack-dev-server 是封裝好的，除了 webpack.config 和命令行參數之外，很難去做定製型開發。而 webpack-dev-middleware 是中間件，可以編寫自己的後端服務然後把它整合進來，相對而言比較靈活自由。

是一個結合webpack-dev-middleware使用的middleware，它可以實現瀏覽器的無刷新更新（hot reload），這也是webpack文檔里常說的HMR（Hot Mole Replacement）。HMR和熱載入的區別是：熱載入是刷新整個頁面。

運行方式：
1、命令行
package.json中指令加上 --hot

2、Nodejs API

熱更新熱重載
webpack-dev-server 自動打包/熱重載

2. 重載是什麼意思

重載是裝運重物時的負載。

引證解釋：

1、古時謂裝載輜重等貨物。

例句：楊伯峻註：重，重車，裝載貨物之車。

2、指裝載輜重等貨物的車輛。

例句：《宋史五行志一下》：雍熙二年冬，南康軍大雨雪，江水冰，勝重載。

3、滿載，超載。

例句：魯迅《野草死後》：一輛獨輪車從我的頭邊推過，大約是重載的。

4、指超載的車。

例句：葉聖陶《游臨潼》：一輛大車往往擠著一二十人，騾子拉著重載本來跑得很慢。

5、方型壓力開關有堅固的防腐蝕外殼，這保證了即使在重載的情況下，也有很長的使用壽命。

6、生命之舟如果缺少知識的重載，就會搖晃不停。

7、帶有資源緩存的集合服務定位器創建全局緩存，通過這種方式不能為重載的資源名正確處理組件級映射。

8、金屬碟片的抗沖擊、耐熱和化學物質耐受性能更佳，不會再重載環境中碎裂。

9、正如所預測的那樣，重載的資源名和緩存服務定位器使得代碼執行有不同的結果，它使某些組件取得錯誤的資源。

10、軋機軸承一般載荷條件是中重載荷和沖擊載荷，因此，最適用的材料為滲碳軸承鋼。

3. 如何重載瀏覽器 onload 事件後載入的資源文件

兩個最佳的性能實踐是 增添一個遠期的失效時間和增加 延遲載入資源（特別是腳本）在onload事件之後。但是這些最佳實踐的組合卻導致了用戶很難刷新資源的情況。更確切的說，點擊重載（或甚至shift+重載）並不能在irefox, chrome, Safari, android,和 iPhone中刷新這些緩存的，延遲載入的資源。
我們期待重載能帶來什麼
瀏覽器有一個緩存（或10個），那裡它保存響應的拷貝。如果用戶感覺那些緩存的結果已經陳舊，她可以點擊重載按鈕忽略緩存並刷新一切，以此保證她看到的是網站內容的最新的拷貝。在HTTP規范中我找不到任何討論重載按鈕的資料，但據我所知所有瀏覽器都有這種特性。
如果你點擊重載（或 control+R 或 command+R)，所有資源將以有條件的GET請求方式刷新(攜有是否自上次以來修改和是否不匹配的校驗)。如果伺服器響應的版本沒有變化，它會返回簡短的不含響應主體的「304 Not Modified」狀態。如果響應改變則響應「200 OK」並返回全部的響應主體。
如果你點擊shift+Reload (或r control+Reload 或 control+shift+R 或 command+shift+R)，那麼所有的資源就會用不帶校驗頭的方式刷新。由於每個響應主體都會返回，這要低效一些，但是確保了所有緩存的失真的響應都被覆蓋重寫。
最起碼，我們希望點擊重載的時候得到網站資源的最新版本而不管其失效時間，shift+重載會更積極的做到這些。
歡迎重載2.0
在Web1.0時代，資源通過HTML標簽的方式請求—IMG, SCRIPT, LINK等等。在Web2.0，資源經常被動態請求。兩個普遍的例子是非同步載入腳本（例如Google Analytics）和圖片動態獲取（例如旋轉燈籠式圖片或下方區域圖片延遲載入）。有時這些資源在窗口onload之後被請求，以使主頁能更快的渲染提供更好的用戶體驗，更好的指標等等。如果資源有一個很久以後的失效時間，瀏覽器則需要特別的智能去做正確的事情。
如果用戶以正常方式瀏覽到該頁(點擊一個link，輸入一個URL，利用一個書簽等等)而且動態的資源在緩存中，瀏覽器將使用緩存拷貝（假設失效時間仍在未來）
如果用戶重載了該頁，瀏覽器將重新獲取所有資源，包括頁面中動態載入的資源。
如果用戶重載了該頁，我想onload處理程序中載入的資源也同樣被重新獲取。這些可能是頁面基礎架構的一部分，它們應當在用戶想刷新頁面內容的時候重新獲取。
但是如果用戶重載頁面的時候，有資源在onload事件之後載入，瀏覽器在該做什麼？有些web應用通過保存數小時乃至數天的session來保持活動狀態。如果用戶重載了，所有在web應用生命期內的動態的資源會忽略cache重新獲取嗎？

一個例子：
我們看一個例子：Postonload Reload
這個頁面用五種不同的方式載入圖片與腳本：
標簽 – 基礎的HTML途徑：<img src=http://www.oschina.net/translate/和<script src=.
正文中動態 – 在頁面正文中是一個腳本塊，動態的創建一幅圖片和一段腳本，設置SRC來獲取資源。這些代碼在onload之前執行。
載入時 – 在onload處理程序中動態的創建一段腳本和一幅圖片。
載入後1 ms – 通過在onload處理程序中的1毫秒setTimeout回調，動態的創建一段腳本和一幅圖片。
載入後5秒– 通過在onload處理程序中的5秒setTimeout回調，動態的創建一段腳本和一幅圖片。
所有圖片和腳本有一個未來一個月的失效期。如果用戶點擊重載，哪一個技術會重新獲取？當然我們希望1和2可以引起重新獲取。我希望3也重新獲取。我想4應該會重新獲取但是困惑於許多瀏覽器是否能做到，還有5可能不會重新獲取。排一下你期待的結果然後看看下面的表格。
結果
在看重載的結果以前，我們看一下如果用戶只是瀏覽到該頁會發生什麼。這是通過點擊例子中「try again」鏈接實現的。在這種情況下，沒有資源被重新獲取。所有的資源都標著未來一個月失效期被存入緩存，所以我測試的瀏覽器都只是從緩存中讀出它們。這很好正如我們預期。
但是我們看下面表中捕獲的重載的結果，行為變得分化了。
Table 1. Resources that are refetched rel="nofollow">Google, YouTube, Yahoo, Microsoft Live, Tencent QQ, Amazon 和 Twitter。如果你用列出來的前四個瀏覽器，打開包嗅探器，重載這些網站的任何一個，你將看到一個奇怪的模式：可緩存的資源在onload之前載入，帶有304響應狀態，而onload之後的從緩存讀出來並不會重新獲取。唯一確保獲得最新版本的辦法是清空緩存，這使得重載按鈕的期望價值破滅了。

這里是Amazon在Chrome瀏覽器下的請求瀑布流。紅色豎線就是onload事件時刻。注意到多少資源在onload之間返回304狀態。紅線右側onload之後一些圖片不被緩存，所以被再請求返回200狀態。而可以緩存的圖片在onload之後都從緩存中讀取，因此這些資源都得不到更新。

最後，無論何時都應該仔細研究不同瀏覽器的行為到底是為什麼。經常一些行為優先於另一個，我們應該把這些特性和廠商對應起來。在重載頁面的情況時，我們應該更一致地重新載入所有資源，即使是onload事件後的動態資源。