Webpack이 영구 캐싱을 구현하는 방법

이번에는 Webpack에서 영구 캐싱을 구현하는 방법을 보여 드리겠습니다. Webpack에서 영구 캐싱을 구현하기 위한 주의 사항은 무엇입니까? 다음은 실제 사례입니다.

머리말

최근에 webpack이 어떻게 지속적 캐싱을 하는지 살펴보았고, 여전히 몇 가지 함정이 있다는 것을 발견했습니다. 이 글을 읽고 나면 대략적으로 이해할 수 있을 것입니다.

1. 영구 캐싱이란 무엇이며 왜 영구 캐싱을 수행하나요?

2. webpack은 영구 캐싱을 어떻게 수행하나요?

3. 웹팩 캐싱에 대한 몇 가지 참고 사항입니다.

영구 캐시

먼저 현재 프런트엔드와 백엔드를 분리하는 애플리케이션이 인기를 끌고 있는 맥락에서 프런트엔드 html, css, js는 정적 리소스 파일인 경우가 많습니다. 양식은 서버에 존재하며 인터페이스를 통해 데이터를 얻어 동적 콘텐츠를 표시합니다. 여기에는 회사가 프런트 엔드 코드를 배포하는 방법에 대한 문제가 포함되므로 업데이트 배포 문제가 포함됩니다. 페이지를 먼저 배포해야 할까요, 아니면 리소스를 먼저 배포해야 할까요?

페이지를 먼저 배포한 다음 리소스 배포: 두 배포 사이의 시간 간격 동안 사용자가 페이지에 액세스하면 이전 리소스가 새 페이지 구조에 로드되고 이전 버전의 리소스가 캐시됩니다. 결과적으로 사용자는 수동으로 새로 고치지 않으면 리소스 캐시가 만료될 때까지 페이지가 무질서한 상태로 유지됩니다.

먼저 리소스 배포 후 페이지 배포: 배포 시간 간격 동안 이전 버전의 리소스에 대한 로컬 캐시가 있는 사용자가 웹 사이트를 방문합니다. 요청한 페이지는 이전 버전이고 리소스 참조는 변경되지 않았으므로 브라우저가 직접 로컬 캐시를 사용하므로 이는 정상적인 상황이지만 로컬 캐시가 없거나 캐시가 만료된 사용자가 웹 사이트를 방문하면 이전 버전 페이지에서 새 버전 리소스를 로드하여 페이지 실행 오류가 발생합니다.

따라서 온라인 코드를 업데이트할 때 온라인 사용자가 원활하게 전환하고 웹 사이트를 올바르게 열 수 있도록 보장하는 배포 전략이 필요합니다.

대기업에서 프런트 엔드 코드를 개발하고 배포하는 방법은 무엇입니까? 이 답변을 먼저 읽어 보는 것이 좋습니다.

위 답변을 읽고 나면 파일이 수정될 때마다 생성되는 해시 값이 다르기 때문에 이제 더 성숙한 영구 캐싱 솔루션은 정적 리소스 이름 뒤에 해시 값을 추가하는 것이라는 것을 대략 이해하게 될 것이며, 이것의 이점은 이전 파일을 덮어쓰고 온라인 사용자 액세스가 실패하는 것을 방지하기 위해 파일을 점진적으로 게시하는 것입니다.

매번 게시되는 정적 리소스(css, js, img)의 이름이 고유하기 때문에 다음을 수행할 수 있습니다.

1. html 파일의 경우: 캐싱을 활성화하지 않고 내 서버에 html을 넣습니다. 서버의 캐시를 끄세요. 귀하의 서버는 html 파일과 데이터 인터페이스만 제공합니다

2. 정적 js, css, 그림 및 기타 파일의 경우: cdn 및 캐시를 활성화하고, cdn 서비스 제공업체에 정적 리소스를 업로드합니다. 리소스를 수정할 수 있습니다. 장기 캐싱을 켜면 각 리소스의 경로가 고유하므로 리소스를 덮어쓰지 않아 온라인 사용자 액세스의 안정성이 보장됩니다.

