프로그레시브 웹 앱 : 충돌 코스

PWAS (Progressive Web Apps)는 모바일 사용자에게 최상의 기능을 제공하여 모바일 웹 앱 및 기본 모바일 앱의 세계를 겹치려고 노력합니다. 그들은 앱과 같은 사용자 경험 (Splash Screens and Home Screen Icons)을 제공하고 HTTPS- 보안 서버에서 제공되며 낮은 품질 또는 느린 네트워크에서도 빠르게로드 할 수 있습니다 (페이지로드 성능 모범 사례 덕분). 조건 및 오프라인 지원, 즉시로드 및 푸시 알림이 있습니다. PWAS의 개념은 Google에서 처음 소개되었으며 여전히 많은 크롬 기능과 Lighthouse와 같은 훌륭한 도구, 접근성, 성능 및 진보성 감사를위한 오픈 소스 도구와 같은 훌륭한 도구로 여전히 지원됩니다. > 이 충돌 과정 전체에 걸쳐 ES6으로 처음부터 PWA를 구축하고 UX 및 성능 측면에서 최상의 결과를 얻을 때까지 등대로 단계별로 반응하고 최적화합니다. Progressive라는 용어는 단순히 PWA가 많은 새로운 기능과 기술이 이미 지원되었지만 이전 브라우저에서도 잘 작동 해야하는 현대식 브라우저에서

점진적으로

가 향상 될 수있는 방식으로 설계되었음을 의미합니다. 최첨단 특징이 없습니다.

키 테이크 아웃

PROPERIVIRIVE WEB APPS (PWAS)는 모바일 웹과 기본 앱 간의 격차를 해소하여 오프라인 지원 및 푸시 알림과 같은 고성능 및 사용자 참여 기능을 제공합니다. PWAS는 App Store 다운로드가 필요하지 않고 브라우저를 통해 액세스 할 수 있으며 현대 및 기존 브라우저에서 모두 작동하도록 점진적으로 향상 될 수 있습니다. Google의 등대 도구는 PWA를 감사하고 최적화하는 데 필수적이며 개발자가 접근성, 성능 및 진보적 인 표준 준수를 개선 할 수 있도록 도와줍니다. PWA를 구축하는 것은 오프라인 지원 및 자원 캐싱과 같은 기능을 가능하게하는 서비스 작업자를 설정하여 앱 성능 및 신뢰성을 크게 향상시킬 수 있습니다. PRPL 패턴은 리소스로드 및 상호 작용 준비를 최적화하여 PWA 성능을 향상시켜 네트워크 조건에 도전하는 경우에도 원활한 사용자 경험을 보장합니다. 서비스 작업자는 PWAS, 배경 동기화 및 푸시 알림을 처리하고 주요 리소스를 캐싱하여 거의 즉시로드 할 수 있도록합니다.

PWA의 미래는 웹 기술의 지속적인 개선과 주요 브라우저 및 플랫폼의 지원이 증가함에 따라 유망한 것으로 보인다.

기본 대 모바일 = 프로그레시브 기본 앱은 모바일 OS의 각 앱 스토어에서 배포 가능하며 다운로드 할 수 있습니다. 반면에 모바일 웹 앱은 주소 나 URL을 간단히 입력하여 웹 브라우저 내에서 액세스 할 수 있습니다. 사용자의 관점에서 브라우저를 시작하고 주소로 탐색하는 것이 앱 스토어로 가서 다운로드, 설치, 앱을 시작하는 것보다 훨씬 편리합니다. 개발자/소유자의 관점에서, App Store 계정을 받기 위해 일회성 수수료를 지불 한 다음 전 세계 사용자가 액세스 할 수 있도록 앱을 업로드하는 데 웹 호스팅의 복잡성을 다루는 것보다 낫습니다. 기본 앱을 오프라인으로 사용할 수 있습니다. 일부 API 서버에서 검색 해야하는 원격 데이터의 경우 최신 액세스 데이터의 SQLITE 캐싱을 지원하기 위해 앱을 쉽게 고안 할 수 있습니다.

