Chrome のインストール基準の見直し

Adriana Jara

Chrome では今後数か月以内にテストを実施し、デベロッパーとユーザー エクスペリエンスの向上を目的として、アプリのインストール条件を簡素化する予定です。この投稿では、今後想定される変化と、テストを実施する理由について説明します。

インストールは 2015 年からモバイルのウェブ機能として提供され、2019 年にはデスクトップ PWA インストールのサポートが追加されました。Chromium ブラウザのインストール機能は、名前やアイコンなどの特定のフィールドを持つマニフェストや、フェッチ ハンドラを持つ Service Worker といった品質基準によって制限されます。

既存のインストール条件の目標は、高品質のユーザー エクスペリエンスに投資するようデベロッパーに奨励し、ソフトウェアをインストールする際にユーザーの期待に応えることです。ただし、この評価基準の要件は、必ずしも質の高いエクスペリエンスを生み出せるわけではありません。たとえば、Service Worker のチェックは、なんらかのオフライン エクスペリエンスがあるサイトを検出するためのプロキシとして意図されていましたが、サイトでは条件を満たすために空のフェッチ ハンドラを持つ Service Worker が追加されています。これはエクスペリエンスを向上させるどころか、ウェブのパフォーマンスに悪影響を及ぼします（最終的に Chrome は空のハンドラを無視することで問題を軽減しました）。

既存の基準では意図した結果が得られないことを考慮し、Google は基準を一部変更してテストしています。最初のステップとして、メニューからインストールするために fetch() メソッドを実装する Service Worker を用意するという要件を削除しました。モバイル版のバージョン 108 以降、パソコン向けのバージョン 112 以降です。

アプリ内でオフライン エクスペリエンスをユーザーに提供するという当初の目標を実現するために、独自のページを実装しないサイト向けにデフォルトのカスタムページをリリースしました。

現時点では、インストール プロンプトを表示するアルゴリズムには引き続き fetch() ハンドラが必要です。この領域では、新しいシグナルを組み込み、ユーザーがアプリをインストールする可能性が最も高いときにプロンプトを表示するよう取り組んでいます。デベロッパーは beforeInstallPrompt() を使用してプロンプトを制御できます。

注: Service Worker は依然としてウェブ テクノロジーのコアであり、優れたキャッシュ戦略を実装してパフォーマンスを改善したり、通知やオフライン エクスペリエンスをカスタマイズしたりするなど、他のエクスペリエンスに必要となります。

Google は、アプリとして利用するウェブサイトをユーザーが決める手段を持たせたいと考えています。このウェブサイトは、アイコンを使用して直接アクセスし、全画面で表示できます。今後のリリースでは、インストール可能にするために、特定のマニフェスト フィールドの要件を削除する予定です。Google は指標とお客様からのフィードバックを慎重に評価し、Chrome の更新後の動作を判断します。

注: 最良のユーザー エクスペリエンスを実現するには、ウェブアプリで short_name または name、icons（マスク可能なアイコンがさらに望ましい）、start_url、display フィールドを使用することを強くおすすめします。これにより、インストール時に最適なエクスペリエンスをユーザーに提供でき、ユーザーのホーム画面やその他のアプリのサーフェスでのブランドの表示方法をコントロールできます。

最後に、Lighthouse PWA のチェックはインストール要件に直接関連しているため、Lighthouse からこのカテゴリを削除することにしました。Google は、ウェブでのインストール エクスペリエンスを最適化するのに最適なツールをデベロッパーに提供することに引き続き取り組んでおり、最適化のチェックと DevTools でのインストール可能なエクスペリエンスのデバッグを引き続き確認できます。

定期的にテストを行うことをおすすめします。ご質問やご不明な点がございましたら、フィードバックをお送りください。