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