CDN 캐시, 빨라지는 페이지와 저장하면 안 되는 응답

공유해도 되는 응답부터 캐시합니다

CDN 캐시는 여러 사용자에게 같은 내용을 전달할 수 있는 응답부터 적용하는 것이 좋습니다. 이미지와 정적 파일, 공개 콘텐츠와 로그인 이후 화면을 구분합니다. Cloudflare 공식 문서는 기본 동작에서 HTML과 JSON을 캐시하지 않는다고 안내합니다. 따라서 CDN을 연결했다는 이유만으로 모든 페이지가 저장되었다고 가정하지 않습니다. 1단계로 경로별 콘텐츠 성격과 갱신 주기, 사용자별 차이를 적습니다. 개인 정보가 들어간 응답이나 장바구니를 잘못 공유하면 성능 문제가 아니라 데이터 노출 문제가 될 수 있습니다. 캐시를 늘리기 전에 어떤 응답이 공용인지와 어떤 조건에서 달라지는지부터 명확히 정의합니다.

캐시 키와 쿠키가 저장 범위를 바꿉니다

2단계에서는 같은 주소로 보이는 요청이 실제로 어떤 키로 구분되는지 확인합니다. 쿼리 문자열, 쿠키, 헤더와 설정에 따라 저장 대상이 나뉘거나 우회될 수 있습니다. 분석 도구에서 캐시 상태를 보며 왜 원본으로 돌아갔는지 조사합니다. URL마다 의미 없는 추적값이 붙어 저장이 쪼개지는 경우와 사용자별 응답을 의도적으로 분리하는 경우는 다르게 처리해야 합니다. 적중률을 높이려고 모든 차이를 무시하면 틀린 응답을 전달할 수 있습니다. 원본의 캐시 관련 응답 헤더와 CDN 규칙을 함께 읽고 어느 설정이 적용되는지 확인합니다. 배포 뒤 파일 이름을 바꾸는 방식도 콘텐츠 갱신을 예측 가능하게 만드는 선택지입니다.

요청 절감과 데이터 절감을 따로 계산합니다

가정으로 공개 이미지 요청 1,000건 중 800건을 캐시가 처리했다면 요청 수 기준 적중률은 800÷1,000×100=80%입니다. 원본으로 향한 요청은 200건입니다. 하지만 모든 파일 크기가 같다는 가정이 없으면 원본 데이터 전송량도 80% 줄었다고 말할 수 없습니다. 캐시에 적중하지 않은 200건이 큰 파일이라면 바이트 기준 효과가 작을 수 있습니다. 이 수치는 실제 사이트의 측정 결과가 아닙니다. 독자는 요청 수 적중률 옆에 원본 전송 바이트와 파일 크기 분포를 같이 기록합니다. 비용과 속도 개선의 최종 판단에는 이 두 지표에 더해 사용자 위치와 원본 응답 시간을 함께 사용해야 합니다.

갱신과 장애 때의 동작까지 시험합니다

3단계에서는 콘텐츠를 수정한 뒤 어떤 시점에 새 내용이 전달되는지 시험합니다. 브라우저 캐시와 CDN 캐시는 별개이므로 원본이나 CDN만 갱신해도 이전 내용이 남을 수 있습니다. 오래 캐시하는 파일은 버전이 포함된 이름을 쓰는 방식 등을 검토하고, 공개 HTML은 서비스의 갱신 요구에 맞는 정책을 정합니다. 전체 캐시 삭제를 반복하면 원본 요청이 한꺼번에 늘 수 있으므로 가능한 경우 필요한 범위만 갱신합니다. 장애 중 오래된 응답을 제공하는 기능을 사용한다면 내용의 유효성이 유지되는지도 판단해야 합니다. 최종적으로 로그인·비로그인, 새 콘텐츠·기존 콘텐츠, 정상 원본·오류 원본의 조합을 시험하고 결과를 기록합니다.

성능 최적화 실행 전 점검표

• 공유 가능한 응답을 분류했다
• 쿠키와 쿼리의 의미를 확인했다
• 요청과 바이트 적중률을 구분했다
• 수정·장애 상황의 갱신을 시험했다