プログレッシブWebアプリ(PWAS)モバイルユーザーに最高の機能を提供することにより、モバイルWebアプリとネイティブモバイルアプリの世界に重複してみてください。
アプリのようなユーザーエクスペリエンス(スプラッシュスクリーンとホーム画面アイコン)を提供し、HTTPSが固定されたサーバーから提供されます。条件、およびオフラインサポート、インスタントロード、プッシュ通知があります。 PWAの概念はGoogleによって最初に導入され、多くのChrome機能やLighthouseなどの優れたツールでサポートされています。 >
このクラッシュコースを通して、ES6でPWAをゼロから構築し、UXとパフォーマンスに関して最良の結果を達成するまで、灯台で段階的に反応して最適化します。
プログレッシブという用語は、PWAが多くの新機能とテクノロジーがすでにサポートされているが、古いブラウザでも正常に機能する最新のブラウザーで徐々に拡張できるようにPWAが設計されていることを意味します。最先端の機能はありません。
キーテイクアウト
プログレッシブWebアプリ(PWAS)モバイルWebとネイティブアプリの間のギャップを橋渡しし、オフラインサポートやプッシュ通知などの高性能およびユーザーエンゲージメント機能を提供します。
PWAは、アプリストアのダウンロードを必要とせずにブラウザを介してアクセスでき、最新のブラウザと古いブラウザーの両方で動作するように徐々に強化できます。
Googleの灯台ツールは、PWASの監査と最適化に不可欠であり、開発者がアクセシビリティ、パフォーマンス、および進歩的な基準の順守を改善するのに役立ちます。
PWAを構築するには、オフラインサポートやリソースキャッシュなどの機能を可能にし、アプリのパフォーマンスと信頼性を大幅に向上させるサービスワーカーのセットアップが含まれます。
PRPLパターンは、リソースの読み込みと相互作用の準備を最適化することにより、PWAのパフォーマンスを向上させ、挑戦的なネットワーク条件でもシームレスなユーザーエクスペリエンスを確保します。
サービスワーカーは、PWASで重要な役割を果たし、バックグラウンドの同期とプッシュ通知を処理し、主要なリソースをキャッシュすることでアプリをほぼ即座にロードできるようにします。
PWAの未来は有望に見え、Webテクノロジーの継続的な改善と主要なブラウザーやプラットフォームからのサポートの増加、それらをネイティブアプリの説得力のある代替品として位置づけています。
ネイティブ対mobile = progressive
ネイティブアプリは、モバイルOSのそれぞれのApp Storeから分散型でダウンロードできます。一方、モバイルWebアプリは、アドレスまたはURLを入力するだけで、Webブラウザー内からアクセスできます。ユーザーの観点からは、ブラウザを起動してアドレスに移動することは、アプリストアに行ってダウンロード、インストール、アプリの起動よりもはるかに便利です。開発者/所有者の視点から、App Storeアカウントを取得するために1回限りの料金を支払ってから、アプリをアップロードして世界中のユーザーにアクセスできるようにすることは、Webホスティングの複雑さに対処するよりも優れています。
ネイティブアプリはオフラインで使用できます。一部のAPIサーバーから取得する必要があるリモートデータの場合、アプリは最新のアクセスデータの何らかのSQLiteキャッシングをサポートするために簡単に考案できます。
モバイルWebアプリは、Googleなどの検索エンジンがインデックスできるようになり、検索エンジンの最適化により、より多くのユーザーにリーチできます。これはネイティブアプリにも当てはまります。アプリストアには独自の検索エンジンがあり、開発者はより多くのユーザーにリーチするために、一般的にApp Store Optimizationとして知られるさまざまな手法を適用できるためです。
ネイティブアプリは、少なくともスプラッシュ画面を使用して、すべてのリソースがアプリを実行できるようになるまで即座にロードします。
これらは最も重要な知覚された違いです。アプリの分布への各アプローチには、エンドユーザー(ユーザーエクスペリエンス、可用性など)とアプリの所有者(コスト、顧客の範囲など)に利点があります。それを考慮に入れて、GoogleはPWASを導入して、各サイドの最高の機能を1つの概念にまとめました。これらの側面は、Google ChromeエンジニアのAlex Russellによって導入されたこのリストにまとめられています。 (出典:めったに記録
応答性:あらゆるフォームファクターに適合します。
接続性独立性:サービスワーカーと徐々に強化して、オフラインで作業できるようにします。
アプリのようなインタラクション:シェルコンテンツアプリケーションモデルを採用して、アッピーナビゲーションとインタラクションを作成します。
Fresh:サービスワーカーの更新プロセスのおかげで、常に最新の状態に透過的に。
安全:スヌーピングを防ぐためにTLS(サービスワーカーの要件)を介して提供されます。
発見可能:W3Cマニフェストとサービスワーカー登録の範囲により、検索エンジンがそれらを見つけることができるおかげで、「アプリケーション」として識別できます。
再触覚:OSの再エンゲージメントUISにアクセスできます。例えば通知をプッシュします。
インストール可能:ブラウザが提供するプロンプトを介してホーム画面に、ユーザーがアプリの手間がかからずに最も便利だと思うアプリを「保持」できるようにします。
リンク可能:ゼロ摩擦、ゼロインストール、そして共有しやすいことを意味します。 URLの社会的力は重要です
灯台
lighthouseは、Googleが作成したWebアプリを監査するためのツールです。 Chrome Dev Toolsと統合されており、監査パネルからトリガーできます。
灯台をnodejs cliツールとして使用することもできます:
次のように実行できます
灯台はChrome拡張機能としてインストールすることもできますが、GoogleはDevToolsと統合されたバージョンを使用し、DevToolsを何らかの形で使用できない場合にのみ拡張機能を使用することをお勧めします。
<span>npm install -g lighthouse
</span> ログイン後にコピー
ログイン後にコピー
CLIベースのバージョンを使用していても、灯台を使用できるようにシステムにChromeをインストールする必要があることに注意してください。
最初のPWAをゼロから構築します
このセクションでは、プログレッシブWebアプリをゼロから作成します。まず、ReactとRedditのAPIを使用してシンプルなWebアプリケーションを作成します。次に、Lighthouseレポートで提供された指示に従ってPWA機能を追加します。
lighthouse https://sitepoint.com/
ログイン後にコピー
ログイン後にコピー
公開されていないReddit APIにはCORSヘッダーが有効になっているため、仲介サーバーなしでクライアント側のアプリから消費できることに注意してください。
開始する前に、このコースでは、NodeJSとNPMがインストールされた開発環境のセットアップがあると仮定します。そうでない場合は、それぞれの最新のバージョンを実行している素晴らしいホームステッドの改善から始めて、箱から出して開発とテストの準備ができています。
Webパック構成の手間からあなたを救うReactチームによって作成されたプロジェクトのボイラープレートであるCreate React Appをインストールすることから始めます。
<span>npm install -g lighthouse
</span> ログイン後にコピー
ログイン後にコピー
アプリケーションシェルアーキテクチャ
アプリケーションシェルは、プログレッシブWebアプリの重要な概念です。これは、ユーザーインターフェイスのレンダリングを担当する最小限のHTML、CSS、およびJavaScriptコードです。
このアプリシェルには、パフォーマンスに多くの利点があります。アプリケーションシェルをキャッシュできます。ユーザーが次回アプリにアクセスすると、ブラウザがリモートサーバーからアセットを取得する必要がないため、すぐにロードされます。
単純なUIを構築するには、ReactでGoogle Material Designの実装であるMaterial UIを使用します。
npm:
からパッケージをインストールしましょう
次にsrc/app.jsを開きます。次に追加します
次に、2つの方法を使用してRedditの投稿を取得する必要がありますfetchfirst()とfetchnext():
lighthouse https://sitepoint.com/
ログイン後にコピー
ログイン後にコピー
このgithubリポジトリにソースコードを見つけることができます。
<span>npm install -g create-react-app
</span>create-react-app react-pwa
<span>cd react-pwa/
</span> ログイン後にコピー
アプリに対して監査を実行する前に、ローカルサーバーを使用してビルドを作成してローカルにアプリを提供する必要があります。
このコマンドは、Package.jsonでビルドスクリプトを呼び出し、React-PWA/ビルドフォルダーにビルドを作成します。
これで、任意のローカルサーバーを使用してアプリを提供できます。 Homesteadの改善では、nginx仮想ホストをビルドフォルダーに向けて、BrowserでHomestead.appを開くだけで、nodejs経由でサーブパッケージを使用できます。
<span>npm install material-ui --save
</span> ログイン後にコピー
サーブを使用すると、アプリはhttp:// localhost:5000/。
から地元で提供されます
<span>import <span>React, { Component }</span> from 'react';
</span><span>import <span>MuiThemeProvider</span> from 'material-ui/styles/MuiThemeProvider';
</span><span>import <span>AppBar</span> from 'material-ui/AppBar';
</span><span>import <span>{Card, CardActions, CardHeader,CardTitle,CardText}</span> from 'material-ui/Card';
</span><span>import <span>FlatButton</span> from 'material-ui/FlatButton';
</span><span>import <span>IconButton</span> from 'material-ui/IconButton';
</span><span>import <span>NavigationClose</span> from 'material-ui/svg-icons/navigation/close';
</span>
<span>import logo from './logo.svg';
</span><span>import './App.css';
</span>
<span>class App extends Component {
</span>
<span>constructor(props) {
</span> <span>super(props);
</span>
<span>this.state = {
</span> <span>posts: []
</span> <span>};
</span> <span>}
</span>
<span>render() {
</span> <span>return (
</span>
<span><MuiThemeProvider>
</span> <span><div>
</span> <span><AppBar
</span> title<span>={<span >React PWA</span>}
</span>
iconElementLeft<span>={<IconButton><NavigationClose /></IconButton>}
</span> iconElementRight<span>={<FlatButton onClick={() => this.fetchNext('reactjs', this.state.lastPostName)} label="next" />
</span> <span>}
</span> <span>/>
</span>
<span>{this.state.posts.map(function (el<span>, index</span>) {
</span> <span>return <Card key={index}>
</span> <span><CardHeader
</span> title<span>={el.data.title}
</span>
subtitle<span>={el.data.author}
</span> actAsExpander<span>={el.data.is_self === true}
</span> showExpandableButton<span>={false}
</span> <span>/>
</span>
<span><CardText expandable={el.data.is_self === true}>
</span> <span>{el.data.selftext}
</span> <span></CardText>
</span> <span><CardActions>
</span> <span><FlatButton label="View" onClick={() => {
</span> <span>window.open(el.data.url);
</span> <span>}} />
</span>
<span></CardActions>
</span> <span></Card>
</span> <span>})}
</span>
<span><FlatButton onClick={() => this.fetchNext('reactjs', this.state.lastPostName)} label="next" />
</span> <span></div>
</span> <span></MuiThemeProvider>
</span>
<span>);
</span> <span>}
</span><span>}
</span>
<span>export default App;
</span> ログイン後にコピー
問題なくアプリを監査することはできますが、モバイルデバイスでテストする場合は、Surge.shなどのサービスを使用して1つのコマンドで展開することもできます!
<span>fetchFirst(url) {
</span> <span>var that = this;
</span> <span>if (url) {
</span> <span>fetch('https://www.reddit.com/r/' + url + '.json').then(function (response) {
</span> <span>return response.json();
</span> <span>}).then(function (result) {
</span>
that<span>.setState({ posts: result.data.children, lastPostName: result.data.children[result.data.children.length - 1].data.name });
</span>
<span>console.log(that.state.posts);
</span> <span>});
</span> <span>}
</span> <span>}
</span> <span>fetchNext(url<span>, lastPostName</span>) {
</span> <span>var that = this;
</span> <span>if (url) {
</span> <span>fetch('https://www.reddit.com/r/' + url + '.json' + '?count=' + 25 + '&after=' + lastPostName).then(function (response) {
</span> <span>return response.json();
</span> <span>}).then(function (result) {
</span>
that<span>.setState({ posts: result.data.children, lastPostName: result.data.children[result.data.children.length - 1].data.name });
</span> <span>console.log(that.state.posts);
</span> <span>});
</span> <span>}
</span> <span>}
</span> <span>componentWillMount() {
</span>
<span>this.fetchFirst("reactjs");
</span><span>}
</span> ログイン後にコピー
次に、任意のディレクトリ内からサージを実行して、そのディレクトリをWebに公開します。
このリンクからこのアプリのホストバージョンを見つけることができます。
ここで、Chrome Devtoolsを開き、監査パネルに移動して、監査の実行をクリックしましょう。
レポートから、プログレッシブWebアプリでは45/100のスコア、パフォーマンスに68/100のスコアがすでにあることがわかります。
プログレッシブWebアプリでは、6つの監査に失敗した監査と5つの合格監査があります。これは、生成されたプロジェクトには、Webマニフェスト、ビューポートメタ、
タグなど、デフォルトでいくつかのPWA機能が追加されているためです。
パフォーマンスの下で、最初の意味のあるペイント、最初のインタラクティブ、一貫したインタラクティブ、知覚速度インデックス、推定入力遅延など、診断とさまざまな計算メトリックがあります。これらを後で検討します。<span>npm run build
</span> ログイン後にコピー
Lighthouseは、ダウンロードサイズを縮小するか、不要なリソースのダウンロードを延期することにより、クリティカルレンダリングチェーンの長さを短縮することにより、ページの負荷性能を改善することをお勧めします。
現在のネットワーク状態や現在のマシン状態などのさまざまな条件の影響を受けるため、同じマシンの異なる監査セッション間でパフォーマンススコアとメトリックの値が変化する可能性があることに注意してください。
なぜページロードパフォーマンスと速度
DoubleClick(Google Advertising Company)によると、ページのロードに3秒以上かかると、モバイルサイトの訪問の53%が放棄されます。ページの負荷のパフォーマンスと速度を最適化することにより、PWAは、次に見る一連のテクニックと戦略を介してユーザーにインスタントWebエクスペリエンスを提供します。
PWAの構築を開始する前に、パフォーマンスを検討してください
クライアント側アプリの大部分は、React、Preact、Angular、Vueなどの何らかのJavaScriptライブラリまたはフレームワークを使用して構築されています。PWAを構築する場合は、モバイルファーストライブラリを選択する必要がありますまたは、言い換えれば、そもそもモバイルWeb用に設計されたライブラリです。それ以外の場合、パフォーマンスのためにアプリを最適化することは不可能なミッションになります。
Chrome Devtools、Lighthouse、Google PagesSpeedなどのさまざまなテストツールを使用して、さまざまなシミュレーションネットワーク条件下でアプリを強くテストする必要があります。
PWAパフォーマンスメトリックあなたはあなたのレーダーに置く必要があります
灯台を使用して、さまざまなメトリック、診断、および機会を使用して、アプリのページのロードパフォーマンスを測定および最適化できます。
灯台は異なるメトリックを使用しています。それらを1つずつカバーしましょう:
最初の意味のあるペイント
最初の意味のあるペイントは、ユーザーが画面上で意味のあるコンテンツまたはプライマリコンテンツを見ることができる時間を単に示す尺度です。この監査が低いほど、アプリの知覚されたパフォーマンスが向上します。
アプリのこのメトリックは次のとおりです。
1.3からブラウザが空の背景をレンダリングし始め、2秒からブラウザがヘッダーのレンダリングを開始し、ヘッダーのボタンと下部の両方のボタンがレンダリングされていることがわかります。投稿がレンダリングされるのは3番目の秒までではありません。プロセス全体に3.4秒かかり、最初の意味のあるペイントは 2.340msに等しくなります。
最初の意味のあるペイントは、私たちが意味のあるものと見なすことができるものに本当に依存しており、それは異なるユーザー間で異なる場合があります。ユーザーが投稿の読み取りにのみ関心がある場合、最初の意味のあるペイントは3秒のマークの後です。 Googleがこのドキュメントからこのメトリックをどのように計算するかを見ることができます。
これは、灯台がFMPを最後のスクリーンショットで2.560msと報告した同じアプリのもう1つのフィルムストリップであり、ポスト見出しが上記の領域に完全に表示されています。
第二に、ページは一度にはなく徐々にレンダリングされていることがわかります。これはパフォーマンスの適切な兆候です。
重要なレンダリングパスを最適化することにより、この尺度を最適化できます。
重要なレンダリングパス
重要なレンダリングパスは、Webブラウザーがページをレンダリングする方法に関連する概念です。つまり、HTML、CSS、JavaScriptアセットを受信した最初の瞬間から、ブラウザが実際の意味のあるコンテンツを処理およびレンダリングするステップまでです。重要なレンダリングパスを最適化するには、ユーザーの現在のアクションに関連するコンテンツにより優先度を高める必要があります。つまり、彼らがあなたのアプリにアクセスしようとしている場合、最初にUIの可視部分、または上記の領域と呼ばれるものを表示することから始めることができます。
詳細については、「重要なレンダリングパスの最適化」を読むことができます。
重要なCSS資産を挿入するためのキュレーションされたツールのこのリストも表示されます。また、JavaScriptおよびその他の資産を挿入するためのこれらのツールを確認してください:
Inliner:Webページのインライン画像、CSS、JavaScriptへのノードユーティリティ
インラインソース:htmlにフラグを立てたJS、CSS、およびIMGソースをインランスするためのツール
Inline-Source-Cli:インラインソースのためのCLIツール。
クリティカルリクエストチェーン
重要な要求チェーンは、重要なレンダリングパスに関連する概念であり、重要なリソースを分解してページをレンダリングするための重要なリソース、各リソースのかかる時間、各リソースにダウンロードするバイト数で表すことができます。重要なリクエストチェーン図を使用して、重要なリソースをよりよく理解して、非同期を排除、延期、またはマークすることができます。これが私たちの例のPWAレポートのスクリーンショットです:
インラインソースとインラインソース-CLIを使用してこの問題を解決してみましょう:
次に、ビルドフォルダーの内側とindex.htmlを開き、 and <script>要素にインラインをインラインで追加します。
<p>
これらのリソースをインライン化しましょう:<pre ><span >npm install -g lighthouse
<p>
<pre >lighthouse https://sitepoint.com/
<p>
CSSとJavaScriptアセットを挿入することにより、重要な要求チェーンを2に減らしました。<h4 >最初のインタラクティブで一貫してインタラクティブ
<p>これら2つのメトリックは、ユーザーがアプリと対話できる時間を示しています。どちらのメトリックも、関与と使いやすさを表していますが、それらの間には違いがあります。ページが最小限のインタラクティブである場合、最初のインタラクティブな測定ページが完全にインタラクティブな場合は一貫してインタラクティブな測定値。
重要なレンダリングパスを最適化することにより、インタラクティブになる時間を最適化できます。
<p>知覚速度インデックス
<h3 >知覚速度インデックスは、レイアウトの安定性(UI要素の突然の変位はありません)を考慮しながら、ページの上記の視覚的パフォーマンスを測定するメトリックです。それは単にページの内容がどれほど速く目に見えるかを示していることを示しています。
psiは、視覚的安定性を考慮せずに上記(目に見える)領域が表示される平均時間であるSiまたは速度インデックスメトリックの変更されたバージョンです。
<p>重要なレンダリングパスを最適化することにより、このメトリックを最適化することもできます。
推定入力レイテンシ<p>
推定入力レイテンシは、メインスレッドが入力を処理する準備ができていることを示すメトリックです。
<p>このメトリックの詳細とここで渡す方法を読むことができます。
最初のバイト(TTFB)<h3 >への時間
WikipediaはTTFBを次のように定義します
<p>
First Byte(TTFB)への時間は、Webサーバーまたは他のネットワークリソースの応答性の指標として使用される測定です。 TTFBは、ユーザーまたはクライアントから、クライアントのブラウザが受信しているページの最初のバイトにHTTPリクエストを作成する期間を測定します。
<p>
WebPagetestやLighthouseなどのツールを使用して、PWAのTTFBを測定できます。詳細については、このリンクを参照してください。<h3 >
これらのメトリックを最適化するために開発者が使用する一連の概念と一般的な手法を見てみましょう。
<p>コード分割とルートベースのチャンキング
<blockquote>JavaScriptエコシステムは、すべてのスクリプトを1つのファイルにバンドルするために使用されるWebpackやBrowserifyなどのモジュールバンドラーなどの新しいツールを使用して、近年劇的に変化しています。これは、複数のスクリプトファイルのネットワークリクエストを1つのリクエスト(バンドル全体を取得するため)にたった1つのリクエストに削減し、重要なレンダリングパス(長いブロッキングJavaScriptとCSSアセットなし)を最適化するのに役立つためです。しかし、問題は、大規模なアプリの場合、バンドルのサイズが大きくなり、バンドルをダウンロードし、処理するプロセスを作成し、アプリケーションを非常に非効率的に起動し、インスタントWebエクスペリエンスに影響を与える(最初の意味の時間を増やすペイントとUIがインタラクティブになる時間)。この問題の解決策として、さまざまなアプリがコード分割とルートベースのチャンキング(各ルートにのみ必要なチャンクにコードを分割する)を使用します。したがって、ブラウザは、最初のページ/ルートをレンダリングするために必要な最初のチャンクをダウンロードする必要があります。その後、ユーザーが他のルートをナビゲートしているときに残りのチャンクをレイジーにロードします。
<p>サーバー側のレンダリング
<h2 >サーバー側のレンダリングは、ブラウザの代わりにサーバー上の初期コンテンツをレンダリングするプロセスです。これは、多くの場合、ブラウザがダウンロードした直後にコンテンツ(プレーンHTML)を表示できるため、ページのロードパフォーマンスを向上させる可能性があります。 。
JavaScriptアセットをダウンロードして起動する必要があるため、サーバー側のレンダリングだけでユーザーがインタラクティブになる時間を最適化するのにあまり役に立ちません。
<p>prplパフォーマンスパターン
<p>PRPLは、HTTP/2サーバーのプッシュ、プリロードヘッダー、サービスワーカー、PWA配信と起動のパフォーマンスを向上させる怠zyなロードなどの概念を利用するパフォーマンスパターンです。
prplは<h2 >の略です
<p>初期URLルートの重要なリソースを押します
<p>初期ルートをレンダリングします
<ul>残りルート前のキャッシュ<li>
怠zyな負荷と、オンデマンドで残りのルートを作成します。<li>
<li>出典:Google Webファンダメンタルズ<li>
キャッシングによるパフォーマンスの最適化
<p>キャッシングは、頻繁に要求されるデータを閉鎖の場所に保持するプロセスです。 Webの場合、それがブラウザのメモリまたはデータベースです。ブラウザは実際にネットワーク応答をキャッシュするために特別に設計されたキャッシュの場所を持っていますが、開発者はHTML5ローカルストレージAPIやIndexEdDBなどの他のストレージメカニズムを活用することもできます。
<em>アプリケーションシェル(UIのレンダリングを担当する資産)、データ、または理想的には両方をキャッシュできます。 UIのキャッシュは、インスタントWebエクスペリエンスを達成するために重要です。しかし、データはどうですか?
ここでは、2つのカテゴリのアプリを検討できます。 UIをレンダリングするためにアセットを担当するためのネットワーク接続のみが必要なアプリ、および/またはコア機能を提供するためにそれを必要とするアプリ。たとえば、アルゴリズムと計算(ローカルCPU)にのみ依存するユーザーに個人会計を提供するアプリを考えてみてください。
<h3 >2番目のカテゴリは、更新された情報を取得するためにリモートサーバーに依存するアプリです。データをキャッシュする必要がある理由は疑問に思うかもしれません。すぐに時代遅れになり、ユーザーがほとんど更新された情報が必要になるからです。問題は、世界の多くの地域で、問題はネットワーク接続の永続的な中断ではなく、遅い信号と良好な信号の間のネットワークの変動状態であり、アプリが既にロードされていてもユーザーエクスペリエンスに影響を与えるものです。 <p>アプリは、ユーザーがページ間でナビゲートしているときにサービスを保証するためにデータキャッシュ(バックグラウンドSYNC APIを利用する)を使用することができます。ネットワーク状態を継続的に監視し、ユーザーを中断することなくデータの取得/送信を再開します。
では、より良いスコアのために失敗した問題を解決しましょう。<p>
サービスワーカーの登録<h2 >
最初の失敗した監査は、アプリがサービスワーカーを登録しないと言っていることです。それを変更する前に、まずサービスワーカーと関連する機能を理解しましょう。
<p>サービスワーカーは、インスタントロードやオフラインサポートなどの機能を追加するためのキャッシュを実装できるように(ネットワークリクエストを傍受することにより)クライアント側プロキシとして使用できる最新のブラウザテクノロジーです。
サービスワーカーは、更新を実装したり、プッシュ通知に関与するために使用することもできます。
<p>サービスワーカーはページDOMにアクセスできませんが、PostMessage()メソッドを介してクライアント(ウィンドウ、ワーカー、または共有ワーカー)と通信できます。
多くのブラウザAPIは、以下などのサービスワーカー内で使用できます。
<p>
Fetch API:リモートサーバーからコンテンツを取得する(リクエストを送信して応答を取得する)<p>
キャッシュAPI:キャッシングコンテンツの場合(リクエストによってキー化された応答のキャッシュストアを作成)<p>
プッシュAPI:プッシュ通知を取得するには<ul>
<li>バックグラウンド同期API:ユーザーが安定した接続を持つまで、Webアプリがアクションを延期できるようにします。
<li>サービスワーカーには、適切に処理する必要があるライフサイクルイベントがたくさんあります。
<li>インストールイベント:アプリが最初にユーザーが訪問し、サービスワーカーがダウンロードされてインストールされたときにインストールイベントを取得します
<li>アクティブ化イベント:電話後にトリガーされた.register()(イベントをダウンロードしてインストールした後)<
フェッチイベント:サービスワーカーのスコープ内でナビゲーションが発生した場合、またはスコープページをトリガーしたリクエストの場合、フェッチイベントを取得します。
<p> Reactプロジェクトにはすでにサービスワーカーが含まれています。私たちはそれを使用するか、新しいものを作成して、サービスワーカーがどのように機能するかについてより良いアイデアを得ることができます。
<survice-worker.jsという名前の新しいファイルをパブリックフォルダーで作成してから、次のコードを追加してpublic/index.htmlファイルから登録してください</script> 以上がプログレッシブWebアプリ:クラッシュコースの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。