プログレッシブウェブアプリ(PWA, Progressive Web App)

1. 概要

A. 定義

プログレッシブウェブアプリ(PWA)とは、標準的なウェブ技術(HTML·CSS·JavaScript)で実装しつつ、サービスワーカー(Service Worker)·ウェブアプリマニフェスト(Web App Manifest)·HTTPSを組み合わせて、ネイティブアプリに準じたインストール性·オフライン動作·プッシュ通知·バックグラウンド処理を提供するウェブアプリケーションである。2015年にGoogleのエンジニアAlex RussellとデザイナーのFrances Berrimanが命名した概念で、「一つのコードベースでウェブの到達性(reach)とアプリの没入性(engagement)を同時に得る」という志向を込めている。

PWAが独立したアーキテクチャのパラダイムとして浮上した背景には、「ウェブとアプリの断絶」という長年の課題がある。従来のウェブはURL一つで即座にアクセスでき、インストールや更新が不要という強力な利点を持っていたが、ネットワークが切れると何もできず、ホーム画面アイコン·プッシュ通知·ハードウェアアクセスといった「アプリらしさ」を提供できなかった。逆にネイティブアプリは豊富な機能と没入感を与えるが、アプリストア審査·大容量インストール·プラットフォーム別開発(iOS/Androidの二重投資)という参入障壁が大きい。PWAはこの隔たりを「ウェブの配布モデルの上にアプリのユーザー体験を漸進的に載せる」方式で埋めようとする試みである。

PWAという用語が指すのは、単一の製品やフレームワークではなく、一連の品質基準を満たしたウェブアプリの状態である点を明確にする必要がある。すなわちReact·Vue·Angularなどどの技術で作ろうと、サービスワーカーでオフラインを支え、マニフェストでインストール可能であり、HTTPSで提供されれば、そのウェブアプリは「PWAになる」。このためPWAは、既存のウェブ資産を捨てずに漸進的に移行·補強できるという実務的な利点を持つ。レガシーサイトにサービスワーカーを一層載せるだけでも再訪時の性能が目に見えて改善される、といった具合である。

「プログレッシブ(progressive)」という名は、漸進的強化(progressive enhancement)の原則から来ている。すなわち旧式のブラウザでは普通のウェブページとして動作し、サービスワーカー·マニフェストを支える最新のブラウザではオフライン·インストールといった上位機能が「漸進的に」加わる。したがってPWAは「できるかできないか」の二分法ではなく、環境が許す分だけ体験を引き上げる優雅なdegradation/enhancement設計を前提とする。この哲学を理解すれば、後述する機能がなぜすべて「選択的追加」として設計されているかが明らかになる。

B. PWAの中核的特性(信頼性·速度·没入性)

PWAの価値は、Googleが提示した三つの品質軸 — 信頼性(Reliable)·高速(Fast)·没入性(Engaging) — に凝縮される。各軸は特定の技術と1対1で結びつくため、特性を理解することがそのまま構成要素を理解する道となる。

信頼性は、ネットワーク状態に関わらず即座に読み込まれる性質である。地下鉄·エレベーター·発展途上国の不安定な3G環境でも、「白い画面」や恐竜のエラーページの代わりに最小限のアプリシェル(App Shell)が表示されることを保証する。これを可能にするのがサービスワーカーのキャッシュ横取りであり、この一点が従来のウェブに対するPWAの最も決定的な差別化点である。実際、ネットワークが遅いほどPWAの効用は大きくなり、このため新興市場(インド·東南アジア)のサービスがPWAを積極的に採用した。

高速は、操作に対する即時の反応を意味する。初回訪問の読み込みだけでなく、再訪時にキャッシュされた資源でほぼ即座にレンダリングし、スクロール·タブ切り替えが60fpsで滑らかに動作しなければならない。GoogleはこれをCore Web Vitals(LCP·INP·CLS)指標で計量化しており、PWA設計はこの指標を満たすよう[[web-performance]]最適化と[[caching-strategy]]を必ず伴う。特にモバイルユーザーは3秒以上読み込むとかなりの割合が離脱するという研究が繰り返し報告されているため、「高速」は見栄えではなくビジネス上の生存の問題として扱われる。