모바일 웹 앱은 Google과 같은 검색 엔진을 통해 색인이 가능하며 검색 엔진 최적화를 통해 더 많은 사용자에게 도달 할 수 있습니다. 앱 스토어에는 개발자가 다른 기술 (일반적으로 App Store Optimization)을 적용하여 더 많은 사용자에게 도달 할 수있는 자체 검색 엔진이 있기 때문에 이는 기본 앱에도 해당됩니다. 기본 앱은 모든 리소스가 앱을 실행할 준비가 될 때까지 스플래시 화면으로 즉시로드됩니다. 이것들은 가장 중요한 인식 된 차이입니다. 앱 배포에 대한 각 접근 방식은 최종 사용자 (사용자 경험, 가용성 등) 및 앱 소유자 (비용, 고객 도달 범위 등)에 대한 장점이 있습니다. 이를 고려하여 Google은 PWA를 도입하여 양쪽의 가장 좋은 기능을 하나의 개념으로 가져 왔습니다. 이러한 측면은 Chrome 엔지니어 인 Alex Russell이 소개 한이 목록에 요약되어 있습니다. (출처 : 드물게 언급되었습니다.)
반응 : 모든 폼 팩터에 맞습니다.
<:> Connective Ind
• app-like-interactions : 쉘 콘텐츠 응용 프로그램 모델을 채택하여 Appy Navigations & Interactions를 생성합니다.
Fresh : 서비스 작업자 업데이트 프로세스 덕분에 항상 최신 최신입니다.
• 안전 : 스누핑을 방지하기 위해 TLS (서비스 작업자 요구 사항)를 통해 제공됩니다.
발견 가능 : W3C Manifests 및 Service Worker 등록 범위 덕분에 검색 엔진을 찾을 수 있도록 "응용 프로그램"으로 식별 할 수 있습니다.
• 리엔지닝 가능 : OS의 재입수 UI에 액세스 할 수 있습니다. 예를 들어 푸시 알림.
설치 가능 : 브라우저 제공 프롬프트를 통해 홈 화면으로, 사용자는 앱 스토어의 번거 로움없이 가장 유용한 앱을 "유지"할 수 있습니다. Linkable :이를 의미합니다. 이는 건전성이없고, 설치가 없으며, 공유하기 쉽습니다. URL의 사회적 힘은 중요합니다.
Lighthouse Lighthouse는 Google에서 작성한 웹 앱을 감사하는 도구입니다. Chrome Dev 도구와 통합되어 감사 패널에서 트리거 될 수 있습니다. Lighthouse를 Nodejs CLI 도구로 사용할 수도 있습니다.
• 그런 다음 다음과 같이 실행할 수 있습니다
CLI 기반 버전을 사용하더라도 등대를 사용할 수 있도록 시스템에 크롬을 설치해야합니다.

첫 번째 PWA를 처음부터 구축 이 섹션에서는 처음부터 프로그레시브 웹 앱을 만들 것입니다. 먼저 React 및 Reddit의 API를 사용하여 간단한 웹 응용 프로그램을 작성합니다. 다음으로 Lighthouse Report에서 제공 한 지침에 따라 PWA 기능을 추가 할 예정입니다. 공개 No-Authentication Reddit API에는 CORS 헤더가 활성화되어 중개 서버없이 클라이언트 측 앱에서 소비 할 수 있습니다. 우리가 시작하기 전에이 과정은 nodejs 및 npm이 설치된 개발 환경 설정이 있다고 가정합니다. 그렇지 않은 경우, Awesome Homestead 개선으로 시작하여 최신 버전의 최신 버전을 실행하고 상자 밖으로 개발 및 테스트를 준비하고 있습니다. . 우리는 REACT 팀이 만든 프로젝트 보일러 플레이트 인 Create React App을 설치하여 시작합니다.

응용 프로그램 쉘 아키텍처 응용 프로그램 쉘은 프로그레시브 웹 앱의 필수 개념입니다. 단순히 사용자 인터페이스를 렌더링하는 최소 HTML, CSS 및 JavaScript 코드입니다.

<span>npm install -g lighthouse  
</span>

이 앱 쉘에는 성능에 많은 이점이 있습니다. 다음 번에 사용자가 앱을 방문 할 때 브라우저가 원격 서버에서 자산을 가져올 필요가 없기 때문에 응용 프로그램 쉘을 캐시 할 수 있으므로 다음 번에 앱을 방문하면 즉시로드됩니다.

. 간단한 UI를 구축하려면 React에서 Google 자재 설계 구현 인 Material UI를 사용합니다. NPM에서 패키지를 설치하겠습니다 :

다음에 src/app.js를 열면 다음을 추가하십시오

다음은 두 가지 메소드 FetchFirst () 및 fetchNext ()를 사용하여 Reddit 게시물을 가져와야합니다.

