엣지와 브라우저 캐시, 두 단계로 나눠 설정합니다

엣지 보관과 브라우저 보관은 따로 정합니다

캐시 시간을 하나로 생각하면 갱신 속도를 조절할 수 없습니다. 보관 위치가 두 곳이기 때문입니다. 첫째는 사용자 가까운 지점의 저장소이고, 둘째는 사용자 브라우저입니다. 두 곳의 시간을 다르게 둘 수 있고, 그 조합이 갱신 특성을 정합니다. 엣지를 길게 두고 브라우저를 짧게 두면, 내용을 바꿀 때 엣지만 지우면 거의 즉시 반영됩니다. 브라우저에 남은 응답은 짧은 시간 뒤 다시 확인하러 오기 때문입니다. 반대로 브라우저를 길게 두면 우리가 통제할 수 없는 기간이 생깁니다. 그래서 통제권을 유지하려면 브라우저 쪽을 짧게 둡니다.

두 값을 조합하는 기본 규칙

실무에서 쓰는 조합은 세 가지입니다. 첫째, 이름에 식별자가 있는 정적 자원은 양쪽을 모두 아주 길게 둡니다. 내용이 바뀌면 주소가 바뀌므로 위험이 없습니다. 둘째, 공개 문서는 엣지를 길게, 브라우저를 짧게 둡니다. 수정 시 엣지만 지우면 되므로 갱신이 빠릅니다. 셋째, 자주 바뀌는 데이터 응답은 양쪽을 짧게 두고 재검증을 함께 씁니다. 개인별 응답은 엣지 저장을 금지하고 브라우저만 허용하거나 아예 저장하지 않습니다. 이 네 줄을 자원 표에 적어 두면 새 자원이 생길 때 어느 줄인지만 고르면 됩니다.

갱신 반영 차이를 계산합니다

학습용 가정으로 계산합니다. 가정값은 엣지 보관을 604,800초, 브라우저 보관을 600초로 둔다고 하겠습니다. 엣지 보관은 86,400으로 나누면 7일이고, 브라우저 보관은 60으로 나누면 10분입니다. 두 값의 비는 604,800을 600으로 나눈 1,008배입니다. 이것이 중간 계산값입니다. 최종 판단은 반영 속도로 합니다. 내용을 바꾸고 엣지를 지우면 새 요청은 즉시 새 내용을 받고, 이미 브라우저에 저장한 사용자도 최대 10분 뒤에는 새 내용을 봅니다. 만약 브라우저 보관도 7일로 두었다면 최대 7일 동안 예전 내용이 남습니다.

엣지 설정이 헤더를 덮어쓰는 경우

결론을 뒤집는 조건은 설정 우선순위입니다. 전송 서비스 쪽 규칙이 원본이 보낸 헤더보다 우선하도록 구성된 경우, 헤더를 올바르게 보냈는데도 보관 시간이 다르게 적용됩니다. 그래서 설정 뒤에는 실제 응답을 받아 두 값이 의도대로인지 확인해야 합니다. 확인 방법은 응답 헤더에서 보관 시간과 적중 상태를 함께 보는 것입니다. 두 번째 조건은 기본 동작입니다. 서비스가 기본적으로 캐시하지 않는 응답 종류가 있어, 헤더를 길게 지정해도 저장되지 않을 수 있습니다. 그래서 자원 표에 '기본 캐시 대상 여부' 열을 두고 예외는 규칙으로 명시합니다.

성능 최적화 실행 전 점검표

• 엣지 보관과 브라우저 보관 시간을 따로 지정했다
• 자원 종류별 조합 표를 만들었다
• 브라우저 보관을 짧게 두어 통제권을 유지했다
• 실제 응답 헤더로 두 값과 적중 상태를 확인했다