マルチオリジン サイトでプログレッシブ ウェブアプリを構築する際の課題と回避策。
背景
以前は、マルチオリジン アーキテクチャを使用するメリットがありましたが、プログレッシブ ウェブアプリの場合、このアプローチには多くの課題があります。特に、同一生成元ポリシーでは、サービス ワーカーやキャッシュ、権限などの共有や、複数のオリジンにまたがるスタンドアロン エクスペリエンスの実現に制限が課せられます。この記事では、複数オリジンの利点と欠点について説明します。また、マルチオリジン サイトでプログレッシブ ウェブアプリを構築する際の課題と回避策についても説明します。
複数のオリジンの適切な使用と不適切な使用
サイトがマルチオリジン アーキテクチャを採用する正当な理由はいくつかあります。主に、独立したウェブ アプリケーションのセットを提供する、または相互に完全に分離されたエクスペリエンスを作成する目的で採用されます。使用を避けるべき用途もあります。
メリット
まず、役に立つ理由を見てみましょう。
ローカライズ / 言語: 国コード トップレベル ドメインを使用して、異なる国で配信されるサイトを分離します（例:
https://www.google.com.ar）。または、サブドメインを使用して、異なる地域をターゲットとするサイトを分割します（例:https://newyork.craigslist.org）または特定の言語のコンテンツを提供する場合（https://en.wikipedia.orgなど）。独立したウェブアプリ: 異なるサブドメインを使用して、メインのオリジンのサイトとは目的が大きく異なるエクスペリエンスを提供します。たとえば、ニュース サイトでは、クロスワード ウェブアプリを
https://crosswords.example.comから意図的に提供し、メインのウェブサイトとリソースや機能を共有することなく、独立した PWA としてインストールして使用できます。
デメリット
これらのことを何も行っていない場合、プログレッシブ ウェブアプリを構築する際にマルチオリジン アーキテクチャを使用すると、デメリットが生じる可能性があります。
にもかかわらず、多くのサイトでは、特に理由もなく、または「以前からの」理由で、引き続きこの構造が維持されています。たとえば、サブドメインを使用して、統合されたエクスペリエンスの一部であるはずのサイトの一部を恣意的に分離することがあります。
たとえば、次のパターンは使用しないことを強くおすすめします。
サイトのセクション: サブドメインでサイトのさまざまなセクションを分離します。ニュース サイトでは、ホームページが
https://www.example.comで、スポーツ セクションがhttps://sports.example.com、政治がhttps://politics.example.comなどになっていることは珍しくありません。e コマース サイトの場合は、商品カテゴリにhttps://category.example.com、商品ページにhttps://product.example.comなどを使用する。ユーザーフロー: サイトのさまざまな小さな部分（サブドメイン内のログイン フローや購入フロー用のページなど）を分離することもおすすめしません。たとえば、
https://login.example.comとhttps://checkout.example.comを使用します。
単一オリジンに移行できない場合は、プログレッシブ ウェブアプリの構築時に考慮できる課題と（可能な場合）回避策のリストをご覧ください。
異なるオリジンにまたがる PWA の課題と回避策
複数のオリジンでウェブサイトを構築する場合、統合された PWA エクスペリエンスを提供するのは困難です。主な理由は、同一生成元ポリシーがさまざまな制約を課すためです。1 つずつ見てみましょう。
Service Worker
サービス ワーカー スクリプトの URL のオリジンは、register() を呼び出すページのオリジンと同じである必要があります。たとえば、https://www.example.com のページで、https://section.example.com のサービス ワーカー URL を使用して register() を呼び出すことはできません。
また、Service Worker は、自身が属するオリジンとパスでホストされているページのみを制御できます。つまり、Service Worker が https://www.example.com でホストされている場合、そのオリジンからの URL のみを（スコープ パラメータで定義されたパスに従って）制御できますが、https://section.example.com などの他のサブドメインのページは制御されません。
この場合、回避策は複数のサービス ワーカー（オリジンごとに 1 つ）を使用することです。
キャッシュ
Cache オブジェクト、indexedDB、localStorage も単一のオリジンに制限されています。つまり、https://www.section.example.com から https://www.example.com に属するキャッシュにアクセスすることはできません。
このようなシナリオでキャッシュを適切に管理するためにできることは次のとおりです。
ブラウザのキャッシュを利用: 従来のブラウザのキャッシュに関するベスト プラクティスの使用をおすすめします。この手法では、キャッシュに保存されたリソースをオリジン間で再利用できるという利点もあります。これは、サービス ワーカーのキャッシュでは不可能です。サービス ワーカーで HTTP キャッシュを使用する方法に関するベスト プラクティスについては、こちらの投稿をご覧ください。
サービス ワーカーのインストールを軽量に保つ: 複数のサービス ワーカーを維持している場合は、ユーザーが新しいオリジンに移動するたびに、大きなインストール費用を支払わないようにしてください。つまり、絶対に必要なリソースのみをプリキャッシュします。
権限
権限はオリジンにスコープされます。つまり、ユーザーがオリジン https://section.example.com に特定の権限を付与した場合、その権限は https://www.example.com などの他のオリジンに引き継がれません。
オリジン間で権限を共有する方法がないため、唯一の解決策は、特定の機能（位置情報など）が必要なサブドメインごとに権限をリクエストすることです。ウェブプッシュなどの場合は、Cookie を維持して、別のサブドメインでユーザーが権限を承認したかどうかを追跡し、権限を再度リクエストしないようにできます。
インストール
PWA をインストールするには、各オリジンに、自身を基準とする start_url を含む独自のマニフェストが必要です。つまり、特定のオリジン（https://section.example.com など）でインストール プロンプトが表示されたユーザーは、別のオリジン（https://www.example.com など）の start_url を使用して PWA をインストールすることはできません。つまり、サブドメインでインストール プロンプトが表示されたユーザーは、サブページの PWA のみをインストールでき、アプリのメイン URL の PWA をインストールすることはできません。
また、各サブドメインがインストールの条件を満たしている場合、サイトを移動する際に同じユーザーに複数のインストール プロンプトが表示され、PWA のインストールを求められるという問題もあります。
この問題を軽減するには、プロンプトをメインのオリジンにのみ表示するようにします。ユーザーがインストール条件を満たすサブドメインにアクセスすると、次のように処理されます。
beforeinstallpromptイベントをリッスンする。event.preventDefault()を呼び出して、プロンプトを表示しないようにする。
これにより、サイトの望ましくない部分にプロンプトが表示されないようにしつつ、メインのオリジン（ホームページなど）では引き続き表示できます。
スタンドアロン モード
スタンドアロン ウィンドウでナビゲートしているときに、ユーザーが PWA のマニフェストで設定されたスコープの外側に移動すると、ブラウザの動作が異なります。動作は、各ブラウザのバージョンとベンダーによって異なります。たとえば、最新バージョンの Chrome では、ユーザーがスタンドアロン モードでスコープから移動すると、Chrome カスタムタブが開きます。
ほとんどの場合、この問題を解決する方法はありませんが、サブドメインでホストされているエクスペリエンスの小さな部分（ログイン ワークフローなど）には回避策を適用できます。
- 新しい URL
https://login.example.comは、全画面 iframe 内で開くことができます。 - iframe 内でタスク（ログイン プロセスなど）が完了したら、postMessage() を使用して、iframe から親ページに結果情報を渡すことができます。
- 最後のステップとして、メインページがメッセージを受信したら、リスナーを登録解除し、最後に iframe を DOM から削除します。
まとめ
同一生成元ポリシーでは、一貫した PWA エクスペリエンスを実現するために複数のオリジン上に構築されたサイトに多くの制限が課せられます。そのため、ユーザーに最適なエクスペリエンスを提供するために、サイトを異なるオリジンに分割しないことを強くおすすめします。
すでにこの方法で構築されている既存のサイトでは、マルチオリジン PWA を正しく動作させることが難しい場合がありますが、いくつかの回避策を検討しています。どちらにもトレードオフがあるため、ウェブサイトでどちらのアプローチを取るかはご判断ください。
長期的な戦略やサイトの再設計を評価する際は、マルチオリジン アーキテクチャを維持する重要な理由がない限り、単一オリジンへの移行を検討してください。
技術的なレビューと提案をしてくれた Penny Mclachlan、Paul Covell、Dominick Ng、Alberto Medina、Pete LePage、Joe Medley、Cheney Tsai、Martin Schierle、Andre Bandarra の各氏に感謝します。