[Vue] SPA 캐싱 지침 관련 내용 정리

⚡ 개요

SPA로 웹 Front-end를 개발하다보면 사용자의 브라우저의 캐싱 기능때문에 빌드/배포 후에도 최신 파일의 변경사항이 적용되지 않는 경우가 있다.

강력 새로고침(ctrl + shift + F5) 기능을 이용해 이를 해결할 순 있지만 일반 사용자에게 배포 때마다 이것을 요구하는 것은 맞지 않기 때문에 개발자가 이 문제를 해결 해야한다.

 

⚡ SPA 캐싱 개념

📁 정적 리소스 캐싱 (Static Asset Caching)

• HTML, JS 번들 파일, CSS, 이미지, 폰트 등 변경되지 않는 리소스

사용자의 브라우저가 동일한 파일을 재요청하지 않아 네트워크 비용이 줄고 빠르게 렌더링 된다는 이점이 존재 한다.

정적 리소스 파일을 번들 하는 과정에서 해쉬값을 붙여서 파일 변경시에만 캐시 무효화가 가능 하다.

📁 HTML 파일 캐싱

SPA 에서 index.html 파일은 진입점으로써 매우 중요한 역활을 한다.

해당 파일은 항상 최신 상태를 유지해야 하기 때문에 캐싱 처리를 하는건 좋지 않은 방향성이라고 생각을 하고 있다.

📁 API 응답 캐싱 (Dynamic Data Caching)

js에서 백엔드 API 를 호출해서 데이터를 가져오고 있다면, 캐싱 전략이 필요 할 수도 있다.

클라이언트측에서 메모리 캐시를 통해서 관리도 가능 하고, 해당 캐싱은 데이터 특정에 따라 다르게 적용 해야 한다. 

📁 서비스 워커 기반 캐싱 (Advanced)

PWA(Progressive Web App)로 확장할 경우, 서비스 워커를 통해 네트워크 요청을 가로채고 캐시에서 제공 가능하다.

• Cache First: 먼저 캐시에서, 없으면 네트워크
• Network First: 항상 최신, 실패하면 캐시
• Stale-While-Revalidate: 캐시 즉시 제공 + 백그라운드 갱신

⚡ 캐싱 동작 방식

📁 정적 리소스 캐싱 동작 방식

1. 사용자가 http://localhost:8080/ 페이지 접속
2. index.html, main.[hash].js, style.[hash].js 등 정적 리소스 요청
3. 서버 또는 CDN이 응답에 캐시 헤더를 포함해서 전달 (응답 헤더는 상황에 맞게 설정 필요)
4. 브라우저는 해당 파일을 디스크 캐시 또는 메모리 캐시에 저장.

위의 방식으로 첫 요청 이후, 두번째 요청이 이뤄질때

브라우저는 캐싱이 되어 있다는걸 알고 있기 때문에 재요청을 하지 않고 해당 js 파일들을 그대로 사용한다.

하지만 index.html의 경우는 최신 상태를 유지해야 하기 때문에 서버에 변경 여부를 확인 요청 한다.

http 내용
HTTP/1.1 304 Not Modified

파일 내용이 변하지 않았다는 뜻으로 브라우저는 캐싱되어 있는 index.html을 재사용 한다.

 

⚡ 빌드시 정적 파일 생성 방법

빌드시 정적 파일에 hash 코드를 넣어서 파일을 만든다. 그렇게 되면 변경 사항이 있는 경우 hash 코드가 계속 바뀔것이고 브라우저에서 읽을때는 변경이 되었다고 판단하여 기존 캐시를 지우고 새로운 파일을 캐시에 담아서 저장한다.

 

index.html이 캐시가 되어 잇다고 가정 했을때, 브라우저는 해당 캐시가 만료될때까지 이 파일을 재사용 한다. 즉 index.html이 새로 고침 되기전까지는 이전 버전을 사용한다. 결론적으로 index.html은 no-cache 설정을 해서 처리 하는게 좋다고 본다.

설정을 위와 같이 하게 되면 페이지를 이동할때 마다 index.html을 다시 검증하고 갱신한다. 파일이 변경되지 않은 경우는 304로 응답하고 이전 버전을 계속 사용 가능하다.

 

⚡ header 확인 방법

HTTP/1.1 200 OK
Date: Wed, 21 Oct 2015 07:28:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Connection: keep-alive
Cache-Control: max-age=3600, must-revalidate
ETag: "123456789abcdef"
Last-Modified: Wed, 21 Oct 2015 07:20:00 GMT
Expires: Thu, 01 Dec 2022 16:00:00 GMT

📁 Cache-Control

• max-age=<seconds>: 리소스가 캐시될 최대 시간(초 단위)을 지정
• no-cache: 리소스를 사용할 때마다 서버와 유효성을 검사
• no-store: 캐시를 사용하지 않고, 리소스를 저장하지 않음
• must-revalidate: 캐시가 만료된 리소스를 다시 서버에서 받아야함.
• public: 모든 캐시가 리소스를 캐시할 수 있음을 의미
• private: 개인 캐시에만 리소스를 저장할 수 있음 (공유 캐시에서는 제외)
• Expires : 리소스가 만료되는 날짜와 시간을 특정되며 이 시점이 지나면 캐시된 리소스는 만료 되고 새로운 요청이 필요.
• Last-Modified : 리소스가 마지막으로 변경된 날짜와 시간을 알려줌
• ETag : 리소스의 고유 식별자이며, 리소스가 변경될때마다 새로운 태그가 생성됨