서비스 워커를 사용하여 네트워크에서 기다리지 않고 탐색 요청에 응답합니다.
탐색 요청은 탐색 메뉴에 새 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 문서가 개별적으로 캐시 및 업데이트되므로 이 접근 방식에는 주의해야 합니다. 동일한 사용자 그룹이 자주 다시 확인하는 URL 수가 적고 이러한 URL을 서로 독립적으로 재확인해도 괜찮다면 HTML에 런타임 캐싱을 사용하는 것이 가장 적합합니다.
단일 페이지 앱
단일 페이지 아키텍처는 최신 웹 애플리케이션에서 자주 사용됩니다. 여기서 클라이언트 측 JavaScript는 사용자 작업에 대한 응답으로 HTML을 수정합니다. 이 모델은 사용자가 웹 앱과 상호작용할 때 History API를 사용하여 현재 URL을 수정하므로 실질적으로 '시뮬레이션된' 탐색이 됩니다. 후속 탐색은 '가짜'일 수 있지만 초기 탐색은 실제이므로 네트워크에서 차단되지 않도록 하는 것이 중요합니다.
다행히 단일 페이지 아키텍처를 사용하는 경우 캐시에서 초기 탐색을 제공하기 위한 간단한 패턴인 애플리케이션 셸이 있습니다. 이 모델에서 서비스 워커는 요청된 URL과 관계없이 이미 사전 캐시된 동일한 단일 HTML 파일을 반환하여 탐색 요청에 응답합니다. 이 HTML은 일반 로드 표시기 또는 스켈레톤 콘텐츠로 구성된 기본 HTML이어야 합니다. 브라우저가 캐시에서 이 HTML을 로드하면 기존 클라이언트 측 JavaScript가 이를 인계하여 원래 탐색 요청에서 URL에 대한 올바른 HTML 콘텐츠를 렌더링합니다.
Workbox는 이 접근 방식을 구현하는 데 필요한 도구를 제공합니다. navigateFallback
option를 사용하면 이 동작을 URL의 하위 집합으로 제한하는 선택적 허용 및 거부 목록과 함께 앱 셸로 사용할 HTML 문서를 지정할 수 있습니다.
다중 페이지 앱
웹 서버에서 사이트의 HTML을 동적으로 생성하거나 고유한 페이지가 수십 개 이상 있는 경우 탐색 요청을 처리할 때 네트워크를 제외하기가 훨씬 어렵습니다. 기타 섹션의 조언이 적합할 것입니다.
하지만 멀티 페이지 앱의 특정 하위 집합에서는 HTML을 생성하기 위해 웹 서버에서 사용되는 로직을 완전히 복제하는 서비스 워커를 구현할 수 있습니다. 이 방법은 서버와 서비스 워커 환경 간에 라우팅 및 템플릿 정보를 공유할 수 있는 경우, 특히 웹 서버가 자바스크립트를 사용하는 경우 (파일 시스템 액세스와 같은 Node.js 관련 기능에 의존하지 않음) 가장 효과적입니다.
웹 서버가 이 카테고리에 해당하고 네트워크에서 HTML 생성을 서비스 워커로 이동하는 한 가지 방법을 알아보려는 경우 SPA 너머: PWA를 위한 대체 아키텍처의 안내를 참고하세요.
기타
캐시된 HTML로 탐색 요청에 응답할 수 없는 경우, HTML이 아닌 기타 요청을 처리하기 위해 사이트에 서비스 워커를 추가해도 탐색 속도가 느려지지 않도록 조치를 취해야 합니다. 서비스 워커를 사용하여 탐색 요청에 응답하지 않고 서비스 워커를 시작하면 약간의 지연 시간이 발생합니다 (서비스 워커로 더 빠르고 복원력이 우수한 앱 빌드에서 설명). 탐색 미리 로드라는 기능을 사용 설정한 다음 fetch 이벤트 핸들러 내에 미리 로드된 네트워크 응답을 사용하여 이 오버헤드를 완화할 수 있습니다.
Workbox는 탐색 미리 로드가 지원되는지 기능을 감지하는 도우미 라이브러리를 제공하며, 지원되는 경우 서비스 워커에 네트워크 응답을 사용하도록 지시하는 프로세스를 간소화합니다.