3. 업데이트가 출시될 때마다 정적 리소스(js, css, img)를 먼저 cdn 서비스로 전송한 후 html 파일을 업로드합니다. 이는 기존 사용자가 정상적으로 액세스할 수 있도록 보장할 뿐만 아니라, 또한 새로운 사용자가 새 페이지에 액세스할 수 있습니다.

위에서는 주류 프런트엔드 영구 캐싱 솔루션을 간략하게 소개했는데 왜 영구 캐싱을 해야 할까요?

사용자가 브라우저를 사용하여 처음으로 사이트를 방문하면 페이지에 다양한 정적 리소스가 표시됩니다. 지속적인 캐싱을 달성할 수 있으면 http 응답 헤더에 Cache-control 또는 Expires 필드를 추가할 수 있습니다. 캐시를 사용하면 브라우저는 이러한 리소스를 로컬에서 하나씩 캐시할 수 있습니다.

사용자가 후속 방문 시 동일한 정적 리소스를 다시 요청해야 하고 정적 리소스가 만료되지 않은 경우 브라우저는 네트워크를 통해 리소스를 요청하는 대신 로컬 캐시를 직접 사용할 수 있습니다.

웹팩이 영구 캐싱을 하는 방법

영구 캐싱을 간략히 소개한 후 다음이 핵심인데, 웹팩에서 영구 캐싱을 어떻게 해야 할까요?

1. 고유성을 보장해야 할까요? 즉, 패키지된 각 리소스에 대해 고유한 해시 값을 생성합니다. 패키지된 콘텐츠가 일치하지 않는 한 해시 값도 일치하지 않습니다.

2. 해시 값의 안정성을 보장하려면 모듈이 수정될 때 영향을 받는 패키지 파일의 해시 값만 변경되고, 모듈과 관련 없는 패키지 파일의 해시 값은 변경되지 않도록 해야 합니다.

hash 파일 이름은 영구 캐싱을 구현하는 첫 번째 단계입니다. 현재 webpack에는 해시를 계산하는 두 가지 방법([hash] 및 [chunkhash])이 있습니다.

1. hash는 webpack이 컴파일 중에 매번 해시를 계산한다는 의미입니다. process 프로젝트의 파일이 변경된 후 다시 생성되는 고유한 해시 값을 생성한 다음 webpack이 새 해시 값을 계산합니다.

2. chunkhash는 모듈을 기준으로 계산된 해시 값이므로 특정 파일에 대한 변경 사항은 자체 해시 값에만 영향을 미치고 다른 파일에는 영향을 미치지 않습니다.

모든 것을 동일한 파일에 압축하면 해시가 만족스러울 수 있습니다. 프로젝트에 압축 풀기, 모듈 로드 등이 포함된 경우에는 관련 파일 해시 값만 사용해야 합니다. ​업데이트마다 변경됩니다.

영구 캐시가 포함된 웹팩 구성은 다음과 같아야 합니다.

module.exports = {
 entry: dirname + '/src/index.js',
 output: {
 path: dirname + '/dist',
 filename: '[name].[chunkhash:8].js',
 }
}

위 코드의 의미는 index.js를 진입점으로 사용하고 모든 코드를 index.xxxx라는 파일에 패키징하고 넣는 것입니다. 이제 프로젝트를 업데이트할 때마다 새로운 이름의 파일을 생성할 수 있습니다.

간단한 시나리오를 다루는 경우 이것으로 충분하지만 대규모 다중 페이지 애플리케이션에서는 페이지에서 성능 최적화를 수행해야 하는 경우가 많습니다.

1. 별도의 비즈니스 코드와 타사 코드: 이유 왜 비즈니스 코드는 자주 업데이트되고, 타사 코드는 느리게 업데이트되고 반복되기 때문에 비즈니스 코드와 타사 코드를 분리합니다. 따라서 타사 코드(라이브러리, 프레임워크)를 분리하여 브라우저의 캐시를 로드합니다.

