マルチオリジン サイトでのプログレッシブ ウェブアプリ

マルチオリジン サイトでプログレッシブ ウェブアプリを構築する際の課題と回避策。

Demián Renzulli

公開日: 2019 年 8 月 19 日

以前は、マルチオリジン アーキテクチャを使用することにいくつかの利点がありました。プログレッシブ ウェブアプリの場合、このアプローチには多くの課題があります。特に、同一生成元ポリシーでは、Service Worker やキャッシュ、権限などの共有や、複数の生成元にまたがるスタンドアロン エクスペリエンスの実現に制限が課されます。

複数のオリジンの適切な使用方法と不適切な使用方法を学び、マルチオリジン サイトでプログレッシブ ウェブアプリを構築する際の課題と回避策について説明します。

複数のオリジンの適切な使用と不適切な使用

サイトがマルチオリジン アーキテクチャを採用する正当な理由はいくつかあります。そのほとんどは、独立したウェブ アプリケーションのセットを提供することや、互いに完全に分離されたエクスペリエンスを作成することに関連しています。また、避けるべき用途もあります。

メリット

まず、有用な理由を確認します。

• ローカライズ / 言語: 国別コード トップレベル ドメインを使用して、異なる国で提供されるサイトを分割する（例: 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

Service Worker スクリプトの URL のオリジンは、register() を呼び出すページのオリジンと同じである必要があります。つまり、たとえば https://www.example.com のページは、https://section.example.com の Service Worker URL を使用して register() を呼び出すことはできません。

もう 1 つの考慮事項は、サービス ワーカーは、自身が属するオリジンとパスでホストされているページのみを制御できるということです。つまり、サービス ワーカーが https://www.example.com でホストされている場合、そのオリジンの URL のみを制御できます（scope パラメータで定義されたパスに従います）。ただし、https://section.example.com などの他のサブドメインのページは制御しません。

この場合、唯一の回避策は、複数の Service Worker（オリジンごとに 1 つ）を使用することです。

注意: 複数のサービス ワーカーを登録してアクティブにすると、追加のリソース（メモリ、CPU など）が消費されます。そのため、ユーザーがサイト内を移動する際に必要となるアクティブなサービス ワーカーの数を適切に判断してください。

キャッシュ

Cache オブジェクト、indexedDB、localStorage も単一のオリジンに制限されます。つまり、https://www.example.com に属するキャッシュに、https://www.section.example.com などからアクセスすることはできません。

このようなシナリオでキャッシュを適切に管理するために、次のような方法があります。

• ブラウザのキャッシュを活用する: 従来のブラウザ キャッシュのベスト プラクティスを使用することを常におすすめします。この手法には、キャッシュに保存されたリソースをオリジン間で再利用できるという追加のメリットがあります。これは、Service Worker のキャッシュでは不可能です。Service Worker で HTTP キャッシュを使用する方法のベスト プラクティスについては、こちらの投稿をご覧ください。

• サービス ワーカーのインストールを軽量に保つ: 複数のサービス ワーカーを管理している場合は、ユーザーが新しいオリジンに移動するたびに大きなインストール費用が発生しないようにします。つまり、絶対に必要不可欠なリソースのみをプリキャッシュします。

Service Worker がアクティブになって実行されると、同一オリジン ポリシーによって、Service Worker 内で行われるクロスオリジン リクエストも制限されます。幸い、この問題には推奨される回避策があります。それは、CORS を使用することです（こちらで説明されています）。Service Worker 内でリソースを取得する際に no-cors モードを使用することはおすすめしません。

権限

権限のスコープもオリジンに設定されます。つまり、ユーザーがオリジン https://section.example.com に特定の権限を付与した場合、その権限は https://www.example.com などの他のオリジンには引き継がれません。

オリジン間で権限を共有する方法はないため、この場合の唯一の解決策は、特定の機能（位置情報など）が必要な各サブドメインで権限をリクエストすることです。ウェブプッシュなどの場合、Cookie を保持して、別のサブドメインでユーザーが権限を承認したかどうかを追跡し、再度リクエストしないようにすることができます。

インストール

PWA をインストールするには、各オリジンに、それ自体を基準とする start_url を含む独自のマニフェストが必要です。つまり、特定のオリジン（https://section.example.com など）でインストール プロンプトを受け取ったユーザーは、別のオリジン（https://www.example.com など）で start_url を使用して PWA をインストールすることはできません。 言い換えると、サブドメインでインストール プロンプトを受け取ったユーザーは、アプリのメイン URL ではなく、サブページの PWA のみをインストールできます。

また、各サブドメインがインストール条件を満たし、PWA のインストールを促す場合、同じユーザーがサイトを移動する際に複数のインストール プロンプトが表示されるという問題もあります。

この問題を軽減するには、メインのオリジンにのみプロンプトが表示されるようにします。ユーザーがインストール条件を満たすサブドメインにアクセスした場合:

1. beforeinstallprompt イベントをリッスンする。
2. event.preventDefault() を呼び出して、プロンプトが表示されないようにします。

これにより、サイトの意図しない部分にプロンプトが表示されないようにしながら、メインのオリジン（ホームページなど）にプロンプトを表示し続けることができます。

スタンドアロン モード

スタンドアロン ウィンドウでナビゲーションを行う場合、ユーザーが PWA のマニフェストで設定されたスコープ外に移動すると、ブラウザの動作が異なります。動作はブラウザのバージョンとベンダーによって異なります。たとえば、最新バージョンの Chrome では、ユーザーがスタンドアロン モードでスコープ外に移動すると、Chrome カスタムタブが開きます。

ほとんどの場合、この問題の解決策はありませんが、サブドメインでホストされているエクスペリエンスの一部（ログイン ワークフローなど）には回避策を適用できます。

1. 新しい URL（https://login.example.com）は、全画面の iframe 内で開くことができます。
2. iframe 内でタスク（ログイン プロセスなど）が完了すると、postMessage() を使用して、結果の情報を iframe から親ページに返すことができます。
3. 最後のステップとして、メインページがメッセージを受信すると、リスナーの登録を解除し、iframe を DOM から削除できます。

注意: 前述の手法は、ユーザーがサブドメインでアクションを実行してメインのオリジンに戻る（ログインフローなど）サイトの一部で、UI の変更を軽減するのに役立ちますが、サブドメインでホストされている多くのページ（サイト セクション全体など）を含むパス全体に実装する手法としては効率的ではありません。

注: Trusted Web Activity のコンテキストでは、Digital Asset Links を使用してすべてのオリジンを検証することで、この問題を回避する方法が推奨されています。

まとめ

同一生成元ポリシーは、一貫した PWA エクスペリエンスを実現したい複数のオリジンの上に構築されたサイトに多くの制限を課します。そのため、ユーザーに最適なエクスペリエンスを提供するには、サイトを異なるオリジンに分割しないことを強くおすすめします。

すでにこのように構築されている既存のサイトでは、マルチオリジン PWA を正しく動作させることは困難な場合がありますが、いくつかの回避策を検討しました。それぞれにトレードオフがあるため、ウェブサイトにどのアプローチを採用するかは、状況に応じてご判断ください。

長期的な戦略やサイトの再設計を評価する際は、マルチオリジン アーキテクチャを維持する重要な理由がない限り、単一のオリジンへの移行を検討してください。

技術的なレビューと提案をいただいた Penny Mclachlan、Paul Covell、Dominick Ng、Alberto Medina、Pete LePage、Joe Medley、Cheney Tsai、Martin Schierle、Andre Bandarra の各氏に感謝いたします。