CSSの進化は、ここ数年で完全に別の次元へと突入した。かつてはJavaScriptのDOM操作や重厚長大なライブラリに頼り切っていたページ遷移のアニメーションが、今やブラウザのネイティブ機能として、しかも圧倒的なパフォーマンスで実装できる。その最先端に君臨するのが View Transitions API だ。
そして、その舞台裏でブラウザのレンダリングエンジン（BlinkやWebKit）が裏で何をやっているのかを理解しているか？
「なんとなく動くから」と `view-transition-name` を適当につけて満足しているそこのあなた。今回は、その遷移の魔術の心臓部であり、DOMの幽霊たちを支配する黒幕 `::view-transition-image-pair` 擬似要素 の深淵へと潜る。
ブラウザのメモリ、ペイントのライフサイクル、そして非同期描画の競合に頭を悩ませるシニアエンジニアたちへ向けて、この擬似要素が持つ本当の役割と、現場で踏みがちな地雷の回避策を授けよう。
—
1. そもそも `::view-transition-image-pair` とは何か？
View Transitionが発動した瞬間、ブラウザの内部では何が起きているのか。
ざっくり言えば、ブラウザは遷移「前」のドキュメントのスクリーンショット（厳密にはペイントされたレイヤーのビットマップ）と、遷移「後」の新しく構築されたDOMの初期状態のスクリーンショットという、2枚の画像を生成する。
この「古い画面」と「新しい画面」のペアを包み込むコンテナこそが、`::view-transition-image-pair(
DOMツリー構造としては、ブラウザが自動生成する擬似要素のツリーの最深部に位置し、以下のような階層構造を形成している。
::view-transition
└── ::view-transition-group(root または任意の名前)
├── ::view-transition-image-pair(root または任意の名前) <-- ★ここ！
│ ├── ::view-transition-old(root または任意の名前)
│ └── ::view-transition-new(root または任意の名前)
└── ::view-transition-separators (未来の仕様用など)
この `image-pair` の役割は極めてシンプルかつ強烈だ。それは、「新旧の画像を正確に重ね合わせ、アニメーションのステージング（舞台）を提供する」こと。親である `::view-transition-group` が空間座標やサイズ（getBoundingClientRectのトラッキング）を管理し、その中で `image-pair` がレイヤーの重ね合わせ順（Z-index）とスタイリングの境界線を規定する。
—
2. レンダリング負荷とメモリ効率：なぜこの「ペア」を知る必要があるのか？
実務でView Transitionsを導入する際、最も恐れなければならないのは「メモリの圧迫」と「コンポジット（合成）レイヤーの爆発」だ。
ブラウザは、アニメーションの対象となった要素（またはページ全体）のピクセルデータをGPUのメモリ上にテクスチャとしてアップロードする。この時、`::view-transition-image-pair` の存在を無視して、やたらと多くの要素に `view-transition-name` を付与するとどうなるか？
すべてのペアに対して個別のGPUテクスチャが生成され、VRAM（ビデオメモリ）を猛烈に消費する。特にモバイル端末や、低スペックな組み込みブラウザにおいて、これは一瞬でJank（カクつき）を引き起こし、最悪の場合はタブのクラッシュ（OOM: Out of Memory）を誘発する。
最適化の鉄則：ペアを絞り、合成コストを最小化する
「全部をスムーズに動かしたい」というプロダクトマネージャーの無茶な要求に対し、チーフアーキテクトである我々は、`image-pair` が抱えるピクセルデータのサイズを意識しなければならない。無駄な `view-transition-name` を乱発せず、本当にユーザーの視線を誘導したいHERO要素（メインビジュアルなど）にのみ絞るべきだ。
さらに、`image-pair` 自体に対してCSSのフィルタや変形を適用する場合の注意点がある。
/ 悪い例：image-pair全体に重い処理をかけると、毎フレームのGPU合成に負荷がかかる /
::view-transition-image-pair(hero-card) {
filter: drop-shadow(0 20px 30px rgba(0,0,0,0.5));
mix-blend-mode: multiply; / 合成モードの変更はラスタライズのコストを跳ね上げる /
}
`mix-blend-mode` や複雑な `filter` を `image-pair` やその子孫（`old` / `new`）に指定すると、ブラウザはオフスクリーンキャンバスでの再合成を余儀なくされ、ハードウェアアクセラレーションの恩恵を台無しにする可能性がある。パフォーマンスを極限まで追求するなら、影の表現などは静的な親要素に逃がし、`image-pair` 内では純粋な変形（`transform`）に留めるのがプロの作法だ。
—
3. 非同期の競合とペイントのライフサイクルにおける罠
SPA（Single Page Application）のルーティングにおいて、View Transitions APIを使用する際、最も頭が痛いのが「DOMの更新完了（`updateCallback` の解決）」と「実際のペイント（画像のキャプチャ）」のタイミングのズレだ。
ブラウザは、`document.startViewTransition(async () => { await fetchNewData(); updateDOM(); })` が呼び出された際、コールバックが返すPromiseが解決した「瞬間」に、古い状態のキャプチャと新しい状態のキャプチャの差分を計算し、`image-pair` の中に `old` と `new` を配置する。
ここで、非同期データの取得が遅れたり、Webフォントの読み込みや画像のデコードが完了していない状態でペイントが走るとどうなるか？
`::view-transition-image-pair` の中身には、「まだコンテンツがレンダリングしきっていない中途半端な画面」の画像がキャプチャされてしまう。
バグ回避策：アニメーション開始前のサスペンド制御
この非同期の競合を防ぐためには、DOMの更新だけでなく、「視覚的な準備が完了したこと」をブラウザに保証させなければならない。
// 実務で使える堅牢なView Transitionのラッパー関数
async function transitionPage(updateDOMCallback) {
// 1. 遷移前の事前チェックや、重いアセットのプリロードをここに挟む
if (!document.startViewTransition) {
// API非対応ブラウザへのフォールバック
updateDOMCallback();
return;
}
const transition = document.startViewTransition(async () => {
// DOMを書き換える
await updateDOMCallback();
// 2. 新しいDOMの主要な画像や非同期コンポーネントの描画完了を待つ
// これにより、image-pairに汚い（未ロードの）画像が入るのを防ぐ
await Promise.all([
document.fonts.ready,
imagePreloadCheck()
]);
});
try {
await transition.finished;
console.log(“ビュー遷移が美しく完了しました”);
} catch (error) {
console.error(“ビュー遷移がアボートされました”, error);
}
}
この「`document.fonts.ready` や画像のデコード完了を `updateCallback` の中で待つ」というアプローチをとることで、`::view-transition-image-pair` に渡るピクセルデータの品質を担保し、遷移時の「ガタつき」や「チラツキ（FOUCのような現象）」を完全に根絶できる。
—
4. 実践：`::view-transition-image-pair` を操る高度なスタイリング
デフォルトでは、ブラウザは `image-pair` 内の `old` と `new` に対して、単純なクロスフェード（Opacityのフェードイン・アウト）を適用する。しかし、この `image-pair` というコンテナの特性を理解していれば、クロスフェード以外の野心的なトランジションをCSSだけで構築できる。
例えば、新旧の画像が「スライドしながら交差する」のではなく、「古い画像がめくれて新しい画像が現れる（あるいはその逆）」ようなエフェクトを実装する場合、`image-pair` のサイズやクリッピングパスを制御することが鍵になる。
/ カスタムビュー遷移のアニメーション定義 /
@keyframes slide-from-right {
from { transform: translateX(100%); }
to { transform: translateX(0); }
}
@keyframes slide-to-left {
from { transform: translateX(0); }
to { transform: translateX(-100%); }
}
/ rootの遷移をカスタム /
::view-transition-old(root) {
animation: 0.4s cubic-bezier(0.4, 0, 0.2, 1) both slide-to-left;
}
::view-transition-new(root) {
animation: 0.4s cubic-bezier(0.4, 0, 0.2, 1) both slide-from-right;
}
/
ここで ::view-transition-image-pair の出番。
overflow: hidden を明示的に指定することで、
スライドアウト/インする画像が画面外にはみ出してレイアウトを破壊するのを防ぐ。
/
::view-transition-image-pair(root) {
overflow: hidden;
/ 影やエッジの処理をここに集約 /
box-shadow: 0 25px 50px -12px rgba(0, 0, 0, 0.25);
}
このコードのポイントは、`::view-transition-image-pair(root)` に対して `overflow: hidden` を適用している点だ。
これを忘れると、アニメーションの最中に新旧の画像がコンテナの外側へ盛大にはみ出し、予期せぬスクロールバーが出現したり、画面の端がちらついたりするという、実に泥臭いCSSバグの温床となる。ブラウザのデフォルトスタイルにすべてを委ねず、コンテナの境界（Clipping Context）をエンジニアが手動でコントロールする。これがプロの仕事だ。
—
5. チーフアーキテクトからの提言：これからのCSS設計に向けて
View Transitions API、そしてその内部構造を司る `::view-transition-image-pair` は、単なる「アニメーションを簡単にするための糖衣構文」ではない。これは、Webアプリケーションのレンダリングモデルに対するブラウザベンダーからの挑戦状であり、我々フロントエンドエンジニアが「ピクセルの流れ」をより深く制御するための強力な武器だ。
フレームワークが自動生成するDOMや、便利になりすぎたツールに思考停止で依存する時代は終わった。
ブラウザがどのようなライフサイクルで画面をキャプチャし、どの擬似要素でそれを合成しているのか。その内部挙動の解像度を上げることこそが、ユーザーの心を掴む極上の滑らかさを持ったWebアプリを構築するための唯一の道である。
さあ、エディタを開き、開発者ツールの「CSS擬似要素を表示する」にチェックを入れろ。そこには、君がまだ見たことのない美しく整然としたDOMの幽霊たちが、次の遷移の瞬間を静かに待っているはずだ。
コメント