2. 요청 시 로드: 예를 들어 React-Router를 사용할 때 사용자가 특정 경로에 액세스해야 하면 해당 구성 요소가 로드됩니다. 그러면 사용자는 처음에 모든 라우팅 구성 요소를 다운로드할 필요가 없습니다. 현지의.

3. 다중 페이지 애플리케이션에서는 머리글, 바닥글 등과 같은 공통 모듈을 추출할 수 있으므로 페이지가 이동할 때 이러한 공통 모듈은 캐시에 존재하는 대신 직접 로드될 수 있습니다. 더 이상 네트워크 요청을 하는 중입니다.

모듈을 풀고 모듈에 로드하려면 webpack에 내장된 플러그인인 CommonsChunkPlugin이 필요합니다. 아래에서는 예제를 사용하여 webpack을 구성하는 방법을 설명하겠습니다.

이 기사의 코드는 내 Github에 있습니다. 관심이 있으시면 다운로드하여 살펴볼 수 있습니다.

git clone https://github.com/happylindz/blog.git
cd blog/code/multiple-page-webpack-demo
npm install

다음 내용을 읽기 전에 이전 기사를 읽어 보시기 바랍니다: 심층적인 이해 웹팩 파일 패키징 메커니즘 및 웹팩 파일에 대한 이해 패키징 메커니즘은 영구 캐싱을 더 잘 구현하는 데 도움이 됩니다.

예제는 대략 다음과 같이 설명됩니다. 페이지A와 페이지B의 두 페이지로 구성됩니다.

// src/pageA.js
import componentA from './common/componentA';
// 使用到 jquery 第三方库，需要抽离，避免业务打包文件过大
import $ from 'jquery';
// 加载 css 文件，一部分为公共样式，一部分为独有样式，需要抽离
import './css/common.css'
import './css/pageA.css';
console.log(componentA);
console.log($.trim(' do something '));
// src/pageB.js
// 页面 A 和 B 都用到了公共模块 componentA，需要抽离，避免重复加载
import componentA from './common/componentA';
import componentB from './common/componentB';
import './css/common.css'
import './css/pageB.css';
console.log(componentA);
console.log(componentB);
// 用到异步加载模块 asyncComponent，需要抽离，加载首屏速度
document.getElementById('xxxxx').addEventListener('click', () => {
 import( /* webpackChunkName: "async" */
 './common/asyncComponent.js').then((async) => {
  async();
 })
})
// 公共模块基本长这样
export default "component X";

위의 페이지 콘텐츠에는 기본적으로 공용 라이브러리 분할, 요청 시 로드 및 공용 모듈 분할이라는 세 가지 모듈 분할 모드가 포함됩니다. 그런 다음 다음 단계는 웹팩을 구성하는 것입니다.

const path = require('path');
const webpack = require('webpack');
const ExtractTextPlugin = require('extract-text-webpack-plugin');
module.exports = {
 entry: {
 pageA: [path.resolve(dirname, './src/pageA.js')],
 pageB: path.resolve(dirname, './src/pageB.js'),
 },
 output: {
 path: path.resolve(dirname, './dist'),
 filename: 'js/[name].[chunkhash:8].js',
 chunkFilename: 'js/[name].[chunkhash:8].js'
 },
 module: {
 rules: [
  {
  // 用正则去匹配要用该 loader 转换的 CSS 文件
  test: /.css$/,
  use: ExtractTextPlugin.extract({
   fallback: "style-loader",
   use: ["css-loader"]
  }) 
  }
 ]
 },
 plugins: [
 new webpack.optimize.CommonsChunkPlugin({
  name: 'common',
  minChunks: 2,
 }),
 new webpack.optimize.CommonsChunkPlugin({
  name: 'vendor',
  minChunks: ({ resource }) => (
  resource && resource.indexOf('node_modules') >= 0 && resource.match(/.js$/)
  )
 }),
 new ExtractTextPlugin({
  filename: `css/[name].[chunkhash:8].css`,
 }),
 ]
}

