webpack缓存

缓存

缓存如何工作

1.当缓存客户端需要访问数据时，它首先检查缓存。当在缓存中找到所请求的数据时，它被称为缓存命中。

2.如果在缓存中找不到请求的数据 ， 称为缓存未命中的情况，它将从主存储器中提取并复制到缓存中。如何完成此操作以及从缓存中弹出哪些数据以便为新数据腾出空间取决于系统使用的缓存算法或策略。

web中的缓存

1. 使用浏览器缓存来提高经常访问的网页的性能。当您访问网页时，请求的文件将存储在浏览器缓存中的计算存储中。

2. 单击返回并返回上一页使您的浏览器能够从缓存中检索所需的大多数文件，而不是从web服务器中重新发送它们。这种方法称为读缓存。浏览器可以比从网页重新读取文件更快地从浏览器缓存中读取数据。

web缓存的优势

web内容可以缓存在客户端、代理服务器以及服务器端。研究表明，缓存技术可以显著地提高www性能，它可以带来以下好处：
（1）减少网络流量，从而减轻拥塞。
（2）降低客户访问延迟，其主要原因有：①缓存在代理服务器中的内容，客户可以直接从代理获取而不是从远程服务器获取，从而减小了传输延迟②没有被缓存的内容由于网络拥塞及服务器负载的减轻而可以较快地被客户获取。
（3）由于客户的部分请求内容可以从代理处获取，从而减轻了远程服务器负载。
（4）如果由于远程服务器故障或者网络故障造成远程服务器无法响应客户的请求，客户可以从代理中获取缓存的内容副本，使得www服务的鲁棒性得到了加强。

web缓存的问题

web缓存系统也会带来以下问题：
（1）客户通过代理获取的可能是过时的内容。
（2）如果发生缓存失效，客户的访问延迟由于额外的代理处理开销而增加。因此在设计web缓存系统时，应力求做到cache命中率最大化和失效代价最小化。
（3）代理可能成为瓶颈。因此应为一个代理设定一个服务客户数量上限及一个服务效率下限，使得一个代理系统的效率至少同客户直接和远程服务器相连的效率一样。

webpack缓存原理

可以通过命中缓存，以降低网络流量，使网站加载速度更快，然而，如果我们在部署新版本时不更改资源的文件名，浏览器可能会认为它没有被更新，就会使用它的缓存版本。由于缓存的存在，当你需要获取新的代码时，就会显得很棘手。通过必要的配置，以确保 webpack 编译生成的文件能够被客户端缓存，而在文件内容变化后，能够请求到新的文件。

1.第一步output.filename确保浏览器能够获取到修改后的文件，原理是[chunkhash]算法，这样做是有问题的，这是由于webpack内部的chunk变化引起的

  const path = require('path');
  const cleanwebpackplugin = require('clean-webpack-plugin');
  const htmlwebpackplugin = require('html-webpack-plugin');

  module.exports = {
    entry: './src/index.js',
    plugins: [
      new cleanwebpackplugin(['dist']),
      new htmlwebpackplugin({
-       title: 'output management'
+       title: 'caching'
      })
    ],
    output: {
-     filename: 'bundle.js',
+     filename: '[name].[chunkhash].js',
      path: path.resolve(__dirname, 'dist')
    }
  };

2.通过提取模版(extracting boilerplate)将 webpack 的样板(boilerplate)和 manifest 提取出来。分离到单独的文件中。这样多次构建manifest文件都不会产生变化，以此来提高缓存命中率，我们还可以将vendor第三方包也打包到单独的文件中来提高命中率，但是hash还是变化了，不着急

const path = require('path');
+ const webpack = require('webpack');
  const cleanwebpackplugin = require('clean-webpack-plugin');
  const htmlwebpackplugin = require('html-webpack-plugin');

  module.exports = {
    entry: './src/index.js',
    plugins: [
      new cleanwebpackplugin(['dist']),
      new htmlwebpackplugin({
        title: 'caching'
-     })
+     }),
+     new webpack.optimize.commonschunkplugin({
+       name: 'manifest'
+     })
    ],
    output: {
      filename: '[name].[chunkhash].js',
      path: path.resolve(__dirname, 'dist')
    }
  };
  
