宣言型Webプッシュの詳細

Brady Eidsonと申します WebKit Architectureチームの エンジニアです Webプッシュ通知の最新情報を お届けできることを 嬉しく思っています

プッシュ通知はモダンプラットフォームに 欠かせないものですが モダンWebでも不可欠な要素となっています

Appleでは 2009年のiPhone OS 3から プッシュ通知の開発を始めています この分野では先駆的な取り組みでしたが プッシュ通知はあらゆるモダン プラットフォームにあるべきものでした すぐに macOSや その他のデスクトッププラットフォーム モバイルプラットフォームに追加されました そこからすぐに アプリではプッシュ通知が プラットフォームに組み込まれていることが 前提となりました

私たちは早くからネイティブアプリの プッシュ通知機能の調整を続けてきました デベロッパとユーザー双方にとっての 最適解を見つけるためです プッシュ通知が Webに必要なもので あることは初めからわかっており 細部まで慎重に検討したいと考えました Safari 7でSafariプッシュ通知を 追加しました Safariプッシュ通知は デベロッパが 熱心に採用し ユーザーの反応も良く 私たちはこれはいけると思いました Safariプッシュ通知は Appleの システムとの緊密な連携が必要で 他のブラウザでも実装可能な形での 標準化はできませんでした もちろんすべてのブラウザに プッシュ通知が必要でした Web標準化コミュニティは Webプッシュ通知の取り組みを始め 1、2年後には最初のブラウザが 公開されました

Web標準では JavaScriptの機能に 強い関心が向けられていた時期でした オリジナルのWebプッシュ通知は 100% 記述したJavaScriptコードで実行される きわめて柔軟なシステムとして 設計されていました 私たちはJavaScriptの実行で 最大限の パフォーマンスを引き出すことに 注力していますが 人が記述して保守するコードには バグが入り込みやすいことはソフトウェア エンジニアなら誰もが知っています

最先端の効率性を誇る JavaScriptエンジンで実行したとしても 何かコードを実行すれば 何もしないよりは負荷がかかります

このアプローチのもう1つの問題は プライバシーです Webサイトデータは 閲覧するユーザーを 追跡する手段となるため インテリジェントトラッキング防止機能では オリジナルのWebプッシュに必要な JavaScriptの有効期限が制限されています

iOS、macOS、Safariのプッシュ通知では プッシュメッセージ自体に ユーザーに表示される通知の 標準化された記述が含まれます メッセージの表示にアプリケーション固有の コードの開発や実行は必要ありません

ネイティブアプリなら プッシュ通知を表示するために デバイス上のコードも必要ありません iOSでオフロードされたアプリでも 正常に通知が表示されます

ブラウザにオリジナルのWebプッシュ通知を 追加してみると面白いことがわかりました 標準で柔軟性が確保されていても 多くのWebサイトは解析しやすいJSONで プッシュメッセージを送信しており サービスワーカーのJavaScriptでは 通知を表示するためのAPI呼び出しへの 変換以上のことは行っていません iOS、macOS、Safariプッシュ通知の 長い歴史を振り返っても これはうなずけることです そして ここから単純なアイデアが 導き出されます 事前にJSONで通知を宣言することが 一般的であれば Webプッシュ通知を進化させ ユーザーがどこにいても届けられます

デベロッパがコードを記述する 手順がなくなることで ネイティブアプリが最初から備えているのと 同じメリットを享受できます

宣言型Webプッシュ通知には 使いやすさ 効率性 透明性が備わっています プッシュメッセージを標準化された フォーマットで送信するのと同じように 簡単に使用でき 設定のための コーディングもほとんど必要ありません

私たちはオープンなWebを念頭に設計し 標準化コミュニティとも連携してきました また 未対応のブラウザとの 下位互換性を確保するように 設計しています 宣言型Webプッシュ通知はまさに Webのプログレッシブエンハンスメントです すでにオリジナルのWeb Pushを よくご存知であれば 考え方はほぼ同じです

確立された標準に基づいているため ここでは宣言型Webプッシュ通知の 新しい特徴を中心に説明しながら オリジナルのWebプッシュ通知に ついても振り返ります まずオリジナルのWebプッシュ通知の 概要から始めましょう

ほぼ完全にJavaScriptに依存し インストールされたサービスワーカーの 形態をとります 通知を表示するためのpushイベントを 処理するコードがサービスワーカーに 含まれています