첫 번째 CommonsChunkPlugin은 공용 모듈을 추출하는 데 사용됩니다. 이는 웹팩 상사에게 모듈이 두 번 이상 로드되는 것을 본다면 해당 모듈을 다음으로 옮기는 데 도움을 주세요. 공통 청크, minChunks는 2이고, 세분성은 실제 상황에 따라 모듈을 분리하는 데 사용해야 하는 횟수를 선택할 수 있습니다.

두 번째 CommonsChunkPlugin은 타사 코드를 추출하고 리소스가 node_modules에서 왔는지 확인하는 데 사용됩니다. 그렇다면 해당 모듈이 타사 모듈임을 의미합니다. 이는 node_modules 디렉터리에서 나오는 일부 모듈을 보고 해당 이름이 .js로 끝나는 경우 이를 공급업체 청크로 이동하라고 말하는 것과 같습니다. 공급업체 청크가 존재하지 않으면 새 모듈을 만드세요.

이 구성의 이점은 무엇입니까? 비즈니스가 성장함에 따라 타사 코드를 저장하기 위한 입구를 특별히 구성하면 webpack.config.js가 더 많이 사용됩니다. 다음과 같이 됩니다:

// 不利于拓展
module.exports = {
 entry: {
 app: './src/main.js',
 vendor: [
  'vue',
  'axio',
  'vue-router',
  'vuex',
  // more
 ],
 },
}

 第三个 ExtractTextPlugin 插件用于将 css 从打包好的 js 文件中抽离，生成独立的 css 文件，想象一下，当你只是修改了下样式，并没有修改页面的功能逻辑，你肯定不希望你的 js 文件 hash 值变化，你肯定是希望 css 和 js 能够相互分开，且互不影响。

运行 webpack 后可以看到打包之后的效果:

├── css
│ ├── common.2beb7387.css
│ ├── pageA.d178426d.css
│ └── pageB.33931188.css
└── js
 ├── async.03f28faf.js
 ├── common.2beb7387.js
 ├── pageA.d178426d.js
 ├── pageB.33931188.js
 └── vendor.22a1d956.js

可以看出 css 和 js 已经分离，并且我们对模块进行了拆分，保证了模块 chunk 的唯一性，当你每次更新代码的时候，会生成不一样的 hash 值。

唯一性有了，那么我们需要保证 hash 值的稳定性，试想下这样的场景，你肯定不希望你修改某部分的代码(模块，css)导致了文件的 hash 值全变了，那么显然是不明智的，那么我们去做到 hash 值变化最小化呢？

换句话说，我们就要找出 webpack 编译中会导致缓存失效的因素，想办法去解决或优化它？

影响 chunkhash 值变化主要由以下四个部分引起的：

1. 包含模块的源代码

2. webpack 用于启动运行的 runtime 代码

3. webpack 生成的模块 moduleid(包括包含模块 id 和被引用的依赖模块 id)

4. chunkID

这四部分只要有任意部分发生变化，生成的分块文件就不一样了，缓存也就会失效，下面就从四个部分一一介绍：

一、源代码变化：

显然不用多说，缓存必须要刷新，不然就有问题了

二、webpack 启动运行的 runtime 代码：

看过我之前的文章：深入理解 webpack 文件打包机制 就会知道，在 webpack 启动的时候需要执行一些启动代码。

(function(modules) {
 window["webpackJsonp"] = function webpackJsonpCallback(chunkIds, moreModules) {
 // ...
 };
 function webpack_require(moduleId) {
 // ...
 }
 webpack_require.e = function requireEnsure(chunkId, callback) {
 // ...
 script.src = webpack_require.p + "" + chunkId + "." + ({"0":"pageA","1":"pageB","3":"vendor"}[chunkId]||chunkId) + "." + {"0":"e72ce7d4","1":"69f6bbe3","2":"9adbbaa0","3":"53fa02a7"}[chunkId] + ".js";
 };
})([]);