이 github 리포지토리에서 소스 코드를 찾을 수 있습니다.

앱에 대한 감사를 실행하기 전에 로컬 서버를 사용하여 로컬로 구축하고 앱을 제공해야합니다. 이 명령은 package.json에서 빌드 스크립트를 호출하고 React-PWA/빌드 폴더에서 빌드를 생성합니다. 이제 로컬 서버를 사용하여 앱을 제공 할 수 있습니다. Homestead 개선에서 Nginx 가상 호스트를 Build Folder에 가리키고 브라우저에서 Homestead.app을 열거나 Nodejs를 통해 서빙 패키지를 사용할 수 있습니다.

서브를 사용하면 앱이 http : // localhost : 5000/.
문제없이 앱을 감사 할 수 있지만 모바일 장치에서 테스트하려는 경우 Surge.sh와 같은 서비스를 사용하여 하나의 명령으로 배포 할 수도 있습니다!

.

다음으로, 디렉토리 내에서 SURGE를 실행하여 해당 디렉토리를 웹에 게시합니다. 이 링크에서 호스팅 된이 앱의 호스팅 버전을 찾을 수 있습니다.

이제 Chrome DevTools를 열고 감사 패널로 가서 감사 수행을 클릭하십시오.

lighthouse https://sitepoint.com/

보고서에서 우리는 이미 Progressive Web App의 경우 45/100 점, 성능을 위해 68/100을 이미 볼 수 있습니다. Progressive Web App에서는 6 개의 감사가 실패했으며 5 번의 감사가 있습니다. 생성 된 프로젝트에는 이미 웹 매니페스트, 뷰포트 메타 및 <script> 태그와 같은 일부 PWA 기능이 기본적으로 추가 되었기 때문입니다. <have> 성능 하에서 우리는 진단과 첫 번째 의미있는 페인트, 첫 번째 대화식, 일관성있는 대화식, 지각 속도 지수 및 추정 입력 대기 시간과 같은 다른 계산 메트릭을 가지고 있습니다. 나중에 이것을 살펴 보겠습니다. </script>

Lighthouse는 다운로드 크기를 줄이거 나 불필요한 리소스의 다운로드를 연기하여 중요한 렌더 체인의 길이를 줄임으로써 페이지 부하 성능을 향상시킬 것을 제안합니다.

성능 점수 및 메트릭 값은 현재 네트워크 상태 및 현재 기계 상태와 같은 다양한 조건의 영향을 받기 때문에 동일한 기계의 다른 감사 세션간에 변경 될 수 있습니다. 왜 페이지 부하 성능 및 속도 물질 DoubleClick (Google 광고 회사)에 따르면, 모바일 사이트 방문의 53%가 페이지를로드하는 데 3 초 이상이 걸리면 포기됩니다. PWA는 페이지로드 성능 및 속도를 최적화하여 다음에 볼 수있는 일련의 기술 및 전략을 통해 사용자에게 즉각적인 웹 경험을 제공합니다.

성능을 고려하십시오 대부분의 클라이언트 측 앱은 반응, preact, angular, vue 등과 같은 일종의 JavaScript 라이브러리 또는 프레임 워크를 사용하여 구축됩니다. PWA를 구축하는 경우 모바일 최초의 라이브러리를 선택해야합니다. 즉, 모바일 웹용으로 설계된 라이브러리가 처음에는 도서관입니다. 그렇지 않으면 성능을 위해 앱을 최적화하는 것은 불가능한 임무가 될 것입니다.

Chrome Devtools, Lighthouse, Google Pagespeed 등과 같은 다양한 테스트 도구를 사용하여 다양한 네트워크 조건에서 앱을 심하게 테스트하므로 앱 페이지로드 성능을 성공적으로 최적화 할 수 있습니다.

. PWA 성능 지표 레이더에 넣어야합니다 등대를 사용하여 다양한 메트릭, 진단 및 기회로 앱의 페이지로드 성능을 측정하고 최적화 할 수 있습니다. Lighthouse는 다른 메트릭을 사용합니다. 첫 번째 의미있는 페인트

첫 번째 의미있는 페인트는 사용자가 화면에서 의미있는 또는 기본 내용을 볼 수있는 시간을 나타내는 측정 값입니다. 이 감사가 낮을수록 앱의 인식 된 성능이 향상됩니다.

앱 의이 메트릭은 다음과 같습니다

