브라우저 캐싱 전략을 설명할 수 있나요?

브라우저 캐싱은 한 번 받은 리소스를 로컬에 저장해 두고 재요청을 줄이는 기법입니다. HTTP 응답 헤더로 캐시 동작을 제어합니다.

강한 캐시 (Strong Cache)

서버에 묻지 않고 로컬 캐시를 바로 사용합니다. Cache-Control 헤더로 제어합니다.

• Cache-Control: max-age=31536000 — 해당 초만큼 캐시가 신선(fresh)하다고 보고 그대로 사용합니다.
• immutable — 유효 기간 동안 변하지 않음을 알려 재검증조차 생략합니다.
• no-cache — 캐시는 하되 사용 전 반드시 서버에 재검증합니다.
• no-store — 아예 캐시하지 않습니다. (민감 데이터)

조건부 요청 (재검증)

캐시가 만료되면 서버에 “바뀌었는지” 묻고, 안 바뀌었으면 304 Not Modified 로 본문 없이 응답받아 캐시를 재사용합니다.

• ETag / If-None-Match — 리소스의 해시·버전 식별자로 비교합니다.
• Last-Modified / If-Modified-Since — 마지막 수정 시각으로 비교합니다.

실전 전략

• 해시 파일명 + 긴 max-age — app.a1b2c3.js처럼 내용 기반 해시를 파일명에 넣고 max-age를 길게 줍니다. 내용이 바뀌면 파일명이 달라져 자연히 새로 받습니다(캐시 버스팅).
• HTML은 no-cache — 항상 최신을 받아 새 자산 경로를 참조하게 합니다.
• 변하지 않는 정적 자산은 immutable 로 재검증까지 생략합니다.

헤더	역할
Cache-Control	캐시 가능 여부·기간 지정
ETag	콘텐츠 식별자로 변경 여부 판별
Last-Modified	수정 시각으로 변경 여부 판별

해시가 붙은 정적 자산(app.a1b2c3.js)에 긴 max-age를 주는 캐싱 전략의 이유는?

내용이 바뀌면 파일명(해시)이 달라져 새 파일로 받게 되므로, 안 바뀐 동안은 오래 캐시해도 안전하다.파일명에 해시가 있으면 브라우저가 캐시를 절대 하지 않기 때문이다.max-age를 길게 주면 서버가 매 요청마다 304를 보내 속도가 빨라지기 때문이다.

CheckReset