没入性は、ホーム画面インストール、全画面起動、プッシュ通知、スプラッシュ画面などネイティブアプリの体験要素を提供する性質である。ユーザーがブラウザのアドレスバーを経ずアイコンを押して独立ウィンドウに入れるようにすることで、「ウェブサイトを訪問する」ではなく「アプリを使う」という心理的転換を起こす。この没入性が滞在時間·再訪率·転換率といったビジネス指標に直結する点が、PWA導入の核心的な論拠である。

2. PWAの全体構造と中核構成要素

PWAは、既存のウェブアプリケーションの上に三つの中核要素 — サービスワーカー、ウェブアプリマニフェスト、HTTPSセキュアコンテキスト — を組み合わせた階層構造として理解される。ブラウザ·オペレーティングシステム·ネットワークがこれらと噛み合ってインストール·キャッシュ·通知を処理する。下の構造図は、ユーザー端末の中で各構成要素がどのように接続されるかを示す。

graph TD
  USER["ユーザー端末(ブラウザ·OS)"] --> UI["ウェブアプリUI(App Shell)"]
  UI --> SW["サービスワーカー(Service Worker)"]
  UI --> MAN["ウェブアプリマニフェスト(manifest.json)"]
  SW --> CACHE["Cache Storage API"]
  SW --> IDB["IndexedDB(動的データ)"]
  SW --> PUSH["Push API·Notification API"]
  SW --> SYNC["Background Sync"]
  MAN --> INSTALL["ホーム画面インストール·アイコン·スプラッシュ"]
  SW -. リクエスト横取り .-> NET["ネットワーク·オリジンサーバー"]
  CACHE -. オフライン応答 .-> UI
  HTTPS["HTTPS(セキュアコンテキスト)"] --> SW
  HTTPS --> PUSH

A. サービスワーカー(Service Worker) — オフラインの心臓

サービスワーカーは、ウェブページとネットワークの間に位置するプログラム可能なネットワークプロキシであり、ブラウザがバックグラウンドで別スレッドとして実行するJavaScriptである。メインUIスレッドと分離して動作するためDOMに直接アクセスできない代わりに、すべてのfetchリクエストを横取りして「キャッシュから渡すか、ネットワークへ送るか、両者を組み合わせるか」を開発者がコードで決定できるようにする。まさにこのリクエスト横取り能力が、オフライン動作·性能向上の技術的源泉である。

サービスワーカーの最も重要な特徴は、イベント駆動のライフサイクルである。登録(register)→インストール(install、この時に中核資源を事前にキャッシュ)→有効化(activate、旧バージョンのキャッシュ整理)→待機/実行の段階を経て、使用しない時はブラウザが終了させて資源を節約する。この非同期·揮発的な特性のため、状態をサービスワーカーの変数に保持してはならず、永続データはCache StorageやIndexedDBに保存しなければならない。またセキュリティ上HTTPSでのみ動作(localhost例外)するが、これはネットワークを横取りする強力な権限が中間者攻撃に悪用されないようにするためである。

サービスワーカーは単純なキャッシュを超えて、バックグラウンド同期(Background Sync)とプッシュ(Push)まで担う。オフラインでユーザーが作成したリクエストをキューに入れておき、接続が復旧すると自動送信したり(例:オフラインで送ったメッセージ)、サーバーが送ったプッシュをページが閉じていても受信して通知を表示したりする。これにより「アプリを使っていない時も動作する」というネイティブアプリの特性をウェブで実装する。

実務の観点では、サービスワーカー導入の落とし穴は「更新の反映」にある。新バージョンを配布しても既存のサービスワーカーが制御権を握っていればユーザーは旧バージョンを見続けるため、install段階のskipWaiting()とactivate段階のclients.claim()をいつ適用するか、ユーザーが作業中なのに強制的に新バージョンを押し付けてデータが失われないかを慎重に設計しなければならない。一般には新バージョンが準備できたことをUIで知らせ、ユーザーが再読み込みを選べるようにする「更新通知」パターンが安全であり、この点がサービスワーカー運用の最もよくある失敗箇所である。

B. ウェブアプリマニフェスト(Web App Manifest) — インストールの設計図

ウェブアプリマニフェストは、アプリの名前·アイコン·テーマ色·開始URL·表示モード(standalone/fullscreen)などを宣言するJSONファイルである。ブラウザはこのファイルを読み、「このウェブサイトはアプリのようにインストールされる意思がある」と判断し、条件を満たせばインストールバナー(またはアドレスバーのインストールアイコン)を表示する。マニフェストがなければ、いくらサービスワーカーが完璧でもホーム画面インストール·独立起動の体験を与えられないため、マニフェストは「没入性」特性の関門の役割を果たす。

