前端性能優化之http緩存

前不久，公司前端開會，領導抽問了4個問題，前3個簡單大家都答起來了，第4個問題關於緩存的這方面我只是了解，結果剛好問到我了（會的不問，專門挑我不熟悉的問，我這運氣真是沒話說），20多個前端看着我，答得不是很好，感覺很臊皮，遂重新研究並記錄下成果。

講下緩存以及200 form cache 和304的區別

如果每次都要求用戶從服務器獲取數據，那么速度和流量勢必有問題，所以就需要http緩存來解決了。如果文件沒有更新就用緩存起來的原文件。
緩存分為強緩存和協商緩存
強緩存是指不問服務器這個文件有沒有更新，只要在緩存時間范圍內，就使用緩存的文件，這時network上顯示200 form cache，
有2個屬性控制強緩存，Expires和Cache-Control: max-age，Expires是http 1.0定義的，使用的是相對時間，如果2邊與服務器時間不統一就會出現問題，為了解決這個問題於是就出現了http 1.1定義的Cache-Control: max-age，這個屬性使用的是相對時間，一般來說都是2個都加，然后取相對時間屬性。
協商緩存是先向服務器詢問下是否文件有更新，根據服務器的提示來決定是否使用緩存，由於比強緩存多了去服務器詢問這一步所以勢必沒有強緩存快。
協商緩存也有2對屬性，分別是ETag和If-None-Match，Last-Modified和If-Modified-Since，每次請求的時候，瀏覽器會保存獲取的ETag和Last-Modified，下次在調的時候會傳If-None-Match和If-Modified-Since過去，值就是上次獲取ETag和Last-Modified的值，然后根據返回的值是否有變化來決定是否取緩存的數據，Last-Modified是用時間來判斷，ETag用標識符，之所以出現2個是因為Last-Modified只能精確到秒，如果1秒內有多次數據調用，它就無能為力了，所以出現了進階的ETag，使用協商緩存的時候status顯示的是304

工作中nginx+vue@cli3+緩存優化

工作中正常情況下除了html其余資源都使用強緩存，html使用協商緩存，當打包重新構建的時候，html使用協商緩存會發現html變了，然后從服務器讀取新的html，由於打包后html引用的文件hash值不一樣，就會重新加載新的各種文件，但是通過查看hash值發現，

1 沒有任何文件改動，app.js的hash值都會改變
2 明明改動的只有js文件，但app.js和app.css的hash都會改變
hash變了就意味着會重新加載，但是文件明明沒有變化，為什么要改變hash值，讓某些文件白白多加載一次呢，
查找資料發現，HashedModuleIdsPlugin可以解決你的問題

configureWebpack: config => {
    return {
      plugins: [
        new webpack.DllReferencePlugin({
          context: process.cwd(),
          manifest: require('./public/vendor/vendor-manifest.json')
        }),
        // 在控制台中輸出可讀的模塊名
        new webpack.NamedModulesPlugin(),
        // 不做改動hash保持不變
        new webpack.HashedModuleIdsPlugin()
       
      ]
    }
  },

還有一點很有趣的是假如你想試着把html也設成強緩存（配置nginx來設置緩存時間），刷新瀏覽器頁面，你會發現html還是304，查看頭部，發現Expires和Cache-Control: max-age這2個都有，但是為什么還是304呢，網上也沒有講這個的，后面瞎折騰發現，網頁新起一個標簽頁，然后輸入你的網頁，第一次是用的強緩存，后面就是304了，雖然這點沒什么用。。。