서비스 워커를 사용하여 네트워크를 기다리지 않고 탐색 요청에 응답합니다.
탐색 요청은 탐색 메뉴에 새 URL을 입력하거나 페이지의 링크를 따라 새 URL로 이동할 때마다 브라우저에서 HTML 문서에 대해 실행하는 요청입니다. 여기에서 서비스 워커가 성능에 가장 큰 영향을 미칩니다. 서비스 워커를 사용하여 네트워크를 기다리지 않고 탐색 요청에 응답하면 네트워크를 사용할 수 없는 경우에도 탐색이 안정적으로 빠르게 이루어질 뿐만 아니라 탄력적일 수 있습니다. 이는 HTTP 캐싱으로 가능한 것과 비교할 때 서비스 워커에서 얻을 수 있는 가장 큰 단일 성능 이점입니다.
네트워크에서 로드된 리소스 식별 가이드에 설명된 대로 탐색 요청은 네트워크 트래픽의 '폭포식'에서 이루어지는 여러 요청 중 첫 번째 요청입니다. 탐색 요청을 통해 로드하는 HTML은 이미지, 스크립트, 스타일과 같은 하위 리소스에 대한 다른 모든 요청의 흐름을 시작합니다.
서비스 워커의 fetch 이벤트 핸들러 내에서 FetchEvent의 request.mode 속성을 확인하여 요청이 탐색인지 확인할 수 있습니다. 'navigate'로 설정된 경우 탐색 요청입니다.
일반적으로 장기 실행 Cache-Control headers를 사용하여 탐색 요청의 HTML 응답을 캐시하지 마세요. 일반적으로 HTML이 후속 네트워크 요청 체인과 함께 (합리적으로) 최신 상태를 유지하도록 Cache-Control: no-cache를 사용하여 네트워크를 통해 충족해야 합니다. 사용자가 새 페이지로 이동할 때마다 네트워크를 사용하면 각 탐색이 느려질 수 있습니다. 최소한 빠르지 않을 안정적으로 빠르지 않다는 의미입니다.
아키텍처에 대한 다양한 접근 방식
네트워크를 피하면서 탐색 요청에 응답하는 방법을 파악하는 것은 쉽지 않을 수 있습니다. 적절한 접근 방식은 웹사이트의 아키텍처와 사용자가 이동할 수 있는 고유한 URL 수에 따라 크게 달라집니다.
모든 상황에 천편일률적으로 적용할 수 있는 방식은 없지만 다음과 같이 최우선으로 고려해야 할 주요 인사이트를 소개합니다.
소규모 정적 사이트
웹 앱이 비교적 적은 수 (예: 수십 개)의 고유 URL로 구성되어 있고 각 URL이 서로 다른 정적 HTML 파일에 해당하는 경우, 이러한 HTML 파일을 모두 캐시하고 적절한 캐시된 HTML로 탐색 요청에 응답하는 것이 좋습니다.
사전 캐싱을 사용하면 서비스 워커가 설치되는 즉시 HTML을 미리 캐시하고 사이트를 다시 빌드하고 서비스 워커를 다시 배포할 때마다 캐시된 HTML을 업데이트할 수 있습니다.
또는 사용자가 사이트의 일부 URL로만 이동하는 경향이 있으므로 모든 HTML을 미리 캐시하지 않으려면 stale-while-revalidate 런타임 캐싱 전략을 사용하면 됩니다. 하지만 이 접근 방식은 각 개별 HTML 문서가 별도로 캐시되고 업데이트되므로 주의해야 합니다. HTML에 런타임 캐싱을 사용하는 것은 동일한 사용자가 자주 다시 방문하는 소수의 URL이 있고 이러한 URL이 서로 독립적으로 재검증될 수 있다고 판단되는 경우에 가장 적합합니다.
단일 페이지 앱
싱글페이지 아키텍처는 최신 웹 애플리케이션에서 자주 사용됩니다. 여기서 클라이언트 측 JavaScript는 사용자 작업에 응답하여 HTML을 수정합니다. 이 모델은 History API를 사용하여 사용자가 웹 앱과 상호작용할 때 현재 URL을 수정하여 사실상 '시뮬레이션된' 탐색을 유도합니다. 후속 탐색은 '가짜'일 수 있지만 초기 탐색은 실제이므로 네트워크에서 차단되지 않았는지 확인하는 것이 중요합니다.
다행히 싱글페이지 아키텍처를 사용하는 경우 캐시에서 초기 탐색을 제공하기 위해 따를 수 있는 간단한 패턴이 있습니다. 바로 애플리케이션 셸입니다. 이 모델에서 서비스 워커는 요청된 URL과 관계없이 이미 미리 캐시된 동일한 단일 HTML 파일을 반환하여 탐색 요청에 응답합니다. 이 HTML은 일반 로드 표시기 또는 스켈레톤 콘텐츠로 구성된 최소한의 HTML이어야 합니다. 브라우저가 캐시에서 이 HTML을 로드하면 기존 클라이언트 측 JavaScript가 이를 인계받아 원래 탐색 요청의 URL에 맞는 올바른 HTML 콘텐츠를 렌더링합니다.
Workbox는 이 접근 방식을 구현하는 데 필요한 도구를 제공합니다. navigateFallback
option를 사용하면 앱 셸로 사용할 HTML 문서를 지정할 수 있으며, 선택적 허용 및 거부 목록을 사용하여 이 동작을 URL의 하위 집합으로 제한할 수 있습니다.
다중 페이지 앱
웹 서버가 사이트의 HTML을 동적으로 생성하거나 고유한 페이지가 수십 개 이상 있는 경우 탐색 요청을 처리할 때 네트워크를 피하는 것이 훨씬 더 어렵습니다. 기타의 안내가 적용될 가능성이 큽니다.
하지만 멀티페이지 앱의 특정 하위 집합의 경우 웹 서버에서 HTML을 생성하는 데 사용되는 로직을 완전히 복제하는 서비스 워커를 구현할 수 있습니다. 이는 서버와 서비스 워커 환경 간에 라우팅 및 템플릿 정보를 공유할 수 있는 경우에 가장 효과적이며, 특히 웹 서버가 파일 시스템 액세스와 같은 Node.js별 기능에 의존하지 않고 JavaScript를 사용하는 경우에 유용합니다.
웹 서버가 이 카테고리에 해당하며 HTML 생성을 네트워크에서 서비스 워커로 이동하는 한 가지 접근 방식을 살펴보고 싶다면 SPA 이외: PWA의 대체 아키텍처의 안내를 참고하세요.
기타
캐시된 HTML로 탐색 요청에 응답할 수 없는 경우 사이트에 서비스 워커를 추가하여 HTML이 아닌 다른 요청을 처리해도 탐색 속도가 느려지지 않도록 조치를 취해야 합니다. 서비스 워커를 탐색 요청에 응답하는 데 사용하지 않고 시작하면 약간의 지연 시간이 발생합니다 (서비스 워커로 더 빠르고 탄력적인 앱 빌드 참고). 탐색 미리 로드라는 기능을 사용 설정한 다음 fetch 이벤트 핸들러 내에 미리 로드된 네트워크 응답을 사용하여 이 오버헤드를 완화할 수 있습니다.
Workbox는 탐색 미리 로드가 지원되는지 기능 감지하고 지원되는 경우 서비스 워커에 네트워크 응답을 사용하도록 지시하는 프로세스를 간소화하는 도우미 라이브러리를 제공합니다.