マニフェストのdisplay属性は、ユーザー体験を左右する核心である。standaloneはアドレスバーを隠してネイティブアプリのように見せ、fullscreenはステータスバーまで隠す。start_urlはインストールされたアプリが起動する入口を指定し、ユーザーが常に一貫した画面からアプリを始められるよう保証する。アイコンはさまざまな解像度(192px·512pxなど)を提供して端末ごとに鮮明に表示されるようにし、Androidではマニフェストを基にWebAPKという実際のインストールパッケージが生成され、システムにアプリとして登録される。

ブラウザがインストール可能(installable)と判定する条件は明示的である。有効なマニフェスト(名前·アイコン·start_url·displayを保有)、有効なサービスワーカー(fetchハンドラを含む)、そしてHTTPS提供という三条件がすべて満たされてインストールプロンプトが現れる。開発者はbeforeinstallpromptイベントを横取りし、インストールボタンを適切なタイミング(例:中核機能の体験後)に露出させることでインストール転換率を高められる。無分別な即時インストール要求はかえって離脱を招くため、「価値体験の後にインストールへ誘導する」というUX原則が重要である。このようにマニフェストは宣言的メタデータであると同時に、インストール転換を設計する地点でもある。

C. アプリシェルアーキテクチャ(App Shell)とデータ分離

PWA性能設計の代表的パターンがアプリシェル(App Shell)モデルである。画面の固定骨格(ヘッダー·ナビゲーション·レイアウトなどのUIシェル)をコンテンツと分離してサービスワーカーで先にキャッシュしておき、可変コンテンツだけをネットワークから取得する方式である。再訪時にシェルはキャッシュから即座にレンダリングされるため体感読み込みが劇的に速くなり、シングルページアプリ(SPA)と特に相性がよい。

シェルとデータを分離すれば、キャッシュ戦略も分離して適用できる。頻繁に変わらないシェル·静的資源は積極的に永続キャッシュし、動的データはネットワーク優先またはstale-while-revalidateで鮮度を保つ、といった具合である。この「静的/動的分離」の思考がPWA性能チューニングの出発点であり、後述するキャッシュ戦略選択の基準となる。

D. オフラインデータストア(Cache Storage·IndexedDB)

オフライン体験を完成させるには、「資源キャッシュ」と「構造化データ保存」を区別しなければならない。Cache Storage APIはHTTPのリクエスト·レスポンス対を丸ごと保存するストアで、サービスワーカーがfetchを横取りして応答を保管したり返したりするのに使われる。主にHTML·CSS·JS·画像のような「ファイル性の資源」に適する。一方IndexedDBはキー·値·オブジェクトを基礎とするトランザクション型のブラウザ内データベースで、ユーザーがオフラインで作成したフォームデータ、買い物かご、既読記事一覧のような「構造化されたアプリケーション状態」を保存するのに使われる。両者を混用せず資源の性格に応じて配分することがオフライン設計の基本である。

これらのストアは容量と寿命に制約がある。ブラウザはオリジンごとに割当量(quota)を設け、ディスクが不足すると使用頻度の低いオリジンのデータを自動削除(eviction)しうる。したがって必ず保全すべきデータはnavigator.storage.persist()で永続保存を要求し、オフラインの変更分は接続復旧時にBackground Syncでサーバーと同期しつつ、同時編集の競合(conflict)解消規則(最終書き込み優先、バージョンベクトルなど)をあらかじめ定めておいてこそデータ整合性が保証される。この部分を疎かにすると「オフラインではできたのに、オンライン復帰後にデータがもつれる」という典型的な障害につながる。

3. サービスワーカーのライフサイクルとキャッシュ戦略

サービスワーカーがリクエストをどう処理するかは、キャッシュ戦略(caching strategy)の選択にかかっている。下のフロー図は、登録からリクエスト処理までの過程と、リクエスト時点で戦略に応じて分岐する様子を示す。

flowchart TD
  A["ページ読み込み"] --> B["サービスワーカー登録(register)"]
  B --> C["install: 中核資源の事前キャッシュ"]
  C --> D["activate: 旧バージョンのキャッシュ整理"]
  D --> E["fetchイベントの横取り"]
  E --> F{"キャッシュ戦略の選択"}
  F -->|Cache First| G["キャッシュ応答、なければネットワーク"]
  F -->|Network First| H["ネットワーク応答、失敗時はキャッシュ"]
  F -->|Stale-While-Revalidate| I["キャッシュ即応 + バックグラウンド更新"]
  G --> J["UIレンダリング"]
  H --> J
  I --> J

