타사 라이브러리를 분리하는 이유는 무엇입니까?

Webpack은 짜증나는 작은 도깨비입니다. 저는 항상 과잉 수용소에 있었고 패키징을 위해 browserify를 사용했습니다. webpack이 인기가 폭발적으로 증가했다는 것을 알게 되었고, 커뮤니티에서 뒤쳐질까 봐 빨리 선택해서 가지고 놀았습니다. 원래는 그냥 놀고 싶었어요. 패키징을 시도한 후 웹팩 서버를 시작한 다음 핫 교체를 추가하고, CSS 파일을 분리하고, 다양한 로더를 사용하여 패키징 결과를 처리하고 최적화하고 싶습니다. 다양한 소스 맵의 차이점은 무엇입니까? 없어진. Hot replacement를 추가할 때, 애플리케이션 서버와 웹팩 서버가 동일한 것을 사용하지 않았기 때문에 약간의 우여곡절이 있었습니다. 그러면 오늘의 주제로 들어갑니다.
오늘의 주제를 단계별로 확장해 보세요.
타사 라이브러리를 분리해야 하는 이유는 무엇인가요?
이러한 이점은 명백합니다. 타사 라이브러리는 비교적 안정적이며 쉽게 변경되지 않습니다. 브라우저 캐시를 사용한 후 사용자는 페이지를 다시 로드할 때 서버 요청을 줄여 속도를 향상하고 경험을 최적화합니다. 여러 애플리케이션(입구)의 공통 모듈을 추출하는 기능은 이와 유사하며, 공통 부분은 캐시되며, 모든 애플리케이션은 캐시된 콘텐츠를 사용하여 성능을 향상시킬 수 있습니다.
타사 라이브러리를 분리하여 브라우저를 사용하여 캐시를 변경할 수 있나요?
캐시를 사용할 수 없게 만드는 요인도 많습니다. 예를 들어, 가장 분명한 것은 분리된 라이브러리 파일을 다시 패키지할 때마다 다른 이름을 갖게 된다는 것입니다. 또 다른 예로는 백그라운드에 있는 동료들이 js 파일에 설정된 캐시 만료 시간이 0인데 0이면 캐시를 사용할 수 없다는 것입니다. 아니요, 파일이 완전히 변경되지 않은 한 수정 시간을 포함하여 완전히 변경되지 않은 한 캐시는 계속 사용되며 성능이 급상승합니다. 캐싱을 사용하려면 먼저 캐싱을 이해해야 합니다. 다음은 간략한 설명입니다.
브라우저 캐싱 메커니즘은 무엇인가요?
HTTP1.1에서 제공하는 전략은 Etag와 함께 Cache-control을 사용하는 것입니다.
Cache-control 설정 예:
'Cache-Control': 'public, max-age=600',
max-age는 만료 시간입니다. 만료되면 Etag도 확인됩니다. ETag 값: Apache에서는 ETag 값은 인덱스 노드(INode), 크기(Size) 및 마지막 수정 시간(MTime)을 해싱하여 얻습니다. 기본적으로 파일.
Etag가 동일하면 새 리소스는 요청되지 않지만 이전 파일이 사용됩니다.

CommonsChunkPlugin은 어떤 용도로 사용되나요?
말 그대로 이해하면 공개 패키지를 추출합니다. 공개 패키지는 단일 페이지 애플리케이션(단일 항목)의 라이브러리가 자신만 사용된다는 의미이므로 공개 패키지로 간주할 수 없습니다. , 오른쪽? 이 플러그인으로 추출한 공개 패키지는 패키징 시간을 절약하기 위한 것인지(비록 사소하지만 결국 쓸모가 없습니다. 라이브러리가 전혀 변경되지 않았습니다) 또는 매번 다시 패키징됩니다(Etag는 다를 수 있음). 브라우저 캐시를 활용합니다(최대 수명이 만료되면 어떻게 됩니까? 캐싱을 포기하시겠습니까?). 둘 다 좋은 해결책은 아닙니다. 최고의 솔루션 등장: DllPlugin
DllPlugin의 장점은 무엇입니까?
라이브러리 파일을 한 번만 패키징하세요. 즉, 라이브러리 파일이 변경되지 않은 한 한 번만 패키징하면 됩니다. 이렇게 하면 나중에 비즈니스 코드와 라이브러리 파일을 패키징해도 상관없습니다. 이렇게 하면 라이브러리 파일은 항상 동일한 라이브러리가 됩니다. 파일.라이브러리 파일이 변경되지 않은 한 캐시는 항상 유효합니다(Etag는 변경되지 않음). 가방을 싸고 라이브러리에 대해 잊어버리고 상쾌한 기분을 느껴보세요. 가장 간단한 사용 방법을 소개하겠습니다. 먼저 다른 webpack 구성 파일을 작성합니다. 결국 별도의 패키지 라이브러리라고 가정해 보겠습니다.
webpack.config.dll.js

const path = require('path')const webpack = require('webpack');module.exports = {
  entry: {vendor: ['react', 'react-dom', 'react-hot-loader', 'immutable', 'redux', 'react-redux', 'react-router-dom', 'redux-logger',  'redux-persist', 'redux-persist-transform-immutable', 'redux-thunk'],
  },
  output: {filename: 'js/[name].js',path: path.resolve(__dirname, 'public'),library: '[name]', // 当前Dll的所有内容都会存放在这个参数指定变量名的一个全局变量下，注意与DllPlugin的name参数保持一致
  },
  plugins: [new webpack.DllPlugin({  path: path.resolve(__dirname, 'public/manifest.json'), // 本Dll文件中各模块的索引，供DllReferencePlugin读取使用  name: '[name]',}),
  ],}

플러그를 추가하세요. 원본 구성 파일에

new webpack.DllReferencePlugin({  manifest: require('./public/manifest.json'), // 指定manifest.json  name: 'vendor',  // 当前Dll的所有内容都会存放在这个参数指定变量名的一个全局变量下，注意与DllPlugin的name参数保持一致}),

먼저 터미널을 실행하세요.

라이브러리가 변경되지 않은 한 먼저 라이브러리 파일을 패키지로 압축하세요. 나중에 이 패키지를 사용한 다음 비즈니스를 패키지하세요. 코드를 작성하면 완료됩니다.

권장 전략: webpack -p --progress --config ./webpack.config.dll.js
모든 사람은 자신의 일을 합니다.
단일 페이지 애플리케이션인 경우 DllPlugin을 사용하여 라이브러리 파일을 패키지하면 비즈니스 코드가 하나의 패키지로 패키지될 수 있습니다. 다중 페이지 애플리케이션인 경우 DllPlugin이 라이브러리 파일을 패키징한 후 개발 중에 많은 공개 비즈니스 코드가 사용될 수 있으며 언제든지 변경될 수 있습니다. 이 경우 예상되는 작업을 수행하려면 CommonsChunkPlugin을 사용해야 합니다. 그런 다음 공용 비즈니스를 추출합니다. 적어도 페이지 간 전환 시 공용 부분은 계속 캐시됩니다.

위 내용은 타사 라이브러리를 분리하는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!