서비스 워커를 사용하여 네트워크를 기다리지 않고 탐색 요청에 응답합니다.
탐색 요청은 탐색 메뉴에 새 URL을 입력하거나 페이지의 링크를 따라 새 URL로 이동할 때마다 브라우저에서 수행하는 HTML 문서 요청입니다. 이것이 바로 서비스 워커가 성능에 가장 큰 영향을 미치는 부분입니다. 서비스 워커를 사용하여 네트워크를 기다리지 않고 탐색 요청에 응답하면 탐색이 안정적으로 빨라지고 네트워크를 사용할 수 없을 때 복원력이 향상됩니다. 이는 HTTP 캐싱으로 가능한 것과 비교하여 서비스 워커에서 얻을 수 있는 가장 큰 성능 이점입니다.
네트워크에서 로드된 리소스 식별 가이드에 자세히 설명된 대로 탐색 요청은 네트워크 트래픽의 '폭포수'에서 이루어지는 여러 요청 중 첫 번째 요청입니다. 탐색 요청을 통해 로드하는 HTML은 이미지, 스크립트, 스타일과 같은 하위 리소스에 대한 다른 모든 요청의 흐름을 시작합니다.
서비스 워커의 fetch 이벤트 핸들러 내에서 FetchEvent의 request.mode 속성을 확인하여 요청이 탐색인지 확인할 수 있습니다. 'navigate'로 설정된 경우 탐색 요청입니다.
일반적으로 탐색 요청의 HTML 응답을 캐시하는 데 수명이 긴 Cache-Control headers를 사용하지 마세요. 일반적으로 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을 로드하면 기존 클라이언트 측 JavaScript가 인계받아 원래 탐색 요청의 URL에 맞는 올바른 HTML 콘텐츠를 렌더링합니다.
Workbox는 이 접근 방식을 구현하는 데 필요한 도구를 제공합니다. navigateFallback
option를 사용하면 앱 셸로 사용할 HTML 문서를 지정할 수 있으며, 선택적 허용 및 거부 목록을 사용하여 이 동작을 URL의 하위 집합으로 제한할 수 있습니다.
다중 페이지 앱
웹 서버가 사이트의 HTML을 동적으로 생성하거나 고유한 페이지가 수십 개 이상인 경우 탐색 요청을 처리할 때 네트워크를 피하기가 훨씬 더 어렵습니다. 기타의 조언이 적용될 수 있습니다.
하지만 특정 다중 페이지 앱 하위 집합의 경우 웹 서버에서 HTML을 생성하는 데 사용하는 로직을 완전히 복제하는 서비스 워커를 구현할 수 있습니다. 이는 서버와 서비스 워커 환경 간에 라우팅 및 템플릿 정보를 공유할 수 있는 경우, 특히 웹 서버가 JavaScript를 사용하는 경우 (파일 시스템 액세스와 같은 Node.js 관련 기능에 의존하지 않음) 가장 효과적입니다.
웹 서버가 이 카테고리에 속하고 HTML 생성을 네트워크에서 서비스 워커로 이동하는 방법을 알아보고 싶다면 SPA를 넘어: PWA의 대체 아키텍처의 안내를 참고하세요.
기타
캐시된 HTML로 탐색 요청에 응답할 수 없는 경우 사이트에 서비스 워커를 추가해도 (HTML이 아닌 다른 요청을 처리하기 위해) 탐색 속도가 느려지지 않도록 조치를 취해야 합니다. 서비스 워커를 사용하여 탐색 요청에 응답하지 않고 서비스 워커를 시작하면 약간의 지연 시간이 발생합니다(서비스 워커를 사용하여 더 빠르고 복원력이 뛰어난 앱 빌드 참고). 탐색 미리 로드라는 기능을 사용 설정한 다음 fetch 이벤트 핸들러 내에 미리 로드된 네트워크 응답을 사용하여 이 오버헤드를 완화할 수 있습니다.
Workbox는 탐색 미리 로드가 지원되는지 여부를 기능 감지하는 도우미 라이브러리를 제공하며, 지원되는 경우 서비스 워커에 네트워크 응답을 사용하도록 지시하는 프로세스를 간소화합니다.