戦略選択の本質は、「鮮度(freshness)と速度(speed)のトレードオフ」を資源の性格に合わせて調律することである。静的資源のようにほとんど変わらないものは速度を、ニュース·残高のように最新性が生命のものは鮮度を優先すべきである。下の表は代表的な戦略と適用文脈を比較したものだが、実際の設計では「なぜこの資源にこの戦略か」を資源ごとに判断しなければならない。

戦略	動作	長所	適した資源
Cache First	キャッシュ優先、なければネットワーク	最速、オフラインに強い	ロゴ·フォント·アプリシェルなど不変資源
Network First	ネットワーク優先、失敗時はキャッシュ	最新性を保証	ニュース·価格·残高など動的データ
Stale-While-Revalidate	キャッシュ即答 + バックグラウンド更新	速度と鮮度の折衷	アバター·一覧サムネイルなど準動的資源
Cache Only / Network Only	キャッシュのみ / ネットワークのみ	単純·予測可能	プリキャッシュ資源 / 決済API

これらの戦略を手で実装すると境界条件(キャッシュ失効·バージョン管理·容量限度)の処理が難しいため、実務ではGoogleのWorkboxライブラリで宣言的に構成する場合が多い。Workboxはルートごとの戦略マッピング、キャッシュ失効·容量ポリシー、プリキャッシュマニフェストの自動生成を提供し、サービスワーカーコードの複雑度を大きく下げる。例えば画像にはCacheFirst(最大60個·30日失効)、APIにはNetworkFirst(タイムアウト3秒)を一、二行で指定できる。

4. ネイティブアプリ·ハイブリッドアプリ·レスポンシブウェブとの比較

PWAの位置を理解するには、競合·代替技術との違いを「なぜ違うのか」の観点から押さえる必要がある。単純な機能列挙ではなく、配布モデルと技術スタックの違いがどのような実務的含意につながるかが重要である。

ネイティブアプリはSwift/Kotlinなどプラットフォーム専用言語で開発され、ハードウェア·OS機能を最大限活用し性能が最も優れる。しかしiOS·Androidをそれぞれ開発·維持する二重コスト、アプリストア審査の遅延(数時間〜数日)と手数料、ユーザーが数十MBをインストールしなければならない摩擦が存在する。PWAは性能·機能の上限はネイティブより低いが、単一コードベース·即時配布·無インストールアクセスで総所有コスト(TCO)と配布速度において先行する。したがって「極限のグラフィック·ハードウェア性能が必要か」が一次の分岐点となる。

ハイブリッドアプリ(Cordova·Ionicなど)はWebViewにウェブコードを収めてアプリストアで配布する方式で、PWAと「ウェブ技術を使う」点は同じだが配布経路が異なる。ハイブリッドは依然ストア審査·インストールを経る一方、PWAはウェブそのものとしてURL共有·検索露出が可能である。ただしハイブリッドはプラグインでより広いネイティブAPIにアクセスできるため、深層のハードウェア連携が必要なら有利である。React Native·FlutterのようなクロスプラットフォームフレームワークはネイティブUIにコンパイルされて性能がより良いが、ストア配布·別途ランタイムが必要という点でPWAとは趣が異なる。

PWAがネイティブ·ハイブリッドと決定的に分かれるもう一つの地点は、検索エンジン露出(SEO)と共有性である。PWAは本質的にウェブであるため、各画面が固有のURLを持ち検索エンジンに索引され、リンク一つで共有·ディープリンクが可能である。アプリストアの中に閉じ込められたネイティブアプリが「検索→インストール→実行」という長い漏斗を経るのと違い、PWAは検索結果からすぐ入りインストールなしで使い、必要ならインストールにつながる短い経路を提供する。この「無摩擦の流入」がコマース·メディアで転換率を引き上げる構造的理由であり、ネイティブ転換コストが負担となる組織がPWAを先に検討する根拠となる。

