Caching | Webpack

시작하기, 출력 관리, 코드 스플릿팅의 예시를 사용합니다.
우리는 배포 가능한 /dist디렉터리를 생성하는 모듈형 애플리케이션을 번들링하기 위해 webpack을 사용하고 있습니다. 일단 서버에 /dist의 콘텐츠가 배포되면 클라이언트(일반적으로 브라우저)가 해당 서버에 접근하여 사이트와 애셋을 가져옵니다. 마지막 단계는 시간이 많이 걸릴 수 있기 때문에 브라우저는 캐싱이라는 기술을 사용합니다. 이렇게 하면 불필요한 네트워크 트래픽을 줄이면서 사이트를 더 빨리 로드할 수 있습니다. 그러나 새 코드를 불러올 경우에는 어려움을 느낄 수 있습니다.
이 가이드는 webpack 컴파일로 생성 된 파일의 내용이 변경되지 않는 한 캐시된 상태로 유지되도록 하는 데 필요한 설정에 초점을 맞춥니다.
output.filename substitutions 설정을 사용하여 출력 파일의 이름을 정의할 수 있습니다. Webpack은 substitutions 이라고 하는 대괄호 문자열을 사용하여 파일 이름을 템플릿화하는 방법을 제공합니다. [contenthash] substitution은 애셋의 콘텐츠에 따라 고유한 해시를 추가합니다. 애셋의 콘텐츠가 변경되면 [contenthash]도 변경됩니다.
index.html 파일을 수동으로 관리할 필요가 없도록 출력 관리의 플러그인과 시작하기의 예제를 사용하여 프로젝트를 설정해 보겠습니다.
Webpack은 output.html을 사용해 페이지를 직접 생성할 수 있습니다. Native HTML을 참고하세요. 이 가이드에서는 생성된 페이지가 내부 청크 이름으로 엔트리의 스크립트를 다시 추가하여 이 가이드에서 다루는 번들 파일 이름을 알아보기 어렵게 만들기 때문에 HtmlWebpackPlugin을 계속 사용합니다.
이 설정으로 빌드 스크립트 npm run build를 실행하면, 다음과 같은 출력이 생성됩니다.
보다시피, 번들의 이름은 해시를 통해 콘텐츠를 반영합니다. 변경하지 않고 다른 빌드를 실행하면 해당 파일 이름이 동일하게 유지될 거라고 생각합니다. 그러나 다시 실행하면 이 경우에는 그렇지 않을 수 있다는 것을 알 수 있습니다.
이것은 webpack이 특정 보일러플레이트, 특히 런타임과 매니페스트를 엔트리 청크에 포함하기 때문입니다.
현재 webpack 버전에 따라 출력이 다를 수 있습니다. 최신 버전에는 일부 이전 버전과 동일한 해싱 문제가 없을 수 있지만, 안전을 위해 다음 단계를 권장합니다.
코드 스플릿팅에서 배운 것처럼 SplitChunksPlugin을 사용하여 모듈을 별도의 번들로 분할 할 수 있습니다. Webpack은 optimization.runtimeChunk 옵션을 사용하여 런타임 코드를 별도의 청크로 분할하는 최적화 기능을 제공합니다. 모든 청크에 대해 단일 런타임 번들을 생성하려면 single로 설정합니다.
추출한 런타임 번들을 보기위해 다른 빌드를 실행해 보겠습니다.
lodash 또는 react와 같은 타사 라이브러리는 로컬 소스 코드보다 변경 될 가능성이 적기 때문에 별도의 vendor 청크로 추출하는 것도 좋은 방법입니다. 이 단계를 통해 클라이언트는 최신 상태를 유지하기 위해 서버에 더 적은 요청을 할 수 있습니다. 이는 Example 2 of SplitChunksPlugin에 표시된 SplitChunksPlugin의 cacheGroups 옵션을 사용하여 수행할 수 있습니다. cacheGroups과 함께 optimization.splitChunks를 추가하고 다음 파라미터를 사용하여 빌드합니다.
새로운 vendor번들을 확인하기 위해 다른 빌드를 실행해 보겠습니다.
이제 main 번들에 node_modules 디렉터리의 vendor 코드가 포함되어 있지 않고 크기가 240 bytes로 줄어든 것을 볼 수 있습니다!
프로젝트에 다른 모듈print.js를 추가해 보겠습니다.
다른 빌드를 실행하면 main 번들의 해시만 변경 될 것으로 예상합니다, 하지만...
... 세 가지 모두가 변경된 것을 볼 수 있습니다. 이는 각 module.id가 해석 순서에 따라 할당되기 때문입니다(optimization.moduleIds: 'natural'). webpack 5는 mode: 'none'인 경우에만 기본적으로 이 방식을 사용합니다. 해석 순서가 변경되면 ID도 변경됩니다. 요약하자면:
첫 번째와 마지막은 예상된 결과이며, 수정하고 싶은 것은 vendor 해시입니다. production 모드는 이미 optimization.moduleIds를 기본적으로 'deterministic'으로, development 모드는 'named'으로 설정하며, 두 가지 모두 빌드 간 안정적입니다. 'deterministic'을 명시적으로 설정하면 mode에 관계없이 ID가 안정적으로 유지됩니다.
이제 새로운 로컬 의존성에도 불구하고 vendor해시는 빌드간에 일관성을 유지해야합니다.
그리고 src/index.js를 수정하여 추가 의존성을 일시적으로 제거해 보겠습니다.
두 빌드 모두 55e79e5927a639d21a1b를 vendor 번들 파일 이름으로 표시한 것을 알 수 있습니다.
콘텐츠 해시는 배포할 때마다 새로운 파일명 세트를 생성하며, 이는 코드 스플리팅과 상호 작용하므로 미리 계획할 필요가 있습니다. 배포 전에 페이지를 로드한 방문자는 이전 엔트리 청크를 실행 중이며, 해당 청크는 비동기 청크의 이전 파일명을 요청합니다. 해당 파일이 서버에서 사라졌다면 import()가 거부되고 애플리케이션은 ChunkLoadError를 겪게 됩니다. 보통 탭이 열려 있는 동안 라우트 또는 지연 로드된 위젯이 실패하는 형태로 나타납니다.
이 문제의 해결은 설정이 아닌 배포 측에서 이루어집니다. 두 가지 방법으로 해결할 수 있습니다.
이전 빌드의 애셋을 유지합니다. 오래된 파일을 제공하는 비용은 크지 않으며, 배포 전에 페이지를 로드한 사람들의 오류를 없애줍니다. 디렉터리를 교체하는 대신 새 빌드를 이전 빌드 위에 복사하세요. 빌드 시 출력 디렉터리를 정리하는 경우, output.clean은 keep 조건자를 허용하며, CDN은 다음 배포 시가 아니라 하루 정도 후에 오래된 객체를 만료시킬 수 있습니다.
거부를 처리합니다. 어떤 보존 기간도 주말 내내 열려 있는 탭을 커버하지 못하므로, 실패한 청크 로드를 "이 페이지가 오래되었습니다"로 처리하고 리로드합니다.
무조건 리로드하면 청크가 다른 이유(잘못된 배포, 오프라인 사용자)로 없는 경우 루프가 발생합니다. 최대 한 번만 리로드하고(sessionStorage에 기록), 이미 "새 버전이 있습니다, 리로드하세요" 프롬프트가 있다면 그것을 대신 표시하세요.
관련 옵션: output.chunkLoadTimeout은 webpack이 거부하기 전에 기다리는 시간을 설정하고, output.crossOriginLoading은 청크가 다른 출처에서 제공될 때 불투명한 오류 대신 유용한 오류를 얻기 위해 필요합니다.
캐싱은 복잡할 수 있지만, 애플리케이션이나 사이트 사용자에게 주는 이점으로 그만한 가치가 있습니다. 자세한 내용은 아래의 추가 자료 섹션을 참고하세요.
저작권은 OpenJS Foundation 및 webpack 기여자에게 있으며, 모든 권리는 보호됩니다. OpenJS Foundation은 등록 상표를 보유하고 있으며 상표를 사용합니다. OpenJS Foundation의 상표 목록은 Trademark Policy와 Trademark List에서 확인할 수 있습니다. OpenJS Foundation 상표 목록에 표시되지 않은 상표 및 로고는 각 소유자의 상표™ 또는 등록 상표®입니다. 이를 사용한다고 해서 해당 소유자와의 제휴 관계나 보증을 의미하지는 않습니다.
The OpenJS Foundation | Terms of Use | Privacy Policy | Bylaws | Code of Conduct | Trademark Policy | Trademark List | Cookie Policy