우리는 1.3s에서 브라우저가 빈 배경을 렌더링하기 시작한 다음 2s에서 브라우저가 헤더를 렌더링하기 시작했습니다. 헤더의 버튼과 하단이 렌더링됩니다. 게시물이 렌더링되는 것은 세 번째 초가되어야합니다. 전체 프로세스는 3.4 초가 걸렸으며 첫 번째 의미있는 페인트는 2.340ms 와 같습니다. 첫 번째 의미있는 페인트는 실제로 우리가 의미있는 것으로 간주 할 수있는 것에 달려 있으며, 이는 사용자마다 다를 수 있습니다. 사용자가 게시물을 읽는 데 관심이있는 경우, 첫 번째 의미있는 페인트는 3 초 마크 이후입니다. Google 이이 문서 에서이 메트릭을 계산하는 방법을 알 수 있습니다.

이것은 Lighthouse가 FMP를 로보고 한 동일한 앱의 또 다른 필름 스트립입니다. 마지막 스크린 샷에서 포스트 헤드 라인이 위의 지역에 완전히 표시됩니다.

. 둘째, 페이지가 한 번에 아니라 점진적으로 렌더링된다는 것을 알 수 있습니다. 이는 성능의 좋은 표시입니다. 중요한 렌더링 경로를 최적화 하여이 측정을 최적화 할 수 있습니다. 임계 렌더링 경로 중요한 렌더링 경로는 웹 브라우저가 페이지를 렌더링하는 방법, 즉 HTML, CSS 및 JavaScript 자산을 수신하는 첫 번째 순간부터 브라우저가 실제 의미있는 컨텐츠를 처리하고 렌더링하는 단계에 이르기까지 개념입니다. 중요한 렌더링 경로를 최적화하려면 사용자의 현재 작업과 관련된 콘텐츠에 우선 순위를 높여야합니다. 즉, 앱을 방문하려는 경우 먼저 UI의 가시적 인 부분을 표시하거나 위의 지역이라고 불리는 것을 시작할 수 있습니다. 자세한 내용은 "중요한 렌더링 경로 최적화"를 읽을 수 있습니다. 중요한 CSS 자산을 인화하기위한 선별 된 도구 목록도 볼 수 있습니다. 또한 JavaScript 및 기타 자산을 인화하기위한이 도구를 확인하십시오. <:> inliner : 웹 페이지의 인라인 이미지, CSS 및 JavaScript에 대한 노드 유틸리티 인라인 소스 : html 의 플래그가 지정된 JS, CSS 및 IMG 소스를 인화하는 도구 인라인 소스 클리 : 인라인 소스를위한 CLI 도구

중요한 요청 체인 중요한 요청 체인은 중요한 렌더링 경로와 관련된 개념이며, 페이지를 렌더링하기 위해 중요한 리소스를 분해하여 각 리소스에 걸리는 시간 및 각 리소스에 대해 다운로드 할 바이트 수를 분해하는 다이어그램으로 표시 될 수 있습니다. 임계 요청 체인 다이어그램을 사용하여 비동기로 제거, 연기 또는 표시를 위해 중요한 리소스를 더 잘 이해할 수 있습니다. 예제 PWA 보고서의 스크린 샷은 다음과 같습니다.

이제 인라인 소스와 인라인 소스 클라이를 사용 하여이 문제를 해결해 보겠습니다.

그런 다음 빌드 폴더 내부를 탐색하고 index.html을 열면 및 요소에 키워드를 추가합니다.

이 리소스를 인라인으로 봅시다 :

CSS 및 JavaScript 자산을 인화하여 중요한 요청 체인을 2로 줄였습니다. 첫 번째 대화식 및 일관되게 대화식

이 두 가지 메트릭은 모두 사용자가 앱과 상호 작용할 수있는 시간을 나타냅니다. 두 메트릭 모두 참여 능력과 유용성을 표현하지만 이들 사이에는 차이가 있습니다. 페이지가 최소 대화식 일 때 첫 번째 대화식 측정 값은 페이지가 완전히 상호 작용할 때 지속적으로 대화식 측정됩니다. 중요한 렌더링 경로를 최적화하여 대화식 시간을 최적화 할 수 있습니다. 지각 속도 지수

지각 속도 지수는 레이아웃 안정성 (UI 요소의 갑작스런 변위가 없음)을 고려하면서 페이지의 상단에 대한 시각적 성능을 측정하는 메트릭입니다. 단순히 페이지 내용이 눈에 띄게 채워지는 정도를 나타냅니다.

