웹 성능을 위한 웹 캐시
date
Feb 18, 2024
slug
cache
status
Published
tags
최적화
Cache
summary
type
Post
코드 블록이 보이지 않는 경우, 페이지를 새로고침해주세요.
시작하며
프론트엔드 개발 후 빌드된 결과물이 간헐적으로 반영되지 않는 경우가 있었습니다. 이러한 문제를 파악하고 해결한 사례를 공유드릴려고합니다.
파이프라인
현재 파이프라인은 빌드된 결과물을 S3에 업로드하고, 변경 사항을 반영하기 위해 CloudFront의
index.html 만을 무효화했습니다.index.html 만 무효화하는 이유는 빌드 과정에서 캐시 무효화를 위해 다른 파일 이름에 무작위 값을 포함시키기 때문입니다. 이러한 방식으로 생성된 파일은 CloudFront가 새로운 파일로 인식합니다.
따라서 index.html 을 제외한 나머지 파일들에 대해 별도의 캐시 무효화 절차가 필요하지 않습니다.임시 해결책 (와일드카드)
그럼에도 불구하고, 빌드된 결과물이 때때로 제대로 반영되지 않는 문제가 발생했습니다. 이 문제를 해결하기 위해, 와일드카드(
*)를 사용하여 CloudFront의 캐시를 전체적으로 무효화시키는 방법을 임시적으로 해결했습니다.전자의 방법은 간헐적으로 문제가 생기고, 후자의 방법은 왜 해결되었는지에 대해 최근에서야 알게되었습니다.
CDN 무효화되었음에도 불구하고,
index.html이 브라우저에 의해 캐싱되어 있어서 과거 리소스를 참조하고 있었기 때문에, 최신의 변경사항이 반영되지 않았습니다.
와일드카드(*)를 사용하여 전체 캐시를 무효화하게 되면, index.html에 참조하는 과거 리소스들이 더 이상 존재하지 않게 되어 오류를 발생시킵니다. 이 오류는 브라우저가 CDN으로부터 index.html을 다시 요청하게 만들며, 이 과정에서 최신 리소스를 불러오게 됩니다. 결과적으로 최근에 배포한 결과물이 반영되었습니다.와일드카드를 사용하여 전체 캐시를 무효화하는 방법은, 리소스가 많을 경우 비용 낭비로 이어질 수 있습니다. 이러한 경험을 통해, 브라우저 캐싱을 효과적으로 관리할 필요성을 깨닫게 되었습니다.
Cache-Control
no-store
no-store 는 브라우저나 중간 캐시(ex: CDN)에 의해 저장되지 않습니다. 따라서 항상 서버로부터 리소스를 다시 받습니다.no-cache
no-cache 는 캐시된 리소스를 사용하기 전에 항상 서버로부터 검증을 받아야 함을 의미합니다. 실제 캐시를 사용하기 전에 if-modified-since 또는 if-none-match 헤더를 사용하여 서버에 재검증을 요청해야 합니다. 서버는 리소스가 변경되었는지 확인(ex: etag, last-modified)하고, 변경되지 않았다면 304 Not Modified 응답을 보내어 리소스를 다시 받지 않도록 합니다.대부분의 브라우저에서 max-age=0 과 동일한 뜻을 가집니다.
max-age
max-age 는 리소스가 캐시될 수 있는 최대 시간(초 단위)을 지정합니다. 이 기간 동안 캐시된 리소스가 유효하며, 서버에 재검증 없이 사용될 수 있습니다.s-maxage
s-maxage 는 max-age 와 유사하게 리소스가 캐시될 수 있는 최대 시간을 지정합니다. 하지만, 브라우저의 캐시가 아닌 공유 캐시(ex: CDN)의 캐싱 정책을 제어합니다.결론
index.html 을 제외한 모든 파일을 S3에 업로드하고, max-age 를 31,536,000으로 설정하여 1년 동안 캐싱합니다.index.html 에 대해서는 max-age를 0으로 설정하여 브라우저에게 캐시하지 않거나, 캐시가 있더라도 사용하기 전에 항상 재검증하도록 합니다. s-maxage 를 31,536,000를 설정하여 공유 캐시(ex: CDN)에 대해 파일을 1년동안 캐싱합니다.CloudFront에서
index.html 에 대한 캐시를 무효화합니다. 이를 통해 업데이트된 index.html 이 사용자에게 제공되도록 보장합니다.마치며
이번 포스트를 통해 웹 캐시에 대해 살펴보았습니다. 이 글이 여러분의 프로젝트에 도움이 되기를 바랍니다. 앞으로도 유용한 정보를 공유하기 위해 노력하겠습니다.
