View Transitions API：DOMの「物理的束縛」から脱却するためのアーキテクチャ論
Webブラウザという巨大なエンジンが、HTMLの断片を読み込み、CSSの計算を経てピクセルへと変換するそのプロセスは、現代の錬金術だ。だが、我々エンジニアが長年苦しめられてきたのは、DOMの更新に伴う「瞬き」だ。ページ遷移のたびに白く点滅する画面、唐突に切り替わるレイアウト。これを解決しようと、我々は長年、複雑なJavaScriptのライブラリや、重たいCSSアニメーションの計算にリソースを割いてきた。
しかし、`View Transitions API`の登場は、単なるアニメーションの糖衣構文ではない。これはブラウザのレンダリングパイプラインを「一時停止」し、スナップショットを撮り、メモリ上で再構成するという、極めて野心的なアーキテクチャの変更なのだ。
—
1. ライフサイクル：レンダリングパイプラインの「一時停止」というマジック
View Transitions APIが最も優れている点は、「ブラウザのレンダリングを一時的にフリーズさせる」という設計思想にある。
`document.startViewTransition()`が呼び出された瞬間、ブラウザは何をするのか。
1. 現在状態のキャプチャ: ブラウザは現在のレンダリング状態をメモリ内にビットマップとして保持する。これはVRAM上に置かれるため、CPU負荷を最小限に抑えたまま「静止画」として扱われる。
2. DOMの更新: コールバック関数が実行され、DOMが書き換わる。しかし、ブラウザはまだ再描画しない。
3. 新状態のキャプチャ: 新しいDOM状態をレンダリングし、もう一つのビットマップを生成する。
4. 擬似要素ツリーの構築: ブラウザはメモリ上に、特殊な擬似要素ツリーを構築し、旧状態と新状態の画像をオーバーレイさせる。
この間、JavaScriptの実行はブロックされないが、レイアウトの計算とペイントは完全に制御下に置かれる。これが、かつて無理ゲーだった「ページ遷移中のスムーズなアニメーション」を可能にする根幹だ。
—
2. 擬似要素による制御：魔法の裏側
ブラウザは、遷移時に以下の擬似要素を自動生成する。
- `::view-transition`: 遷移全体を覆うルート要素。
- `::view-transition-group()`: 各要素のグループ。
- `::view-transition-image-pair()`: 新旧画像ペア。
ここで重要なのは、`view-transition-name`プロパティだ。これは単なるクラス名ではない。ブラウザの compositor（合成スレッド）に対して、「この要素は一意である」と宣言するIDだ。もし複数の要素に同じ名前を振れば、レンダリングパイプラインはクラッシュするか、予期せぬ挙動を示す。これはメモリ上の参照管理に関わるため、開発者は責任を持って一意性を担保しなければならない。
// 堅牢な遷移実装の例
async function navigateWithTransition(targetUrl) {
// ブラウザがサポートしているか確認。非対応ブラウザで死なないための鉄則
if (!document.startViewTransition) {
window.location.href = targetUrl;
return;
}
const transition = document.startViewTransition(async () => {
// ここでDOMを更新する。Reactなら stateの更新、VanillaならinnerHTMLの置換など
await updateDOM(targetUrl);
});
try {
await transition.finished;
console.log(“遷移完了。メモリ上の旧スナップショットは解放済み”);
} catch (e) {
console.error(“遷移中に競合が発生した可能性あり”, e);
}
}
—
3. パフォーマンスと落とし穴：上級者のための最適化
このAPIは強力だが、安易に使うとメモリを食いつぶす。
メモリ効率の観点
スナップショットはビットマップ画像としてGPUメモリを消費する。巨大なDOM要素を遷移させようとすれば、それだけVRAMを専有する。`view-transition-name`をページ全体に安易に割り当てるのは避け、必要な要素だけに絞り込むのがプロの嗜みだ。
非同期の競合
`document.startViewTransition`は、コールバックが完了するまで次のフレームを描画しない。もしコールバック内で重いネットワークリクエストや、巨大なデータパースを行うと、ユーザーは「ブラウザが固まった」と感じるだろう。データフェッチは遷移を開始する「前」に完了させ、コールバック内は「DOMの書き換え」のみに専念させるのが、ユーザー体験を損なわない鉄則だ。
重大なバグ：レイアウトシフトの回避
遷移アニメーション中に親要素のサイズが動的に変わると、擬似要素のバウンディングボックス計算が追いつかず、描画が崩れることがある。これを防ぐには、遷移させる要素に `contain: layout` や `contain: paint` を付与し、レイアウト計算のスコープを限定しておくことを強く勧める。
—
最後に：なぜ我々はこれを使うのか
View Transitions APIは、Webを「ドキュメントの羅列」から「アプリケーションの体験」へと進化させるための強力な武器だ。しかし、このAPIの真価はアニメーションの美しさではない。「ブラウザのレンダリングプロセスに深く介入できるようになった」という点にある。
仕組みを知ることは、不具合を恐れることではなく、不具合の「理由」を予測できるということだ。VRAMの負荷、合成スレッドの処理、CSSの擬似要素のスタック。これらを頭の中でシミュレートしながらコードを書くとき、あなたのWebアプリケーションは、単なるWebサイトから、OSレベルの振る舞いに近い洗練されたインターフェースへと変貌するはずだ。
さあ、DOMの制約から解放された、新しいUIの設計を始めよう。
コメント