View Transitions API：ブラウザの「魔法」を制御する、モダンUIの極意
やあ。今日は少しエキサイティングな話をしよう。
フロントエンドの現場で「画面遷移でカクつきを消したい」「あの滑らかなモーフィングを実装したい」と一度でも悩んだことがあるなら、`View Transitions API`はまさに君が待ち望んでいた「魔法」だ。
でも、ただ「便利だ」で終わらせてはいけない。このAPIは、ブラウザがレンダリングの裏側で必死に行っている「スナップショットの裏技」を、僕たちが意図的に制御できるようにするためのものなんだ。仕組みを理解すれば、君が書くコードは単なる実装から、ユーザー体験を支配する芸術に変わる。
—
1. ブラウザは何を隠蔽しているのか？
通常、DOMの構造をJavaScriptで書き換えると、ブラウザは「DOMツリー」を更新し、CSSOMと合体させ（Render Treeの構築）、レイアウトを計算し、ペイントする。この一連の流れは瞬時だが、遷移時にDOMがガラッと変わると、ユーザーの目には「唐突な切り替わり」として映る。
View Transitions APIがやっていることは、極めてシンプルかつ強引だ。
1. スナップショットの撮影: `document.startViewTransition()` が呼ばれた瞬間、ブラウザは現在の画面の「スクリーンショット」を撮る。
2. DOMの更新: JavaScriptでDOMを書き換える。この間、ブラウザはレンダリングを一時停止する。
3. 新しいスナップショットの撮影: 更新後の状態を再度撮影する。
4. 合成アニメーション: 二つのスナップショットを「擬似要素」というブラウザの特殊なレイヤーに配置し、CSSでクロスフェードや移動のアニメーションを適用する。
つまり、遷移アニメーション中、ユーザーは見ているのは「本物のDOM」ではなく、ブラウザが生成した「高精細な画像」なんだよ。賢いだろう？
—
2. 現場で使うための最小構成
まずは、SPA（シングルページアプリケーション）の画面遷移で最も一般的な「SPAルーティングでの遷移」を例に見てみよう。
/
- View Transitions API を使ったスマートな画面遷移関数
- @param {Function} updateDOM – DOMを更新する副作用を持つ関数
/
async function transitionView(updateDOM) {
// ブラウザが対応しているか確認。これ大事。
if (!document.startViewTransition) {
updateDOM();
return;
}
// 遷移を開始。このAPIは戻り値として ‘ViewTransition’ オブジェクトを返す
const transition = document.startViewTransition(async () => {
// このコールバック内でDOMを変更する
// ブラウザはここでの変更が完了するのを待ってから「更新後のスナップショット」を撮る
await updateDOM();
});
// 必要に応じて完了を待機できる
await transition.finished;
console.log(“遷移アニメーションが完了しました”);
}
—
3. 擬似要素で「制御の主導権」を握る
View Transitions APIの真骨頂は、CSSの擬似要素にある。`view-transition-name` プロパティを使うことで、ブラウザに「どの要素とどの要素が対応しているか」を教えることができるんだ。
例えば、商品一覧のカードが詳細ページへ拡大するような動きを作りたい場合、CSSはこうなる。
/ 遷移させたい要素にユニークな名前を割り振る /
.product-card {
view-transition-name: selected-product;
}
/
ブラウザはアニメーション中、以下のようなツリー構造を自動生成する
::view-transition
└─ ::view-transition-group(selected-product)
└─ ::view-transition-image-pair(selected-product)
├─ ::view-transition-old(selected-product) // 遷移前の画像
└─ ::view-transition-new(selected-product) // 遷移後の画像
/
ここで重要な知見を一つ。`view-transition-name` は「文書内で一意」である必要がある。 もし複数の要素に同じ名前をつけてしまうと、ブラウザは混乱してアニメーションをスキップする。実務では、動的なIDを使ってインラインスタイルで当てるのが定石だ。
—
4. チーフアーキテクトからの助言：ハマりどころと回避策
最後に、現場で泣きを見ないための注意点を伝授しておく。
- 「無限ループ」の恐怖: `startViewTransition` 内で重いDOM操作を行うと、その間メインスレッドがブロックされる。ユーザー体験を良くするための機能でUIをフリーズさせては元も子もない。DOM操作は極力軽く、非同期処理が必要ならコールバックの前に済ませておくこと。
- iOS Safariの挙動: まだまだブラウザ間の差異はある。`@supports` で機能をチェックし、対応していない環境では「遷移なし（即時反映）」にフォールバックさせるのが、プロのフロントエンドエンジニアとしての優しさだ。
- パフォーマンスの罠: あまりに多くの要素に `view-transition-name` をつけると、ブラウザの合成レイヤーが膨れ上がり、メモリを食いつぶす。本当に「滑らかに見せる必要がある要素」だけに絞るのが、パフォーマンスとUXのバランスを取る鍵になる。
—
まとめ
View Transitions APIは、ブラウザに「今、画面を書き換えてるから、ちょっと待ってて。その間にいい感じの画像を重ねておくから」と指示を出す仕組みだ。
このAPIが登場したことで、僕らは「アニメーションのためにわざわざDOMを複雑にする」という泥臭い作業から解放された。しかし、その裏にあるブラウザのレンダリングパイプラインを意識することだけは忘れないでくれ。
技術は常に進化するが、ブラウザが裏で何をしているかという本質は変わらない。君がこの機能を使いこなせば、プロダクトの質は確実に一段上のレベルへ引き上げられるはずだ。
さあ、エディタを開いて、君のサイトに魔法をかけてみようか。分からないことがあれば、いつでも聞きに来るといい。
コメント