Notionブラウザ版、WebAssembly版SQLite3でページ遷移速度を20％改善　実装時の苦労と教訓とは？：クロスオリジン分離も課題

　セッション間でデータを永続化するために、WASM版SQLite3は「OPFS」（Origin Private File System）を使用している。OPFSは、サイトがユーザーのデバイス上のファイルを安全に読み書きできるようにするための最新のブラウザAPIだ。OPFSを使用することで、ブラウザを閉じてもローカルでデータを保持することができる。

　当初は、シンプルな方法でWASM版SQLite3の導入を検討していたという。ブラウザのメインスレッドとは別に、バックグラウンドでJavaScriptを実行する「Web Worker」の仕組みを用いて、Notionを開いているブラウザタブごとに1つのWeb Workerを設け、各Web Workerでデータをキャッシュする手法だ。

　その手法の実現にOPFSを使用しており、その実装を「sqlite3_vfs」（SQLite3の仮想ファイルシステムのインタフェース）と、SQLite3.43で追加された「SyncAccessHandle Pool VFS」のどちらを通じて行うかを検討した。これらの実装では次の3つの課題が生じた。

• 「クロスオリジン分離」の問題：sqlite3_vfsを通じてOPFSを使用するには、クロスオリジン分離が必要だった。Webインフラストラクチャのさまざまな機能を実現するために多くのサードパーティースクリプトに依存しているNotionの場合、クロスオリジン分離を果たすためには、スクリプトの提供元にコードの変更を依頼する必要があり、非現実的だった
• データの不整合：sqlite3_vfsを通じてOPFSを使用する手法を一部のユーザーに対して有効化した結果、ページ上で誤ったデータが表示されるなど深刻なバグが生じた。複数のタブを開いている際、各タブのWeb Workerが同時にファイルに対して書き込み処理を同時実行することによるデータの不整合が起きていた。応急処置的なアプローチも試みたが、再び本番環境で有効化することは難しくなった
• 1つのタブでしか実行できない：SyncAccessHandle Pool VFSを使用する場合、sqlite3_vfsで起きたデータ不整合の問題は起きないものの、1つのタブでしかNotionを実行できないという問題があった。複数タブでもキャッシュの恩恵を受けるという目的を果たせないため、この手法も適用できなかった

　そこで同社は、「wa-sqlite」プロジェクトの開発者であるロイ・ハシモト氏が提唱した「一度に1つのタブだけがSQLiteにアクセスし、他のタブがSQLiteクエリを実行できるようにするアプローチ」を参考に、解決策となるアーキテクチャを検討したという。

　このアーキテクチャではWeb Workerに加えて、複数のタブやウィンドウ間からアクセスできる「SharedWorker」と、複数のタブやスクリプトが同じリソースにアクセスしないように管理する「Web Lock API」を活用している。

　各タブがWASM版SQLite3に書き込む専用のWeb Workerを持ち、常にアクティブなタブだけがWASM版SQLite3にアクセスできるよう、SharedWorkerがアクティブタグを管理する。アクティブタグが閉じられると、SharedWorkerは新しいアクティブタブを選択する。SharedWorkerがアクティブタブを検出するために、Web Lock APIを活用しているという。

SharedWorkerを活用したアーキテクチャのイメージ（提供：Notion Labs）

　このアーキテクチャにより、実装上の課題を解決できると判断し、SyncAccessHandle Pool VFSと組み合わせてWASM版SQLite3を導入したという。

WASM版SQLite3導入の教訓

　Notion Labsは、パフォーマンス改善を目的にWASM版SQLite3を導入する上で直面した課題を踏まえ、次のように教訓を共有している。

• OPFSは同時実行のための処理を標準で提供していない。開発者はこれを踏まえた上で、設計を検討する必要がある
• Web WorkerとSharedWorkerにはそれぞれ異なる機能があり、必要に応じてこれらを組み合わせることで有用なケースがある
• 2024年春の時点で、高度なWebアプリケーションで完全なクロスオリジン分離を実装することは容易ではなく、特にサードパーティーのスクリプトを使用している場合には困難だ