정적 자원 전략, 파일 이름에 버전을 넣습니다

이름에 내용을 반영하면 캐시를 길게 둘 수 있습니다

정적 자원에서 가장 효과가 큰 전략은 파일 이름에 내용 기반 식별자를 넣는 것입니다. 내용이 바뀌면 이름이 바뀌므로, 같은 이름의 파일은 영원히 같은 내용임이 보장됩니다. 그러면 보관 시간을 1년으로 둬도 안전합니다. 1년은 8,760시간이고, 그 기간 동안 재방문 사용자는 그 파일을 다시 받지 않습니다. 이 전략의 전제는 두 가지입니다. 첫째, 빌드 과정에서 이름을 자동으로 생성해야 합니다. 손으로 버전을 붙이면 빠뜨립니다. 둘째, 그 이름을 참조하는 문서가 함께 갱신돼야 합니다. 문서는 짧게 캐시하고 자원은 길게 캐시하는 구조가 됩니다.

변경 불가 표시를 함께 보냅니다

보관 시간을 길게 두어도 브라우저가 중간에 서버에 확인하러 오는 경우가 있습니다. 사용자가 새로 고침을 하거나 브라우저가 자체 판단으로 재검증할 때입니다. 내용이 절대 바뀌지 않는다는 표시를 함께 보내면 이런 확인 요청까지 줄어듭니다. 이 표시는 이름에 식별자가 있는 자원에만 써야 합니다. 이름이 고정된 자원에 쓰면 내용을 바꿔도 사용자가 받지 못합니다. 그래서 빌드 산출물 폴더에만 이 설정을 적용하고, 그 폴더 밖의 자원에는 적용하지 않도록 경로 조건을 둡니다. 설정 뒤에는 응답 헤더를 확인해 두 값이 함께 나가는지 봅니다.

재방문 전송 절감을 계산합니다

학습용 가정으로 계산합니다. 가정값은 한 번 방문에 받는 정적 자원이 450킬로바이트이고 월 재방문이 120,000건이라고 두겠습니다. 캐시가 전혀 없으면 전송량은 54,000,000킬로바이트이고 기가바이트로는 54기가바이트입니다. 긴 캐시가 적용되면 재방문에서는 이 전송이 거의 발생하지 않습니다. 이것이 중간 계산값입니다. 최종 효과는 요금과 속도 양쪽에 나타납니다. 전송 요금이 줄고, 재방문 사용자의 화면은 네트워크 대기 없이 그려집니다. 첫 방문에는 효과가 없으므로, 첫 방문 속도는 용량 줄이기와 전송 경로로 따로 개선해야 합니다.

배포 간 참조가 끊기는 문제가 있습니다

결론을 뒤집는 조건은 배포 중 참조입니다. 문서는 새로 받았는데 그 문서가 참조하는 새 자원이 아직 배포되지 않았거나, 반대로 예전 문서가 캐시에 남아 이미 삭제된 예전 자원을 찾는 경우가 생깁니다. 그러면 화면이 깨집니다. 그래서 예전 버전의 자원을 일정 기간 함께 남겨 둡니다. 보관 기간은 문서의 캐시 시간보다 길게 잡습니다. 두 번째 조건은 폴더 정리입니다. 버전이 쌓이면 저장 용량이 늘어나므로, 보관 기간이 지난 버전을 자동으로 지우는 규칙을 둡니다. 그래서 배포 절차에 '예전 버전 보관 기간'을 숫자로 적습니다.

성능 최적화 실행 전 점검표

• 빌드에서 내용 기반 파일 이름을 자동 생성한다
• 변경 불가 표시를 빌드 산출물 경로에만 적용했다
• 예전 버전 자원을 문서 캐시 시간보다 길게 남긴다
• 보관 기간이 지난 버전을 자동으로 지우는 규칙을 두었다