psi는 SI 또는 속도 지수 메트릭의 수정 된 버전이며, 이는 시각적 안정성을 고려하지 않고 위의 (가시적) 영역이 표시되는 평균 시간입니다. 중요한 렌더링 경로를 최적화 하여이 메트릭을 최적화 할 수도 있습니다. 추정 된 입력 대기 시간 추정 된 입력 대기 시간은 기본 스레드가 입력을 처리 할 준비가 된 시점을 나타내는 메트릭입니다. 당신은이 메트릭과 그것을 여기에 전달하는 방법에 대해 더 많이 읽을 수 있습니다.

첫 바이트 (ttfb) 까지 Wikipedia는 ttfb를 다음과 같이 정의합니다

첫 바이트 (TTFB)까지의 시간은 웹 서버 또는 기타 네트워크 리소스의 응답 성을 나타내는 측정입니다. TTFB는 클라이언트 브라우저가 수신하는 페이지의 첫 바이트에 HTTP 요청을하는 사용자 또는 클라이언트의 지속 시간을 측정합니다.

WebPagetest 및 Lighthouse와 같은 도구를 사용하여 PWA의 TTFB를 측정 할 수 있습니다. 자세한 내용은이 링크를 참조하십시오.

이제 개발자가 이러한 메트릭을 최적화하기 위해 사용하는 일련의 개념과 일반적인 기술을 보자. 코드 분할 및 경로 기반 청킹 JavaScript 생태계는 최근 몇 년 동안 Webpack 및 Browserify와 같은 모듈 번들과 같은 새로운 도구를 통해 모든 스크립트를 하나의 파일에 묶는 데 사용됩니다. 이는 여러 스크립트 파일에 대한 네트워크 요청을 하나의 요청 (전체 번들을 얻기위한)으로 줄여 중요한 렌더링 경로 (장거리 블로킹 JavaScript 및 CSS 자산)로 최적화하는 데 도움이되므로 모범 사례로 간주됩니다. 그러나 문제는 대형 앱의 경우 번들이 크기가 커져서 번들을 다운로드하고 처리하는 프로세스를 만들고 애플리케이션을 매우 비효율적으로 부팅하여 인스턴트 웹 경험에 영향을 미칩니다 (첫 번째 의미있는 시간을 높이는 데 영향을 미칩니다. 페인트와 UI가 대화식이 될 시간).

이 문제의 솔루션으로서, 다른 앱은 코드 분할 및 경로 기반 청킹을 사용합니다 (코드를 각 경로에만 필요한 청크로 분할). 따라서 브라우저는 첫 번째 페이지/경로를 렌더링하는 데 필요한 첫 번째 청크 만 다운로드하면 사용자가 다른 경로를 탐색 할 때 나머지 청크를로드합니다. 서버 측 렌더링 서버 측 렌더링은 브라우저 대신 서버의 초기 컨텐츠를 렌더링하는 프로세스입니다. 브라우저가 다운로드 한 후 즉시 콘텐츠 (일반 HTML)를 표시 할 수 있으므로 많은 상황에서 페이지로드 성능을 향상시킬 수 있습니다. . 서버 측 렌더링만으로는 자바 스크립트 자산을 다운로드하고 부팅해야하므로 사용자가 대화식 시간을 최적화하는 데 큰 도움이되지 않습니다. PRPL 성능 패턴

PRPL은 HTTP/2 서버 푸시, 예압 헤더, 서비스 작업자 및 게으른로드와 같은 개념을 사용하는 성능 패턴입니다. PWA 전달 및 발사의 성능을 향상시킵니다. Prpl은 다음과 같습니다

초기 URL 경로의 임계 리소스를 푸시하십시오 초기 경로를 렌더링합니다 나머지 경로 사전 캐시 게으른 부하 및 수요에 남아있는 경로를 만듭니다

출처 : Google Web Fundamentals