3.将第三方库(library)（例如 lodash 或 react）提取到单独的 vendor chunk 文件中，是比较推荐的做法，这是因为，它们很少像本地的源代码那样频繁修改。因此通过实现以上步骤，利用客户端的长效缓存机制，可以通过命中缓存来消除请求，并减少向服务器获取资源，同时还能保证客户端代码和服务器端代码版本一致。这可以通过使用新的 entry(入口) 起点，以及再额外配置一个 commonschunkplugin 实例的组合方式来实现：

 var path = require('path');
  const webpack = require('webpack');
  const cleanwebpackplugin = require('clean-webpack-plugin');
  const htmlwebpackplugin = require('html-webpack-plugin');

  module.exports = {
-   entry: './src/index.js',
+   entry: {
+     main: './src/index.js',
+     vendor: [
+       'lodash'
+     ]
+   },
    plugins: [
      new cleanwebpackplugin(['dist']),
      new htmlwebpackplugin({
        title: 'caching'
      }),
+     new webpack.optimize.commonschunkplugin({
+       name: 'vendor'
+     }),
      new webpack.optimize.commonschunkplugin({
        name: 'manifest'
      })
    ],
    output: {
      filename: '[name].[chunkhash].js',
      path: path.resolve(__dirname, 'dist')
    }
  };

模块标识符(module identifiers)

每个 module.id 会基于默认的解析顺序(resolve order)进行增量。也就是说，当解析顺序发生变化，id 也会随之改变。

当前模块的 id。module.id === require.resolve("./file.js")

由于修改了module.id的值，vendor分配到的id也发生了变化

main bundle 会随着自身的新增内容的修改，而发生变化。
vendor bundle 会随着自身的 module.id 的修改，而发生变化。
manifest bundle 会因为当前包含一个新模块的引用，而发生变化。

修改文件前id增量变化
   [1] ./src/index.js 336 bytes {1} [built]
   [2] (webpack)/buildin/global.js 509 bytes {0} [built]
   [3] (webpack)/buildin/module.js 517 bytes {0} [built]
  == [4] multi lodash 28 bytes {0} [built]==
修改文件后id增量变化，发现lodash解析顺序变化了，4变成了5
   [1] ./src/index.js 421 bytes {1} [built]
   [2] (webpack)/buildin/global.js 509 bytes {0} [built]
   [3] (webpack)/buildin/module.js 517 bytes {0} [built]
   [4] ./src/print.js 62 bytes {1} [built]
   ==[5] multi lodash 28 bytes {0} [built]==
   


可以使用两个插件来解决这个问题。第一个插件是 namedmodulesplugin，将使用模块的路径，而不是数字标识符。虽然此插件有助于在开发过程中输出结果的可读性，然而执行时间会长一些。第二个选择是使用 hashedmoduleidsplugin，推荐用于生产环境构建：

 const path = require('path');
  const webpack = require('webpack');
  const cleanwebpackplugin = require('clean-webpack-plugin');
  const htmlwebpackplugin = require('html-webpack-plugin');

  module.exports = {
    entry: {
      main: './src/index.js',
      vendor: [
        'lodash'
      ]
    },
    plugins: [
      new cleanwebpackplugin(['dist']),
      new htmlwebpackplugin({
        title: 'caching'
      }),
+     new webpack.hashedmoduleidsplugin(),
      new webpack.optimize.commonschunkplugin({
        name: 'vendor'
      }),
      new webpack.optimize.commonschunkplugin({
        name: 'manifest'
      })
    ],
    output: {
      filename: '[name].[chunkhash].js',
      path: path.resolve(__dirname, 'dist')
    }
  };

修改前: 修改前,后完全保持一致
  [3di9] ./src/print.js 62 bytes {1} [built]
  [3irh] (webpack)/buildin/module.js 517 bytes {0} [built]
  [dur2] (webpack)/buildin/global.js 509 bytes {0} [built]
   ==[0] multi lodash 28 bytes {0} [built]==
  [lvk7] ./src/index.js 421 bytes {1} [built]
  
修改后:
  [3irh] (webpack)/buildin/module.js 517 bytes {0} [built]
  [dur2] (webpack)/buildin/global.js 509 bytes {0} [built]
  == [0] multi lodash 28 bytes {0} [built]==
  [lvk7] ./src/index.js 427 bytes {1} [built]