캐시 헤더, max-age와 재검증을 나눠 씁니다

신선도와 재검증은 다른 설정입니다

캐시 헤더를 하나의 설정으로 보면 동작을 예측할 수 없습니다. 두 개념으로 나눠야 합니다. 첫째는 신선도입니다. 지정한 시간 동안은 브라우저가 서버에 묻지 않고 저장된 응답을 그대로 씁니다. 둘째는 재검증입니다. 신선도가 끝난 뒤 서버에 '바뀌었나요'라고 묻고, 바뀌지 않았으면 내용 없이 '그대로'라는 응답만 받습니다. 두 설정의 효과가 다릅니다. 신선도는 요청 자체를 없애고, 재검증은 요청은 하되 본문 전송을 없앱니다. 그래서 자주 바뀌지 않는 자원은 신선도를 길게, 바뀔 수 있는 자원은 재검증을 쓰는 것이 기본입니다.

자원 종류별로 표를 만들어 적용합니다

설정을 자원 종류별로 정리하면 실수가 줄어듭니다. 이름에 식별자가 붙은 정적 파일은 내용이 바뀌면 이름이 바뀌므로 신선도를 아주 길게 두어도 안전합니다. 이름이 고정된 진입 문서는 짧게 두고 재검증을 붙입니다. 자주 바뀌는 데이터 응답은 짧은 신선도에 재검증을 함께 둡니다. 개인별 응답은 공용 저장을 금지하고 브라우저에만 저장하거나 아예 저장하지 않습니다. 자원 종류 4개를 한 표로 적어 두면 새 자원이 생길 때 어느 줄에 해당하는지만 정하면 됩니다. 표가 없으면 자원마다 매번 결정하게 되고, 결국 가장 보수적인 설정으로 통일됩니다. 표는 분기 1회, 자원 종류가 늘어난 시점에 갱신합니다.

재검증이 줄이는 전송량을 계산합니다

학습용 가정으로 계산합니다. 가정값은 파일 하나가 300킬로바이트이고 월 100,000번 요청되며, 재검증 응답은 0.3킬로바이트라고 두겠습니다. 캐시가 전혀 없으면 전송량은 30,000,000킬로바이트이고 기가바이트로는 30기가바이트입니다. 재검증으로 처리되면 30,000킬로바이트, 즉 0.03기가바이트입니다. 중간 계산값으로 전송량이 1,000분의 1 수준으로 줄어듭니다. 최종 효과에는 응답 시간 개선이 더해집니다. 본문을 받지 않으므로 사용자는 거의 즉시 다음 단계로 넘어갑니다. 신선도를 길게 두면 요청 자체가 사라져 이보다 더 줄어듭니다.

긴 신선도는 되돌리기 어렵습니다

결론을 뒤집는 조건은 되돌림입니다. 이름이 고정된 자원에 긴 신선도를 지정하면, 잘못된 파일을 올렸을 때 이미 저장된 브라우저에는 그 파일이 지정 기간 내내 남습니다. 서버를 고쳐도 사용자는 예전 파일을 봅니다. 그래서 긴 신선도는 이름에 식별자가 있는 자원에만 적용합니다. 두 번째 조건은 중간 캐시입니다. 회사 네트워크나 전송 서비스가 응답을 저장할 수 있으므로, 개인별 응답에 공용 저장을 금지하는 지시를 빼면 다른 사용자에게 노출될 수 있습니다. 그래서 자원 표에 '공용 저장 허용 여부' 열을 반드시 둡니다.

성능 최적화 실행 전 점검표

• 신선도와 재검증을 구분해 설정했다
• 자원 종류별 설정 표를 만들었다
• 긴 신선도는 이름에 식별자가 있는 자원에만 적용했다
• 개인별 응답에 공용 저장 금지를 지정했다