次にプッシュサブスクリプションが必要です これにはサーバがユーザーのブラウザに 到達するために必要な情報が含まれます プッシュメッセージの送信に 使用するURLなどです ユーザーのジェスチャに応じて JavaScriptがプッシュサブスクリプションを リクエストし 後で使用できるように サーバに送信します

通知を送信するタイミングで サブスクリプションのURLを使用して プッシュメッセージを送信します WebKitブラウザでは ネイティブアプリで使用するのと同じ Apple Push Notification Serviceに これを送信しますが サブスクリプションを使用するのに Apple Developerアカウントは不要です

メッセージがブラウザに届くと 対応するサービスワーカーが 検索され 起動されます ブラウザがそのサービスワーカーに対して プッシュイベントを送信します ここにはプッシュメッセージで送信された すべてのデータが含まれます

サービスワーカーがメッセージを解析し JavaScriptで showNotification APIを呼び出して 通知を表示します

その後 ユーザーが通知をタップ またはクリックすると 適切なサービスワーカーが 実行されていなければ ブラウザによって再度起動され notificationclickイベントが送信されます ハンドラで必要な処理として 多くの場合 ウィンドウを開いて URLにアクセスする必要があります

これが 現在のオリジナルの Webプッシュ通知の仕組みです 説明した手順の大部分は JavaScriptで処理されるもので デベロッパが記述し ブラウザで 実行する必要があります

宣言型Webプッシュ通知では JavaScriptを完全には排除できませんが それに近づきます 宣言型Webプッシュ通知でJavaScriptが 必要なのは プッシュサブスクリプションの 取得部分のみです サービスワーカーは不要になっています

宣言型のプッシュメッセージを送信すると 従来と同様にブラウザが受信して解析し 有効なJSONを抽出します

ユーザーに表示される有効な通知が JSONに記述されていることが確認され 自動的に表示されます

また 通知のタップまたはクリックを 自動的に処理する方法は ブラウザがわかっています ブラウザが何を実行すべきかを知る 方法については後ほど説明しますが まずは プッシュサブスクリプションの 取得に必要なJavaScriptです 以前のオリジナルの Webプッシュ通知でのコードと 現在の宣言型Webプッシュ通知の 場合を見てみましょう

オリジナルのWebプッシュ通知を使った ことがある方なら見覚えがあるでしょう

先ほど触れたようにオリジナルの Webプッシュ通知では インストールされた サービスワーカーなしには話が進みません サービスワーカーの登録が済むと PushManagerオブジェクトにアクセスでき ユーザーのジェスチャに応じて プッシュサブスクリプションを リクエストできます

宣言型Webプッシュ通知で プッシュサブスクリプションを取得する コードは従来とほぼ同じですが サービスワーカーが不要であるため ウインドウオブジェクトでも PushManagerを使用できます

ここがすばらしいところです 純粋な宣言型Webプッシュ通知を使用する場合 記述が必要なコードはこれだけです 宣言型Webプッシュ通知ではプッシュメッセージ の標準JSONフォーマットが定義されます こちらは最小限の 有効なメッセージの一例で チームの重要なインフラツールである Browser Pets Webアプリのものです

必須エントリが1つあり ユーザーに 表示される通知が記述されています

この通知では タイトルテキストと ユーザーが通知をタップまたは クリックした時の表示先のURLが 必須となっています

しかし この最初のエントリが宣言型 プッシュメッセージの魔法の値です 必ず web_pushキーに対して 8030の値を設定します

IETFのWebプッシュメッセージに関する オリジナルのRFC標準が8030であり 誰もがこれに対応しているわけでは ありません

先ほど ブラウザを介した 宣言型プッシュメッセージの流れを 説明しました

魔法のキーを探すのは その流れの一部です

ブラウザがプッシュメッセージの JSONを解析しようとして失敗したら どうなるでしょうか その場合 オリジナルのWebプッシュ通知に フォールバックし サービスワーカーを使って メッセージが処理されます

JSONに魔法のキーがない場合もオリジナルの Webプッシュ通知にフォールバックします

プッシュメッセージにJSONが含まれていて 魔法のキーがあっても 有効な通知が記述されていない 場合はどうでしょうか