大致内容像上面这样，它们是 webpack 的一些启动代码，它们是一些函数，告诉浏览器如何加载 webpack 定义的模块。

其中有一行代码每次更新都会改变的，因为启动代码需要清楚地知道 chunkid 和 chunkhash 值得对应关系，这样在异步加载的时候才能正确地拼接出异步 js 文件的路径。

那么这部分代码最终放在哪个文件呢？因为我们刚才配置的时候最后生成的 common chunk 模块，那么这部分运行时代码会被直接内置在里面，这就导致了，我们每次更新我们业务代码(pageA, pageB, 模块)的时候， common chunkhash 会一直变化，但是这显然不符合我们的设想，因为我们只是要用 common chunk 用来存放公共模块(这里指的是 componentA)，那么我 componentA 都没去修改，凭啥 chunkhash 需要变了。

所以我们需要将这部分 runtime 代码抽离成单独文件。

module.exports = {
 // ...
 plugins: [
 // ...
 // 放到其他的 CommonsChunkPlugin 后面
 new webpack.optimize.CommonsChunkPlugin({
  name: 'runtime',
  minChunks: Infinity,
 }),
 ]
}

这相当于是告诉 webpack 帮我把运行时代码抽离，放到单独的文件中。

├── css
│ ├── common.4cc08e4d.css
│ ├── pageA.d178426d.css
│ └── pageB.33931188.css
└── js
 ├── async.03f28faf.js
 ├── common.4cc08e4d.js
 ├── pageA.d178426d.js
 ├── pageB.33931188.js
 ├── runtime.8c79fdcd.js
 └── vendor.cef44292.js

多生成了一个 runtime.xxxx.js，以后你在改动业务代码的时候，common chunk 的 hash 值就不会变了，取而代之的是 runtime chunk hash 值会变，既然这部分代码是动态的，可以通过 chunk-manifest-webpack-plugin 将他们 inline 到 html 中，减少一次网络请求。

三、webpack 生成的模块 moduleid

在 webpack2 中默认加载 OccurrenceOrderPlugin 这个插件，OccurrenceOrderPlugin 插件会按引入次数最多的模块进行排序，引入次数的模块的 moduleId 越小，但是这仍然是不稳定的，随着你代码量的增加，虽然代码引用次数的模块 moduleId 越小，越不容易变化，但是难免还是不确定的。

默认情况下，模块的 id 是这个模块在模块数组中的索引。OccurenceOrderPlugin 会将引用次数多的模块放在前面，在每次编译时模块的顺序都是一致的，如果你修改代码时新增或删除了一些模块，这将可能会影响到所有模块的 id。

最佳实践方案是通过 HashedModuleIdsPlugin 这个插件，这个插件会根据模块的相对路径生成一个长度只有四位的字符串作为模块的 id，既隐藏了模块的路径信息，又减少了模块 id 的长度。

这样一来，改变 moduleId 的方式就只有文件路径的改变了，只要你的文件路径值不变，生成四位的字符串就不变，hash 值也不变。增加或删除业务代码模块不会对 moduleid 产生任何影响。

module.exports = {
 plugins: [
 new webpack.HashedModuleIdsPlugin(),
 // 放在最前面
 // ...
 ]
}

四、chunkID

实际情况中分块的个数的顺序在多次编译之间大多都是固定的, 不太容易发生变化。

这里涉及的只是比较基础的模块拆分，还有一些其它情况没有考虑到，比如异步加载组件中包含公共模块，可以再次将公共模块进行抽离。形成异步公共 chunk 模块。有想深入学习的可以看这篇文章：Webpack 大法之 Code Splitting

webpack 做缓存的一些注意点

1. CSS 文件 hash 值失效的问题

2. 不建议线上发布使用 DllPlugin 插件

CSS 文件 hash 值失效的问题：

