서비스 워커 등록 타이밍의 모범 사례
서비스 작업자 웹 앱을 반복적으로 방문하는 속도를 유의미하게 높일 수 있지만 서비스 워커의 초기 설치로 인해 네트워크의 성능이 저하되지 않도록 사용자의 첫 방문 경험을 추적할 수 있습니다
일반적으로 서비스 워커를 지연하면 등록 사용자에게 최적의 환경을 제공하기 위해 특히 네트워크 연결이 느린 모바일 장치를 사용하는 사용자에게 도움이 됩니다.
일반적인 등록 상용구
서비스 워커에 대해 읽은 적이 있다면 아마 상용구는 다음과 매우 유사합니다.
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/service-worker.js');
}
경우에 따라 몇 개의 console.log() 문이 수반될 수도 있습니다. 또는
코드
복구하는 방법으로 이전 서비스 워커 등록에 대한 업데이트를
사용자에게 페이지 새로고침을 알립니다. 그러나 이것들은 Kubernetes의 사소한 변형에 불과합니다
몇 줄의 표준 코드를 사용합니다.
그렇다면 navigator.serviceWorker.register에는 미묘한 차이가 있을까요? CANNOT TRANSLATE
어떤 권장사항을 따라야 할까요? 당연한 결과입니다 (이 도움말이 끝나지 않는다는 점을 고려하면
두 질문 모두에 대한 답은 "예!"입니다.
사용자의 첫 방문
사용자가 웹 앱을 처음 방문한 경우를 생각해 보겠습니다. 아직 서비스 워커가 없으며 브라우저는 서비스가 최종 설치 작업자를 호출할 수 있습니다
개발자로서 여러분의 우선순위는 브라우저가 빠르게 양방향 인터페이스를 표시하는 데 필요한 최소한의 중요 리소스를 있습니다. 이러한 응답을 가져오는 속도를 늦추는 모든 것은 공격의 적 빠르게 구현할 수 있습니다.
이제 자바스크립트나 이미지를 다운로드하는 과정에서 페이지를 렌더링해야 하는 경우 브라우저가 백그라운드 스레드를 시작하거나 스레드라고 가정하겠습니다. 가정 견고한 데스크톱 컴퓨터가 아니라 성능이 저하된 가장 많이 사용하는 휴대기기입니다. 스피닝 이 추가 스레드는 브라우저의 CPU 시간과 메모리에 대한 경합을 증가시킵니다. 많은 비용을 지출하게 될 수 있습니다.
유휴 백그라운드 스레드는 큰 차이를 발생시킬 가능성이 낮습니다. 하지만 해당 스레드가 유휴 상태가 아닌 경우 대신 스레드가 대기 모드를 시작하기로 결정하고 어떻게 해야 할까요? CPU 또는 메모리 관련 우려사항 제한된 대역폭에 대한 우려로 한 걸음 물러나 사용할 수 있습니다. 대역폭은 매우 중요하므로 보조 리소스를 동시에 다운로드하여 중요한 리소스를 더욱 효율적으로 사용할 수 있습니다.
이 모든 것은 즉, 새 서비스 워커 스레드를 가동하여 백그라운드에 있는 캐시 리소스는 요청하지 못할 수 있습니다 사용자가 사이트를 처음 방문할 때 상호작용까지 걸리는 시간이 가장 짧은 환경을 사이트
상용구 개선
해결책은 호출 시점을 선택하여 서비스 워커의 시작을 제어하는 것입니다.
navigator.serviceWorker.register() 일반적으로는 지연 시간과
등록 기한은 load
event까지
다음과 같이 window에서 시작됩니다.
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker.register('/service-worker.js');
});
}
그러나 서비스 워커 등록을 시작하는 적절한 시간은 즉시 파악할 수 있습니다. 예를 들어 Google I/O는 2016 웹 앱에 짧은 애니메이션이 있음 전환할 수 있습니다. Google 팀 발견했다고 합니다. 애니메이션 도중 서비스 워커 등록을 해제하면 버벅거림이 발생할 수 있음 광고를 게재할 수 있습니다. Google은 사용자에게 불만족스러운 경험을 제공하기보다는 지연 서비스 워커 등록은 애니메이션이 끝난 후 몇 초 정도 유휴 상태일 수 있습니다
마찬가지로 웹 앱이 설정 완료 후 추가 설정을 수행하는 프레임워크를 사용하면 페이지가 로드된 경우 페이지가 로드된 시점을 나타내는 프레임워크별 이벤트를 작업이 완료됩니다
후속 방문
지금까지는 첫 방문 경험에 초점을 맞췄습니다. 하지만 서비스 워커 등록 지연으로 인해 사이트를 반복 방문했을까요? 놀랄 수도 있지만 전혀 영향을 미치지 않습니다.
서비스 워커가 등록되면 install를 거치고
activate 수명 주기
이벤트를 사용합니다.
서비스 워커가 활성화되면 해당 서비스의 fetch 이벤트를 처리할 수 있습니다.
웹 앱에 대한 후속 방문입니다. 서비스 워커는 시작 전에
모든 페이지에 대한 요청이 이루어지는데 이는
있습니다. 기존 서비스 워커가 아직 실행 중이 아니었다면
페이지를 방문하면 다음에 대한 fetch 이벤트를 처리할 수 없습니다.
탐색 요청에 사용합니다.
따라서 활성 서비스 워커가 있으면 언제 어디서나
navigator.serviceWorker.register() 또는 실제로는 호출해도 상관없습니다.
서비스 워커 스크립트의 URL을 변경하지 않으면
navigator.serviceWorker.register()는 사실상
후속 방문 중에는 작동하지 않습니다.
관련이 없습니다.
일찍 등록해야 하는 이유
서비스 워커를 가장 빨리 등록하는 시나리오가 있나요?
이해가 가시나요? 예를 들면, 서비스 워커에서 서비스 워커가
clients.claim() 드림
첫 번째 방문 동안 페이지를 제어하고 서비스 워커는
적극적으로 런타임 수행
캐싱
fetch 핸들러 내에 삽입하세요. 이러한 상황에서는
최대한 빨리 서비스 워커를 활성화하여 가능한 한 빨리
나중에 편리하게 사용할 수 있는 리소스로 런타임 캐시를 채웁니다. 만약
웹 앱이 이 카테고리에 속하는 경우 한 걸음 물러서서
서비스 워커의 install 핸들러가
기본 페이지의 요청과 함께 대역폭을 두고 싸우는 리소스.
테스트하기
첫 번째 방문을 시뮬레이션하는 가장 좋은 방법은 웹 앱을 Chrome 시크릿 모드 window, Chrome 웹 브라우저에서 네트워크 트래픽을 DevTools를 사용할 수 있습니다. 웹 개발자라면 아마 웹 앱의 로컬 인스턴스를 수십 개의 하루에 수십 번 그렇지만 이미 사이트를 방문했을 때 캐시와 서비스 워커가 모두 채워져 있으므로 동일한 경험을 얻지 못합니다. 잠재적인 문제를 무시하기 쉽습니다.
다음은 등록 시점 간의 시간 차이를 보여주는 예입니다. 있습니다. 두 스크린샷 모두 샘플 앱을 네트워크 제한을 사용하여 느린 연결을 시뮬레이션하는 시크릿 모드
위의 스크린샷은 샘플이 수정되었을 때의 네트워크 트래픽을 나타냅니다.
가능한 한 빨리 서비스 워커 등록을 수행해야 합니다. 여기에서
사전 캐싱 요청 (톱니바퀴 모양이 있는 항목
아이콘
서비스 워커의 install 핸들러에서 비롯됨)
페이지 표시에 필요한 다른 리소스 요청에 산재되어 있습니다.
위의 스크린샷에서 서비스 워커 등록은
페이지를 로드했습니다. 사전 캐싱 요청은
네트워크에서 가져온 리소스만 가져오기 때문에
할 수 있습니다. 게다가 사전 캐시하는 항목 중 일부는 이미
브라우저의 HTTP 캐시 — 크기의 (from disk cache) 항목이
열로 이동하지 않고도 서비스 워커의 캐시를 채울 수 있습니다.
다시 연결할 수 있습니다
10.10.1.1의 가격으로 실제 저사양 기기에서 이러한 종류의 테스트를 사용할 수 있습니다. Chrome의 원격 디버깅을 활용하여 기능 USB를 통해 Android 휴대전화를 데스크톱 컴퓨터에 연결하고 테스트의 결과는 여러 광고주 사이트의 실제 경험을 있습니다.
결론
요약하자면, 사용자의 첫 방문이 만족스러워야 합니다. 최우선 순위여야 합니다 서비스 워커 등록을 페이지가 로드된 경우 이를 확인하는 데 도움이 됩니다. 다음 혜택을 계속 이용할 수 있습니다. 반복 방문에 서비스 워커가 있는 모든 이점을 누려보세요.
서비스 워커의 초기 작업 실행을 지연시키는 간단한 방법 등록하려면 다음을 사용해야 합니다.
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker.register('/service-worker.js');
});
}