その場合 ブラウザは単に何もせず メッセージをそのまま破棄します しかし プッシュメッセージが これらすべてのチェックをパスすれば ブラウザは自動的に通知を表示します

通知のタイトルとアクセス先のURLが 有効な通知の最小要件です オリジナルのWebプッシュ通知の 経験があれば 通知を作成する際 JavaScriptにはさらに多くのオプションが あることをご存じでしょう 宣言型Webプッシュ通知では それらすべてがサポートされています

ここでは メッセージの本文と 通知のタグを指定し 可能であれば デフォルトの 通知サウンドを再生するように プラットフォームにリクエストしています これはあくまで一例で W3C標準の NotificationOptionsディクショナリで サポートされているものは すべて対応します

それだけではありません 通知には 未読数などを示す アプリケーションバッジが 付随する場合が多いため 宣言型プッシュメッセージでも 組み込みのアプリバッジの 更新機能がサポートされています

ブラウザで自動的に表示できる通知の数を 考えるとすばらしいものですが 場合によっては 個別のニーズがあり すべてをブラウザだけで 賄えないこともあります

これについては iOSとmacOSでの ネイティブプッシュ通知での学びがあり UserNotificationsフレームワークを 使用するアプリにもしばらく前から この機能があります プッシュメッセージでは必ず 表示されるメッセージを記述しますが アプリでより有益な形に 改善を加えることができます

宣言型Webプッシュ通知でも サービスワーカーによるオプションの 処理の形でこれがサポートされます なぜこれが重要なのでしょうか これは 通知の正確性に関する基準が 非常に高い場合に役立ちます 例えば Browser Petsサーバが ユーザーに未読メッセージ7件の 通知をしていて そのうち3件は既読だと 認識していない場合が考えられます クライアントデバイス上のJavaScriptで 通知を更新できればユーザーに役立ちます

数学的に 通知テキストを含めることが できない場合があります Browser Petsのユーザーは ダイレクトメッセージの送受信に関して 世界クラスのエンドツーエンドの 暗号化を期待します クライアントデバイス上の鍵が 通知を復号する唯一の手段になります どういうことか見てみましょう 通常のBrowser Petsのダイレクト メッセージでは 通知のJSONは このようになっています

JSONには 送信者のデバイス上で 暗号化されたデータが含まれています このデータの暗号化を解除する鍵が ユーザーのデバイスにあり 暗号化解除には オプションのサービスワーカーを使用します

このJSONには mutableをtrueに設定する エントリも含まれています ほとんどの宣言型プッシュメッセージは 自動で処理されますが この通知はサービスワーカーで 処理する必要があることを このエントリがブラウザに伝えています

これがダイレクトメッセージの暗号解除に Browser Petsで使用されるJavaScriptです

サービスワーカーに プッシュイベントハンドラを渡しました これは オリジナルのWebプッシュ通知の 必須要件として行うのと同様です

1つ新しいこととして ディスパッチされるイベントが mutableと指定されたプッシュに よるものである場合 宣言型のJSONで提示された通知のコピーが イベントに含まれます

この通知を精査することにより ダイレクトメッセージであることと 暗号化されたデータにアクセスする 方法がわかります

宣言型Webプッシュ通知の フローチャートを思い出してください 通知の記述の検証後に ブラウザは mutableのエントリを検索します

エントリがないかfalseであれば ブラウザは自動的に通知を表示します

trueでサービスワーカーが 代替の通知を提示する場合 ブラウザはプッシュメッセージの プレーンテキストではなく 代替の通知を使用します

サービスワーカーが ダイレクトメッセージの暗号解除に成功し 提示された通知を置き換えた場合 ブラウザはこの暗号が解除された メッセージを表示します

ただし メッセージの暗号解除に失敗し 代替の提供ができない場合 元のプレーンテキストの通知が使用されます

プライバシー機能によって サービスワーカーが削除されているか デバイスでリソースに過負荷が かかっているなどの理由で サービスワーカーを起動できない場合にも 宣言型の通知が使用されます 宣言型Webプッシュ通知でのオプションの サービスワーカーJavaScriptの使い方は オリジナルのWebプッシュ通知で必要な サービスワーカーの場合と同様です ここからが お話ししたいところです 下位互換性について説明します

