서비스 워커 캐시 및 HTTP 캐시 레이어 전반에서 일관성 있는 만료 로직이나 다른 만료 로직을 사용할 경우의 장단점
서비스 워커와 PWA가 최신 웹 애플리케이션의 표준이 되고 있는 동안, 리소스 캐싱은 그 어느 때보다도 복잡해졌습니다. 이 문서에서는 브라우저 캐싱에 관해 개략적으로 다룹니다. 포함:
- 서비스 워커 캐싱과 HTTP 캐싱의 사용 사례와 차이점
- 일반적인 서비스 워커와 비교했을 때 다양한 서비스 워커 캐싱 만료 전략의 장단점 HTTP 캐싱 전략
캐싱 흐름 개요
상위 수준에서 브라우저는 리소스를 요청할 때 아래의 캐싱 순서를 따릅니다.
- 서비스 워커 캐시: 서비스 워커는 리소스가 해당 캐시에 있는지 확인하고 프로그래밍된 캐싱 전략에 따라 리소스 자체를 반환할지 여부를 결정합니다. 참고 자동적으로 발생하지는 않는다는 점을 기억하세요 다음 위치에 가져오기 이벤트 핸들러를 만들어야 합니다. 네트워크 요청을 가로채서 서비스로부터 요청을 제공 작업자의 캐시를 삭제합니다.
- HTTP 캐시 (브라우저 캐시라고도 함): 리소스가 HTTP 캐시되고 아직 만료되지 않은 경우 브라우저는 자동으로 리소스를 삭제합니다.
- 서버측: 서비스 워커 캐시나 HTTP 캐시에 아무것도 발견되지 않은 경우 브라우저가 네트워크로 이동하여 리소스를 요청합니다. 리소스가 CDN에 캐시되지 않은 경우 원본 서버로 돌아가야 합니다.
캐싱 레이어
서비스 워커 캐싱
서비스 워커는 네트워크 유형의 HTTP 요청을 가로채고 캐싱 전략 브라우저에 반환해야 하는 리소스를 결정합니다. 서비스 워커 캐시와 HTTP는 캐시는 동일한 범용 기능을 제공하지만 서비스 워커 캐시는 더 많은 캐싱 기능을 제공하므로 정확히 캐시되는 내용과 캐싱이 수행되는 방식에 대한 세밀한 제어 등 다양한 기술을 사용할 수 있습니다.
서비스 워커 캐시 제어
서비스 워커는 다음 이벤트를 사용하여 HTTP 요청을 가로챕니다.
리스너 (일반적으로 fetch 이벤트)를 호출합니다. 이
코드 스니펫은
캐시 우선
캐싱 전략입니다.
Workbox를 사용하여 시간이 많이 듭니다. 예를 들어 정규식 코드 한 줄로 리소스 URL 경로를 등록할 수 있습니다.
import {registerRoute} from 'workbox-routing';
registerRoute(new RegExp('styles/.*\\.css'), callbackHandler);
서비스 워커 캐싱 전략 및 사용 사례
다음 표에는 일반적인 서비스 워커 캐싱 전략과 각 전략이 유용한 경우에 대한 개요가 나와 있습니다.
| 전략 | 최신성 근거 | 사용 사례 |
|---|---|---|
| 네트워크 전용 | 콘텐츠는 항상 최신 상태여야 합니다. |
|
| 네트워크 캐시로 대체 | 최신 콘텐츠를 제공하는 것이 좋습니다. 그러나 네트워크가 실패하거나 불안정한 경우에는 허용됩니다. |
|
| 재검증 중 비활성 | 캐시된 콘텐츠를 즉시 제공하는 것은 괜찮지만 업데이트된 캐시된 콘텐츠는 있습니다. |
|
| 먼저 캐시하고 네트워크로 대체 | 콘텐츠는 중요하지 않으며 성능 향상을 위해 캐시에서 제공할 수 있지만 서비스 워커는 때때로 업데이트를 확인해야 합니다. |
|
| 캐시 전용 | 콘텐츠가 거의 변경되지 않습니다. |
|
서비스 워커 캐싱의 추가 이점
서비스 워커 캐싱은 캐싱 로직에 대한 세밀한 제어 외에도 다음과 같은 기능도 제공합니다.
- 원본에 추가 메모리 및 저장공간: 브라우저가 HTTP 캐시를 할당합니다. 원본 단위로 리소스를 생성할 수 있습니다 기타 다시 말해, 하위 도메인이 여러 개 있다면 모두 동일한 HTTP 캐시를 공유합니다. 없음 원본/도메인의 콘텐츠가 HTTP 캐시에 오랫동안 유지되도록 보장합니다. 대상 예를 들어 사용자가 브라우저의 설정 UI에서 수동으로 정리하여 캐시를 삭제할 수 있습니다. 하드 새로고침을 트리거하는 경우 서비스 워커 캐시를 사용하면 캐시될 가능성을 높일 수 있습니다 자세한 내용은 영구 스토리지를 참조하세요.
- 불안정한 네트워크 또는 오프라인 환경에서 유연성 향상: 리소스가 캐시되는지 여부 중 하나만 선택할 수 있습니다. 서비스 워커 캐싱 사용 작은 '문제'를 완화할 수 있으며 ('stale-while-revalidate' 전략 사용)로 훨씬 더 쉽습니다. 완전한 오프라인 경험을 제공하거나('캐시 전용' 전략 사용) 예를 들어 사용자 지정된 UI가 서비스 워커 캐시에서 비롯되고 해당하는 경우 일부 요소가 제외됩니다('Set catch 핸들러' 전략 사용).
HTTP 캐싱
브라우저는 웹페이지와 관련 리소스를 처음 로드할 때 이러한 리소스를 HTTP 캐시 HTTP 캐시는 사용 설정되어 있지 않은 한 일반적으로 브라우저에서 자동으로 명시적으로 사용 중지할 수 있습니다
HTTP 캐싱을 사용하는 것은 서버에서 리소스를 캐시하는 시점과 long입니다.
HTTP 응답 헤더로 HTTP 캐시 만료 제어
서버가 리소스에 대한 브라우저 요청에 응답할 때 서버는 HTTP 응답 헤더를 사용하여 브라우저에 리소스를 캐시하는 기간을 알려줍니다. 응답 헤더: 웹 구성을 참조하세요. 서버를 참조하세요.
HTTP 캐싱 전략 및 사용 사례
HTTP 캐싱은 서비스 워커 캐싱보다 훨씬 간단합니다. HTTP 캐싱은 시간 기반 (TTL) 리소스 만료 로직. 자세한 내용은 어떤 응답 헤더 값을 사용해야 하나요? HTTP 캐싱 전략에 대해 자세히 알아볼 수 있는 요약
캐시 만료 로직 설계
이 섹션에서는 서비스 워커 전체에 일관된 만료 로직을 사용할 경우의 장점과 단점을 설명합니다. 각 레이어에 대해 자세히 알아보고 이러한 레이어 간에 별도의 만료 로직의 장단점을 레이어가 있습니다
아래의 결함은 웹 전반에서 서비스 워커 캐싱과 HTTP 캐싱이 작동하는 방식을 여러 시나리오가 있습니다
모든 캐시 레이어에 일관된 만료 로직
장점과 단점을 설명하기 위해 장기, 중기 및 단기적으로는 변함이 없습니다.
| 시나리오 | 장기 캐싱 | 중기 캐싱 | 단기 캐싱 |
|---|---|---|---|
| 서비스 워커 캐싱 전략 | 캐시, 네트워크로 대체 | 재검증 중 비활성 | 네트워크 대체 캐시 |
| 서비스 워커 캐시 TTL | 30일 | 1일 | 10분 |
| HTTP 캐시 max-age | 30일 | 1일 | 10분 |
시나리오: 장기 캐싱 (캐시, 네트워크로 대체)
- 캐시된 리소스가 유효한 경우(30일 이하): 서비스 워커가 캐시된 리소스 리소스에 액세스할 수 있습니다
- 캐시된 리소스가 만료된 경우(30일 초과): 서비스 워커가 네트워크로 이동하여 가져올 수 있습니다 브라우저는 HTTP 캐시에 리소스의 사본이 없으므로 리소스를 위해 서버 측으로 이동합니다
단점: 이 시나리오에서는 브라우저가 항상 한 번에 여러 작업을 처리하기 때문에 HTTP 캐싱은 서비스 워커에서 캐시가 만료되면 서버 측에 요청을 전달합니다.
시나리오: 중기 캐싱 (재검증 중 비활성)
- 캐시된 리소스가 유효한 경우(1일 이하): 서비스 워커가 캐시된 리소스 리소스를 즉시 가져오고 네트워크로 이동하여 리소스를 가져옵니다. 브라우저에는 리소스를 HTTP 캐시에 저장하므로 해당 복사본을 서비스 워커에 반환합니다.
- 캐시된 리소스가 만료된 경우(1일 초과): 서비스 워커는 캐시된 리소스를 반환합니다. 리소스를 즉시 가져오고 네트워크로 이동하여 리소스를 가져옵니다. 브라우저에 리소스를 가져오므로 서버 측으로 이동하여 리소스를 가져옵니다.
단점: 서비스 워커에서 HTTP 캐시를 재정의하려면 추가 캐시 무효화가 필요합니다. '재검증'을 최대한 활용하여 단계를 거칩니다.
시나리오: 단기 캐싱 (네트워크가 캐시로 대체)
- 캐시된 리소스가 유효한 경우(<= 10분): 서비스 워커가 네트워크로 이동 리소스를 가져올 수 있습니다 브라우저의 HTTP 캐시에 리소스 사본이 있어 서비스 워커에 전달되도록 할 수 있습니다.
- 캐시된 리소스가 만료된 경우(10분 초과): 서비스 워커는 캐시된 리소스를 반환합니다. 리소스를 즉시 가져오고 네트워크로 이동하여 리소스를 가져옵니다. 브라우저에 리소스를 가져오므로 서버 측으로 이동하여 리소스를 가져옵니다.
단점: 중기 캐싱 시나리오와 마찬가지로 서비스 워커에는 추가 리소스 및 최신 리소스를 가져오기 위해 HTTP 캐시를 재정의하는 캐시 무효화 로직을 있습니다.
모든 시나리오의 서비스 워커
모든 시나리오에서 서비스 워커 캐시는 네트워크가 켜졌을 때 여전히 캐시된 리소스를 반환할 수 있습니다. 있습니다. 반면에, HTTP 캐시는 네트워크가 불안정하거나 다운되면 안정적이지 않습니다.
서비스 워커 캐시 및 HTTP 레이어의 다른 캐시 만료 로직
장점과 단점을 설명하기 위해 장기, 중기, 단기를 다시 살펴보겠습니다. 있습니다
| 시나리오 | 장기 캐싱 | 중기 캐싱 | 단기 캐싱 |
|---|---|---|---|
| 서비스 워커 캐싱 전략 | 캐시, 네트워크로 대체 | 재검증 중 비활성 | 네트워크 대체 캐시 |
| 서비스 워커 캐시 TTL | 90일 | 30일 | 1일 |
| HTTP 캐시 max-age | 30일 | 1일 | 10분 |
시나리오: 장기 캐싱 (캐시, 네트워크로 대체)
- 캐시된 리소스가 서비스 워커 캐시에서 유효한 경우(90일 이내): 캐시된 리소스를 즉시 반환합니다.
- 캐시된 리소스가 서비스 워커 캐시에서 만료된 경우(90일 초과): 네트워크로 이동하여 리소스를 가져옵니다. 브라우저에 리소스를 HTTP 캐시에 저장하므로 서버 측으로 이동합니다
장점 및 단점:
- 장점: 서비스 워커가 캐시된 리소스를 반환함에 따라 사용자가 즉각적인 응답을 경험할 수 있음 즉시 삭제할 수 있습니다
- 장점: 서비스 워커가 캐시를 사용하는 시점과 시기를 더 세밀하게 제어할 수 있습니다. 새 버전의 리소스를 요청할 수 있습니다
- 단점: 잘 정의된 서비스 워커 캐싱 전략이 필요합니다.
시나리오: 중간 캐싱 (재검증 중 비활성)
- 캐시된 리소스가 서비스 워커 캐시에서 유효한 경우(30일 이내): 캐시된 리소스를 즉시 반환합니다.
- 캐시된 리소스가 서비스 워커 캐시에서 만료된 경우(30일 초과): 리소스에 대한 네트워크로 이동합니다 브라우저에 따라서 서버 측으로 이동합니다
장점 및 단점:
- 장점: 서비스 워커가 캐시된 리소스를 반환함에 따라 사용자가 즉각적인 응답을 경험할 수 있음 즉시 삭제할 수 있습니다
- 장점: 서비스 워커는 지정된 URL에 대한 다음 요청이 재검증이 있기 때문에 네트워크로부터 새로운 응답을 받을 수 있습니다.
- 단점: 잘 정의된 서비스 워커 캐싱 전략이 필요합니다.
시나리오: 단기 캐싱 (네트워크가 캐시로 대체)
- 캐시된 리소스가 서비스 워커 캐시에서 유효한 경우(1일 이하): 해당 서비스 리소스에 대한 네트워크로 이동합니다 브라우저가 HTTP 헤더로부터 찾을 수 있습니다. 네트워크가 다운되면 서비스 워커는 서비스 워커 캐시
- 캐시된 리소스가 서비스 워커 캐시에서 만료된 경우(1일 초과): 네트워크로 이동하여 리소스를 가져옵니다. 브라우저는 캐시된 버전이 만료되었기 때문입니다.
장점 및 단점:
- 장점: 네트워크가 불안정하거나 다운되면 서비스 워커가 캐시된 결과를 반환함 리소스를 즉시 사용할 수 있습니다
- 단점: 서비스 워커가 HTTP 캐시를 재정의하기 위해서는 추가 캐시 무효화가 필요하며, '네트워크를 우선'으로 설정 있습니다
결론
캐싱 시나리오 조합의 복잡성을 고려할 때 하나의 규칙을 설계하는 것은 불가능함 적용할 수 있습니다 그러나 이전 섹션의 조사 결과에 따르면 몇 가지 캐시 전략을 설계할 때 살펴봐야 할 제안사항은 다음과 같습니다.
- 서비스 워커 캐싱 로직이 HTTP 캐싱 만료와 일치하지 않아도 됨 제공합니다. 가능하면 서비스 워커에서 더 긴 만료 로직을 사용하여 서비스 워커에 권한을 부여하세요. 관리할 수 있습니다.
- HTTP 캐싱은 여전히 중요한 역할을 하지만 네트워크가 영향을 줄 수 있습니다
- 각 리소스의 캐싱 전략을 다시 검토하여 서비스 워커 캐싱 확인 전략은 HTTP 캐시와 충돌하지 않고 값을 제공합니다.