캐싱을 통한 성능을 최적화합니다 캐싱은 가까운 스토리지 위치에 자주 요청되는 데이터를 유지하는 프로세스입니다. 웹의 경우 브라우저 메모리 또는 데이터베이스입니다. 브라우저에는 실제로 캐싱 네트워크 응답을 위해 특별히 설계된 캐시 위치가 있지만 개발자는 HTML5 로컬 스토리지 API 및 IndexedDB와 같은 다른 스토리지 메커니즘을 활용할 수도 있습니다. 당신은 응용 프로그램 쉘 (UI 렌더링을 담당하는 자산), 데이터 또는 이상적으로 둘 다 캐시 할 수 있습니다. UI를 캐싱하는 것은 즉각적인 웹 경험을 달성하는 데 중요합니다. 그러나 데이터는 어떻습니까? 우리는 여기에서 두 가지 범주의 앱을 고려할 수 있습니다. UI 렌더링을 담당하는 자산을 얻기 위해 네트워크 연결이 필요한 앱 및/또는 핵심 기능을 제공하기 위해서는이를 필요로합니다. 예를 들어, 알고리즘 및 계산 (로컬 CPU)에만 의존하는 사용자를위한 개인 회계를 제공하는 앱을 생각해보십시오. 두 번째 범주는 업데이트 된 정보를 얻기 위해 원격 서버에 의존하는 앱입니다. 데이터가 곧 쓸모 없게 될 것이며 사용자는 대부분 업데이트 된 정보가 필요하다는 점을 감안할 때 왜 데이터를 캐시 해야하는지 궁금 할 것입니다. 문제는 세계의 많은 지역에서 문제는 네트워크 연결의 영구적 인 중단이 아니라 느린 신호와 우수한 신호 사이의 네트워크의 변동 상태이며, 이는 앱이 이미로드 된 경우에도 사용자 경험에 영향을 미칩니다.

앱은 데이터 캐싱 (배경 동기화 API를 활용)을 사용하여 사용자가 페이지를 탐색 할 때 또는 단기간에 앱으로 돌아와서 다시 앱으로 돌아 오는 경우에도 서비스를 보장 할 수 있습니다. 네트워크 상태를 지속적으로 시청 한 다음 사용자를 방해하지 않고 데이터 가져 오기/보내기를 재개하십시오. 이제 더 나은 점수를 위해 실패한 문제를 해결해 봅시다 서비스 작업자 등록 첫 번째 실패한 감사는 앱이 서비스 작업자를 등록하지 않는다고 말합니다. 그것을 변경하기 전에 먼저 서비스 근로자와 관련 기능을 이해해 봅시다.

서비스 작업자는 최신 브라우저 기술로, 네트워크 요청을 가로 채면 앱 (네트워크 요청을 가로 채면 즉시로드 및 오프라인 지원 등)과 같은 기능을 추가하기위한 캐싱을 구현할 수있는 클라이언트 측 프록시로 사용할 수있는 최신 브라우저 기술입니다. 서비스 작업자는 업데이트를 구현하고 푸시 알림을 사용하는 데 사용될 수도 있습니다. 서비스 작업자는 PAGE DOM에 액세스 할 수 없지만 postMessage () 메소드를 통해 클라이언트 (창, 작업자 또는 공유 작업자)와 통신 할 수 있습니다. 많은 브라우저 API는 다음과 같은 서비스 작업자 내부에서 사용할 수 있습니다.

Fetch API : 원격 서버에서 컨텐츠를 가져 오기 (요청 보내기 및 응답 받기) 캐시 API : 캐싱 컨텐츠의 경우 (요청에 의해 키가 표시된 응답 스토어 생성) 푸시 API : 푸시 알림을 얻는

배경 동기화 API : 사용자가 안정적인 연결성을 가질 때까지 웹 앱이 작업을 연기 할 수 있습니다.

서비스 작업자는 적절하게 처리 해야하는 많은 수명주기 이벤트가 있습니다.

<: :> 설치 이벤트 : 사용자가 앱을 처음 방문하고 서비스 작업자가 다운로드 및 설치되면 이벤트를 설치합니다. 활성화 이벤트 : .register ()를 호출 한 후 트리거 됨 (이벤트를 다운로드하고 설치 한 후) Fetch 이벤트 : 서비스 작업자의 범위 내에서 내비게이션의 경우 가져 오기 이벤트를 얻거나 모든 요청이 트리거 된 범위 페이지입니다.

RECT 프로젝트에는 이미 서비스 작업자가 포함되어 있습니다. 우리는 그것을 사용하거나 새로운 것을 만들 수 있으므로 서비스 근로자의 작동 방식에 대한 더 나은 아이디어를 얻을 수 있습니다. 공개 폴더에서 service-worker.js라는 새 파일을 만들고 다음 코드를 추가하여

위 내용은 프로그레시브 웹 앱 : 충돌 코스의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!