머리말
그런 경우도 있나요?프로젝트가 온라인화 된 후 고객이 사용 중에 버그를 발견하면 서둘러 수정하여 출시합니다. 하지만 출판하고 나면
테스터나 고객은 "바꾸면 소용없다"고 말할 것이다.
당신: "캐시를 지워보세요"
고객:"????"
그래서 이 글에서는 브라우저 캐시와 브라우저 캐시를 지우는 방법을 소개하겠습니다. 더 이상 캐싱에 대해 걱정하지 마세요! !
브라우저 캐시
우리 모두 알고 있듯이 웹 페이지를 처음 열 때의 속도와 나중에 열 때의 속도는 다릅니다. 프런트 엔드에서 경로 지연 로드를 수행하지 않으면 많은 리소스가 로드됩니다. 그러나 후속 로딩은 매우 빠르며 이는 브라우저 캐싱의 이점입니다.
캐싱의 이점
- 웹페이지 로딩 속도 향상 및 응답 시간 단축
- 서버 부담 완화
- 대역폭 소비 감소
강력한 캐싱 및 협상된 캐싱
강력한 캐싱(로컬 캐시)
서버에 요청이 전송되지 않고 캐시에서 직접 리소스를 읽습니다. 두 가지 HTTP 헤더(Expires 및 Cache-Control)를 설정하여 강력한 캐싱을 구현할 수 있습니다.
- Expires 캐시 만료 시간은 리소스 만료 시간을 지정하는 데 사용되는 서버 측의 특정 시점으로,
HTTP/1의 제품으로 현지 시간으로 제한되며, 현지 시간을 수정하면 캐시가 무효화될 수 있습니다. . - Cache-Control HTTP/1.1 제품의 경우, 예를 들어 Cache-Control:max-age=300으로 설정하면 단위는 s가 되는데, 이는 5분 이내에 다시 요청하면 캐시가 강화된다는 의미입니다.
캐시 협상
리소스에 대한 브라우저의 요청이 강력한 캐시에 도달하지 않으면 서버에 요청을 보내 협상된 캐시에 도달했는지 확인합니다. 협상된 캐시에 도달하면 요청 응답에 반환되는 HTTP 상태는 304(수정되지 않음)입니다. , 요청은 엔터티 데이터를 전달하지 않습니다. 적중되지 않은 경우 200을 반환하고 리소스 엔터티 데이터를 전달합니다. 협상 캐싱은 Last-Modified, If-Modified-Since 및 ETag, If-None-Match 헤더 쌍을 사용하여 관리됩니다.
브라우저 캐시를 지우는 방법: webpack 패키징 출력 파일 이름 구성
먼저 포장 차이점 비교표를 살펴보겠습니다.
최초 패키징: 구성되지 않음
두 번째 포장: 구성되지 않음
첫 번째 포장: 구성 후
두 번째 포장: 구성 후
첨부된 내용은 주요 구성 코드입니다.
const {
defineConfig } = require('@vue/cli-service')
const timestamp = new Date().getTime()
module.exports = defineConfig({
configureWebpack: {
output: {
// 修改输出js目录名及文件名
filename: `js/[name]-test-${
timestamp}.js`,
chunkFilename: `js/[name]-test-${
timestamp}.js`,
},
},
})
요약하다
설정되지 않은 webpack의 출력 파일명은 패키징할 때마다 동일하므로 브라우저 캐시는 여전히 이전 js 파일이라고 생각하고 캐시에서 직접 얻어오는 것을 알 수 있습니다. 프로젝트의 패키지 출력 파일 이름은 여전히 동일합니다. 매우 필요합니다. 릴리스 후 캐싱 문제를 제거하는 가장 효과적인 방법입니다. 구성 원칙을 알고 나면 Vite 구성 원칙은 동일합니다. 구성을 확인하십시오. 스스로.