はじめに
2021 年 8 月 25 日、ついに Firebase SDK @9.0.0 がメジャーリリースされました。 晴れて安定版がリリースされたことで、今後 V9 モジューラー SDK への移行が加速するでしょう。
さて、V9 モジューラー SDK は、主にバンドルサイズの削減を目的としたリリースでした。 コードベースは、クラス型の記述スタイルから、関数へ移行しました。 これにより、バンドラーのツリーシェイキングを最大限生かせるようになりました。
Firebase Authentication に関しては、最大でバンドルサイズを 70%程度削減することができるようです。 どの程度バンドルサイズが削減されたかについては、Firebase のモジュラー SDK でバンドルサイズ比較 を確認ください。
ただ、残念ながら依然としてサイズ問題は存在します。
例えば initializeAuth
という関数は、 firebase/auth
モジュールを使用する際必ず行う初期化関数ですが、
この関数だけでおよそ 90kb
程度あります。
今回は、Firebase Authentication を Service Worker で使い、パフォーマンス改善の方法を紹介します。
Firebase Authentication の認証の種類
Firebase Authentication では、認証として主に2つの種類があります。 この分類は、認証タイミングと能動関係の違いを表しています。
- ユーザー認証
- 匿名認証
ユーザー認証
ユーザー認証は、ユーザーが能動的に行う認証です。メールアドレスや認証プロバイダーを使用して認証を行います。
Firebase Authentication のモジュールを読み込むタイミングは、ユーザーが submit
するか、
認証専用ページをリクエストしたタイミングまで遅延することができます。
Service Worker によるセッション管理 ではバックエンドが存在するアプリケーションを例に、Service Worker を利用する方法を紹介しています。
匿名認証
匿名認証を行うタイミングは、構成によって様々でしょうが、基本的に受動的に行われます。 多くの場合、ページの読み込み時でなくとも良く、ユーザーインタラクション1後でも問題ないでしょう。
また、認証自体の処理は、UI を伴う必要性が薄いです。 この場合、メインスレッドで認証処理を行うのではなく、バックグラウンドスレッドに処理を移行できます。
バックグラウンドスレッドで処理を行うことで、UI を妨げることなく処理を実行できます。 また、基本的には CWV2が向上します。
Service worker で Firebase Authentication を使う
今回の目的はパフォーマンス改善です。 initializeAuth
をメインスレッドで行わないことでパフォーマンスを改善させます。
Service Worker での Firebase SDK は モジュールバンドラーを使い、バンドルすることを前提に解説します。
CDN から importScripts
を用いて読み込む場合は適宜読み替えてください。
加えて、認証情報の永続化には Indexed DB
が利用されます。 Indexed DB
が実装されていないブラウザは利用できないため注意してください。
まず、既にある場合は不要ですが、Firebase SDK をインストールします。
今後、sw.ts
という一つのファイルで説明しますが、実際は適宜ファイル分割をしてください。
続いて、firebase/auth
を初期化します。
Service Worker は大きな特徴として http リクエストのプロキシとなることが挙げられます。
fetch
イベントにアタッチすることで、http リクエストをハイジャックできます。
これを利用し、特定のリソースに対するリクエストの際、 認証情報をヘッダーへ付与することができます。 匿名の認証情報を付与する場合は、次のようになります。
ここでは、特定のオリジンに対して、認証トークンを付与しています。
サインインと、トークンを付与したリクエストオブジェトを作成するヘルパー関数を作ると便利です。
Request
オブジェクトの headers
は読み取り専用なので、 Headers
オブジェクトは新たに作成しなければならない点に注意が必要です。
また、fetch
イベントリスナーは iframe
などのサードパーティへのリクエストもハイジャックするため、全てのリクエストに認証情報を付与するべきではありません。
例では、Cloud Firestore のエンドポイントに対してのみ認証トークンを付与しています。
Service Worker をすぐにアクティベートする
Service Worker がすぐにアクティベートされるように設定します。 Service Worker は登録されたあと、ページがもう一度読み込まれるまで有効化されません。
認証は Service Worker 登録後すぐに使いたい機能なため、Clients.claim()
メソッドを使い、登録後すぐにアクティベートします。
あとはフロントエンドから、Service Worker を登録するだけです。
Service Worker をビルドする
上の例は、 TypeScript と NPM モジュールを利用しています。 ブラウザで利用するためには、TypeScript はトランスパイルが必要ですし、 NPM モジュールはバンドルしなければなりません。
理想的には、メインバンドラーに Service Worker のビルドも任せたいところです。 しかし、残念ながら Service Worker のモジュールのバンドルまでサポートしているものは少ないです。
その実情を踏まえて、esbuild
を使って別プロセスでビルドする方法を例示します。
Web workers は別スレッドで動作するため、メインビルドとは切り離してビルドプロセスを構築できます。
まず、 esbuild
をインストールします。
esbuild
は CLI で動作するコマンドを提供しているため、それを利用します3。
outdir
に メインビルドの出力先のルートディレクトリを指定します。
これでバンドル済みの Service Worker ファイルが出力されます。
あとはフロントエンドから Service Worker の登録をします。
これで Service Worker が利用できるようになりました。
開発環境でも Service Worker をテストするためには、ビルドプロセスの工夫が必要です。 詳しくは build.ts を参考にしてください。
匿名認証で Cloud Firestore を使う
匿名認証を導入する背景には、多くの場合 Cloud Firestore を利用していることでしょう。 現状は、認証部分だけワーカースレッドへ移行しました。
ここで問題なのは、 uid
を取得するタイミングです。
Cloud Firestore で uid
をドキュメントの ID として管理するパターンは王道です。
その場合、事前に uid
を知る必要があります。
現状では、 Service Worker が fetch
イベントを取得したタイミングでしか uid
を知る方法がありません。
Indexed DB から取得する方法も一応ありますが、一度 fetch
イベントが発生しなければなりません。
さて、この問題を解決するために postMessage
を使って、service worker とメッセージングします。
Service Worker とメッセージングする
まず、現状を整理すると次のようになります。
ユーザーがメインスレッドから fetch
したタイミングでは、まだ uid
を知ることができません。
これは uid
を含むクエリが発行できないことを意味しています。
Service Worker とメインスレッドとは、 postMessage
を利用しメッセージのやり取りができます。
fetch
以外の別のタイミングで uid
をやり取りしてみます。
Service Worker では、message
イベントを登録することで、クライアントからのメッセージを待ち受けます。
postMessage
を使い、クライアントにメッセージを送信します。ここでは uid
を送信しています。
残念ながら postMessage
を使って送信できるメッセージには制限があります。
構造化複製アルゴリズム を使って、JavaScript オブジェクトを複製できるもののみが送信できます。
例えば、メソッドを持つクラスオブジェクトは送信できません。そのため、ここでは uid
のみを送信しているわけです。
クライアント側では、次のようにメッセージの送受信をします。
active な Service Worker に対して、 postMessage
でメッセージを送信します。
Service Worker からのメッセージは、 message
イベントで取得できます。
これで uid
を取得できました。このやり取りは非同期なため、Cloud Firestore へリクエストする際は、 uid
が取得できるまで待機するか、
リクエストの前に毎回上の処理を行うなどの対応が必要になります。
おわりに
パフォーマンスの観点からは、理想的には UI を伴わない処理はすべてワーカースレッドへ移行することが望ましいです。 しかし、往々にしてパフォーマンスの最適化と引き換えに複雑性をもたらします。
上の方法だけでなく、実は firebase/firestore
モジュールを Web worker で使う方法もあります。
またの機会に、 Web worker と Cloud Firestore について書きたいと思います。
Edit this page on GitHub