レスポンシブウェブ(Responsive Web)とは混同しやすいが層位が異なる。レスポンシブは画面サイズに合わせてレイアウトを調整するCSS中心の適応技法にすぎず、オフライン·インストール·プッシュのようなアプリ機能とは無関係である。PWAはたいていレスポンシブ設計を含むが、その上にサービスワーカー·マニフェストを加えた上位概念である。すなわち「すべてのPWAはレスポンシブでありうるが、レスポンシブウェブがそのままPWAではない」が正確な関係である。この区別を明確にすることが、答案で概念の混同を避ける要領である。

5. 産業適用事例と成果

PWAの効用はグローバル企業の実測指標で立証されている。Twitter(Twitter Lite)は2017年にPWAへ転換し、初期ロード容量をネイティブアプリ(数十MB)比で1MB未満に減らし、セッションあたりのページビュー65%増·離脱率20%減を報告した。データ料金が高い新興市場のユーザーに特に効果が大きかった点が、PWAの「信頼性」の価値をよく示す。

スターバックスはPWAの注文アプリを導入し、容量を既存のiOSアプリの約1/100(数百KB水準)に減らし、オフラインでもメニューの閲覧·買い物かご追加ができるようにして日次の注文ユーザーが2倍に増加した。PinterestはモバイルウェブをPWAで再構築した後、中核の参加指標が60%、広告売上が44%増加し、滞在時間が40%増えたと発表した。国内(韓国)でもコマース·メディアのサービスがインストール摩擦なしで再訪率を高める手段としてPWAを活用し、[[super-app]]戦略と結合して軽量な入口を提供する事例が増えている。

注目すべき点は、これらの指標が単純な「ウェブ最適化」ではなく、PWAの特性がユーザー行動を変えた結果だという点にある。インストール摩擦が消えたことで見込みユーザーが離脱なく流入し(流入)、再訪時に即座に読み込まれるので滞在が増え(参加)、ホーム画面アイコン·プッシュが再訪を誘導して(リテンション)転換·売上につながった。すなわち「信頼性·速度·没入性」という三つの特性がそれぞれ漏斗の別の段階を改善し複合的な成果を生んだのである。この因果構造を答案に盛り込めば、事例を単純な列挙ではなく「特性→行動→指標」の論理で説明できる。

これらの事例の共通点は、「ネットワークが不安定、またはインストール摩擦が転換を阻んでいた区間」でPWAが最も大きな改善をもたらしたことである。逆に高性能ゲーム·複雑なハードウェア連携の領域では依然ネイティブが優勢である。この対比がPWA導入の是非を判断する実務的基準を提供する。

6. 深化:最新動向とプラットフォーム支援の変化

PWAの機能的限界は、Project Fugu(ウェブ機能拡張プロジェクト)を通じて急速に狭まっている。Google·Microsoft·Intelなどが参加するこのイニシアティブは、ファイルシステムアクセス(File System Access API)、Bluetooth·USB·シリアル、連絡先選択、画面スリープ防止(Wake Lock)など、かつてネイティブのみ可能だった機能をウェブ標準APIとして提供する。これによりPWAが扱える領域が、写真編集·IDE·ビデオ会議のような高度なアプリへ拡張している。

性能·品質を客観的に点検する手段も標準化されている。GoogleのLighthouse監査ツールはPWAチェックリスト(インストール可能性·オフライン応答·HTTPS·レスポンシブなど)とCore Web Vitalsを自動測定し、スコアと改善項目を提示するため、開発·運用段階でPWAの成熟度を継続的に管理する基準点となる。これをCIパイプラインに入れ、配布のたびに品質の後退を防ぐことが成熟した運用組織の慣行である。

長らくPWA普及の障壁だったAppleの消極的な支援も次第に改善された。iOSは一時サービスワーカー·プッシュを制限していたが、iOS 16.4からホーム画面に追加されたウェブアプリに対してウェブプッシュ(Web Push)の支援を始めた。ただしEUのデジタル市場法(DMA)対応の過程でホーム画面ウェブアプリの支援をめぐり方針が翻意·調整されるなど、プラットフォーム別の偏差と不確実性は依然残っており、中核機能は必ず機能検出(feature detection)の後にフォールバックを置く設計が求められる。