現在 オリジナルのWebプッシュ通知は 主要ブラウザエンジンで広くサポートされ すでに多くのWebサイトで使われています 宣言型Webプッシュ通知が広く採用されれば あらゆる人にメリットがありますが 採用が容易であると同時に すべてのブラウザで通知を利用できる ことも重要です すでにオリジナルのWebプッシュ通知を 使用し シンプルなJSONの解析を行って 通知を表示したことがある方の多くは ニーズの拡大と利用者の増加に伴い 段階的にプッシュメッセージの フォーマットを変化させてきたことでしょう Browser Petsも年月をかけ そうして開発されてきました WebKitチームの宣言型Webプッシュ通知が 軌道に乗ると Browser Petsでこれを活用して 可能な限り効率性と信頼性に優れた通知を 実現したいと考えました ただし当然 すべてのブラウザで機能する プッシュ通知でなければなりません どうアップデートしてきたかをお話しします

このBrowser Petsの通知のJSONは 時間とともに有機的に進化してきました

最初は 通知のタイトルテキスト のみが含まれていました

もとは通知をクリックすると必ずメインの Browser Petsアプリが開かれていましたが このclickURLエントリが追加され 通知の クリック時の行先が指定できるように なりました

次に 通知本文のテキストが重要だと 考えるエンジニアがいました

次の変更点は 私が責任を負っているものです 可能な場合は 通知でシステムのアラート サウンドを再生するのは私のアイデアでした

次のエンジニアが考えたのは 基本的に通知の設定には Web標準の NotificationOptionsディクショナリを 使用しているため これを明示的にコードに含めることでした もちろん 逆行して以前のオプションを 更新することはありません

このアドホックなJSONフォーマットには showNotificationのAPI呼び出しを 構成する要素がすべて含まれていますが ただ名前と構造が異なります

これを 宣言型の標準フォーマットに 合わせて再構成するのは簡単でした

各プロパティの名前を NotificationOptionsディクショナリで 使用されている標準の名前に 変更するのも簡単でした

魔法のキーを追加して 宣言型プッシュメッセージであることを ブラウザに伝えると サポート対象の新しいブラウザでは 自動的に通知が行われます

先ほどのアドホックのJSONに戻ります オリジナルのWebプッシュ通知では プッシュメッセージはフローの一部に過ぎず サービスワーカーでの対応が必要です こちらはオリジナルのBrowser Petsの サービスワーカーです JSONに埋め込まれた引数は 名前を指定して引き出す必要があり 後でshowNotificationを呼び出すために NotificationOptionsディクショナリを 構築する必要がありました

宣言型プッシュメッセージがどうなって いるか改めて確認しましょう

設計上 通知を記述する 宣言型メッセージの重要な要素は それ自体が有効な NotificationOptionsディクショナリです 有効な宣言型JSONになるように プッシュ メッセージのフォーマットを変更すると それを処理できるようにサービスワーカーの コードを書き直すのは非常に簡単です

JSONからnotificationメンバーを取り出し タイトルを抽出して そのままshowNotificationに渡します

プッシュメッセージのJSONとサービス ワーカーのプッシュイベントハンドラを リファクタリングすると どのブラウザでも Webプッシュメッセージを利用できます

宣言型Webプッシュ通知をサポートする ブラウザでは確実かつ効率的に処理されます

宣言型Webプッシュ通知をまだ サポートしていないブラウザでは オリジナルのWebプッシュメッセージと同様 記述したJavaScriptを介して処理されます 宣言型Webプッシュ通知が皆さんの お役に立てることを楽しみにしています macOSのSafari 18.5以降や iOS 18.4およびiPadOS 18.4以降の ホーム画面に保存したWebアプリで 試してみてください

アプリで初めてWebプッシュ通知を サポートする場合 最初から宣言型のフォーマットを 利用することができます すでにWebプッシュ通知を使用しているなら 今こそ移行を始めるべきときです 従来のSafariプッシュ通知の フォーマットは それ自体が宣言型なので そこからの移行は非常に簡単です 導入の際には このセッションに 関連するリソースを手元に置き Web標準化コミュニティやWebKitプロジェクト へのフィードバックがあればお寄せください

これらのセッションでも ブラウザでのWebプッシュ通知の概要や 今年のSafariおよびWebKitの新機能の 詳細について説明していますので ご覧ください

ご視聴ありがとうございました