ExtractTextPlugin 有个比较严重的问题，那就是它生成文件名所用的[chunkhash]是直接取自于引用该 css 代码段的 js chunk ；换句话说，如果我只是修改 css 代码段，而不动 js 代码，那么最后生成出来的 css 文件名依然没有变化。

所以我们需要将 ExtractTextPlugin 中的 chunkhash 改为 contenthash，顾名思义，contenthash 代表的是文本文件内容的 hash 值，也就是只有 style 文件的 hash 值。这样编译出来的 js 和 css 文件就有独立的 hash 值了。

module.exports = {
 plugins: [
 // ...
 new ExtractTextPlugin({
  filename: `css/[name].[contenthash:8].css`,
 }),
 ]
}

如果你使用的是 webpack2，webpack3，那么恭喜你，这样就足够了，js 文件和 css 文件修改都不会影响到相互的 hash 值。那如果你使用的是 webpack1，那么就会出现问题。

具体来讲就是 webpack1 和 webpack 在计算 chunkhash 值得不同：

webpack1 在涉及的时候并没有考虑像 ExtractTextPlugin 会将模块内容抽离的问题，所以它在计算 chunkhash 的时候是通过打包之前模块内容去计算的，也就是说在计算的时候 css 内容也包含在内，之后才将 css 内容抽离成单独的文件，

那么就会出现：如果只修改了 css 文件，未修改引用的 js 文件，那么编译输出的 js 文件的 hash 值也会改变。

对此，webpack2 做了改进，它是基于打包后文件内容来计算 hash 值的，所以是在 ExtractTextPlugin 抽离 css 代码之后，所以就不存在上述这样的问题。如果不幸的你还在使用 webpack1，那么推荐你使用 md5-hash-webpack-plugin 插件来改变 webpack 计算 hash 的策略。

不建议线上发布使用 DllPlugin 插件

为什么这么说呢？因为最近有朋友来问我，他们 leader 不让在线上用 DllPlugin 插件，来问我为什么？

DllPlugin 本身有几个缺点：

1. 首先你需要额外多配置一份 webpack 配置，增加工作量。

2. 其中一个页面用到了一个体积很大的第三方依赖库而其它页面根本不需要用到，但若直接将它打包在 dll.js 里很不值得，每次页面打开都要去加载这段无用的代码，无法使用到 webpack2 的 Code Splitting 功能。

3. 第一次打开的时候需要下载 dll 文件，因为你把很多库全部打在一起了，导致 dll 文件很大，首次进入页面加载速度很慢。

虽然你可以打包成 dll 文件，然后让浏览器去读取缓存，这样下次就不用再去请求，比如你用 lodash 其中一个函数，而你用dll会将整个 lodash 文件打进去，这就会导致你加载无用代码过多，不利于首屏渲染时间。

我认为的正确的姿势是：

1. 像 React、Vue 这样整体性偏强的库，可以生成 vendor 第三方库来去做缓存，因为你一般技术体系是固定的，一个站点里面基本上都会用到统一技术体系，所以生成 vendor 库用于缓存。

2. 像 antd、lodash 这种功能性组件库，可以通过 tree shaking 来进行消除，只保留有用的代码，千万不要直接打到 vendor 第三方库里，不然你将大量执行无用的代码。

결론

알겠습니다. 최근에 webpack을 읽으면서 정말 많은 것을 얻었던 것 같습니다. 모두가 이 글을 통해 뭔가를 얻을 수 있기를 바랍니다. 또한, 파일 캐싱 메커니즘을 이해하는 데 더 도움이 될 수 있는 이전에 쓴 기사를 다시 추천합니다. 웹팩 파일 패키징 메커니즘에 대한 심층적 이해

이 기사의 사례를 읽고 나면 방법을 마스터했다고 믿습니다. 더 흥미로운 콘텐츠를 보려면 다른 PHP 중국어 웹사이트 관련 기사를 주목하세요!

추천 자료:

일반적으로 사용되는 JS 기능 요약

Node.js 등록 이메일 활성화 방법은 무엇인가요

위 내용은 Webpack이 영구 캐싱을 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!