配布エコシステムの側面では、PWAをアプリストアに登載する経路も開かれた。Microsoftストアは PWAを一級のアプリとして受け入れ、PWABuilderのようなツールはPWAをAndroid(TWA, Trusted Web Activity)·Windows·iOSのパッケージで包んでストアに載せられるようにしてくれる。すなわちPWAは「ウェブとしても、ストアアプリとしても」両面配布が可能になる趨勢である。予想される出題方向としては「PWAの三大構成要素とキャッシュ戦略を説明しネイティブアプリと比較せよ」「サービスワーカーのライフサイクルとオフライン設計を論ぜよ」「企業のモバイル戦略におけるPWA導入の妥当性を評価せよ」などが典型的であるため、構成要素–特性–戦略–比較–事例を一つの流れに貫いて答案を構成する練習が効果的である。

7. 考慮事項および示唆点

適用戦略 — 「アプリ優先」ではなく「文脈優先」: PWAは万能ではない。データ料金·低スペック端末·インストール摩擦が転換を阻むコマース·メディア·新興市場ではPWAが強力だが、高性能グラフィック·深層のハードウェア連携が核心の領域はネイティブが適する。技術士は「アプリかウェブか」の二分法の代わりに、ユーザー文脈·性能要求·配布速度·TCOを総合してPWA·ネイティブ·ハイブリッドを組み合わせるポートフォリオ戦略を提示すべきである。
トレードオフ — 能力と一貫性の限界: サービスワーカーの強力なリクエスト横取りは、誤って設計すると「旧バージョンがキャッシュされ続け更新されない」問題を生む。キャッシュのバージョン管理·失効ポリシー·スキップウェイティング(skipWaiting)戦略を明確に立てねばならず、ブラウザ·OS別の機能偏差(特にiOS)を機能検出とフォールバックで吸収せねばならない。オフラインデータの整合性(同期の競合)も同様に、Background Sync·競合解消ロジックで設計段階に扱うべき課題である。
セキュリティ·プライバシー — HTTPSと権限の均衡: PWAはHTTPSを前提とし、TLS([[quic-http3]]を含む)·セキュリティヘッダー·コンテンツセキュリティポリシー(CSP)が必須である。サービスワーカー·プッシュ·ハードウェアAPIは強力なだけに悪用の危険があるため、最小権限の原則と明示的なユーザー同意、権限要求のタイミング設計が信頼確保の鍵である。キャッシュに機微情報を残さないポリシーも併せて策定すべきである。
組織·運用の観点 — 単一コードベースの得失: PWAの単一コードベースは開発·維持コストを減らすが、その分ウェブ·インストール型·プッシュなど多様な実行文脈を一つのコードですべて考慮せねばならない複雑性を生む。QAはネットワーク状態(オンライン/オフライン/低速)·ブラウザ·インストール有無の組み合わせをすべて検証せねばならず、サービスワーカーの配布は一般の静的配布とキャッシュ寿命が異なるため、リリース戦略·ロールバック手順を別途策定せねばならない。組織はPWA品質チェックリストとLighthouseを基礎としたゲートをパイプラインに入れ、継続的管理体系を備えるのが望ましい。
展望 — ウェブプラットフォームの能力収束: Project Fugu·WebAssembly([[webassembly]])·WebGPUの発展でウェブの機能·性能がネイティブに収束し、PWAの適用範囲は広がり続ける見通しである。同時にアクセシビリティ([[web-accessibility]])·検索露出·インストール体験を併せて引き上げてこそビジネス成果につながる。技術士はPWAを単一の技術ではなく、性能·キャッシュ·セキュリティ·アクセシビリティが噛み合う「現代ウェブアプリ品質体系」の結節点として俯瞰し、組織のマルチプラットフォーム戦略の中でその役割と限界を均衡よく提示できなければならない。

参考資料

Google Developers, "Progressive Web Apps": https://web.dev/explore/progressive-web-apps
MDN Web Docs, "Progressive web apps": https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps
Google, "Service Worker API / Workbox": https://developer.chrome.com/docs/workbox
Chrome Developers, "Project Fugu — Web capabilities": https://developer.chrome.com/docs/capabilities
WebKit, "Web Push for Web Apps on iOS and iPadOS": https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/

一言まとめ: PWAは標準ウェブ技術の上にサービスワーカー·ウェブアプリマニフェスト·HTTPSを組み合わせて信頼性·速度·没入性を提供するウェブアプリであり、サービスワーカーのリクエスト横取りとキャッシュ戦略(Cache First·Network First·SWR)でオフライン·高性能を実装し、単一コードベース·無インストール配布でネイティブアプリと差別化され、Project Fugu·iOSウェブプッシュ·ストア登載で適用範囲が広がる現代ウェブアプリ品質体系の結節点である。