こんにちは。フロントエンドの迷宮をブラウザの描画パイプラインと心中する覚悟で彷徨う、ただのCSSギークです。
さて、近年のWebフロントエンドにおける最大のパラダイムシフトの一つといえば、間違いなく View Transitions API です。SPAの画面遷移だろうが、DOMの完全な置き換えだろうが、あの「滑らかなアニメーション」がネイティブアプリ並みの手軽さで実装できるようになったのは、ブラウザエンジニアたちの執念の結晶と言えます。
しかし、このAPIをプロダクション環境、それも数百万人のユーザーを抱える堅牢なWebアプリケーションに導入しようとした瞬間、私たちは残酷な現実に向き合うことになります。そう、「何も考えずに使うと、GPUを爆発させ、メモリをリークさせ、非同期の競合によってユーザーの眼前に醜い残像を焼き付ける地獄のツール」に変貌するのです。
今回は、そのView Transitionsの核心であり、裏側でDOMの「幽霊（ゴースト）」を支配する最強にして最凶の擬似要素、`::view-transition-old` の制御方法について、ブラウザの描画エンジンの内部挙動レベルから徹底的に解剖していきましょう。
—
1. `::view-transition-old` の正体：DOMの「ゾンビ」をどう飼い慣らすか
まず、ブラウザが `document.startViewTransition()` の発火を検知した瞬間、内部で何が起きているかを正確に理解する必要があります。
ブラウザは、遷移が開始される直前のDOMツリーの見た目を、一種の「静止画（rasterized snapshot）」としてGPU上にキャプチャします。これが `::view-transition-old` の正体です。つまり、ユーザーが操作している実際のDOMはすでに次の状態（新画面）に切り替わっているにもかかわらず、画面上には「過去の亡霊（オールド・スナップショット）」が居座り続けるという状態を作ります。
ここで多くの開発者が陥る最初の罠が、この「亡霊」に対する無自覚なスタイル適用です。
/ やってはいけない典型例 /
::view-transition-old(root) {
animation: 0.5s cubic-bezier(0.4, 0, 0.2, 1) fade-out;
}
このコード、一見すると何の問題もないように見えます。しかし、大規模なWebアプリでこれをやると、低スペックなモバイル端末で確実にフレームレートが落ち（Jank）、場合によってはスレッドをブロックします。なぜか？
ブラウザの合成スレッド（Compositor Thread）は、`::view-transition-old` が生成された瞬間、その要素のテクスチャをGPUメモリにアップロードします。もし対象が `root`（画面全体）であれば、Retinaディスプレイのような高解像度環境では、数メガバイトの巨大なBitmapが瞬時に生成されます。これを安易にアニメーションさせると、GPUのバス帯域を圧迫し、レイテンシの悪化を招くのです。
—
2. メモリ効率とレンダリング負荷の極限最適化
堅牢なアーキテクチャを目指す上級エンジニアとして、私たちは「メモリのフットプリント」と「合成レイヤーのライフサイクル」を完全にコントロールしなければなりません。
`::view-transition-old` をスタイリングする際は、以下の鉄則を遵守してください。
1. アニメーションさせるプロパティは `transform` と `opacity` のみに限定する
`width`、`height`、`top`、`left` などをアニメーションさせると、メインスレッドでレイアウト（Reflow）とペイント（Repaint）が毎フレーム発生し、アプリが死にます。`transform: scale()` や `opacity` を使い、ブラウザの合成レイヤー（Compositor Layer）だけで処理を完結させましょう。
2. `will-change` の明示的な付与による最適化
ビュー遷移中の要素には自動的にレイヤーが割り当てられますが、CSS側から意図を明確に伝えることで、ブラウザの最適化ヒントになります。
実践的な最適化コードの例を見てみましょう。
/ 遷移前の状態（古い画面）の最適化されたフェードアウト＆スケールダウン /
::view-transition-old(page-content) {
/ メインスレッドをバイパスし、GPU合成レイヤーのみでアニメーションを完結させる /
animation-duration: 0.4s;
animation-timing-function: cubic-bezier(0.16, 1, 0.3, 1);
animation-fill-mode: forwards;
animation-name: smart-fade-out;
/ レンダリングエンジンに対する強力なヒント /
will-change: transform, opacity;
}
@keyframes smart-fade-out {
0% {
opacity: 1;
transform: scale(1) translateZ(0); / ハードウェアアクセラレーションの強制 /
}
100% {
opacity: 0;
transform: scale(0.96) translateZ(0); / わずかに縮小させることで奥行き感を演出 /
}
}
ここで `translateZ(0)` を挟んでいるのは、古いブラウザや特定のGPUアーキテクチャにおいて、強制的に専用のコンポジットレイヤーを作成させ、描画のちらつき（Flicker）を物理的にねじ伏せるためのギークな知恵です。
—
3. 非同期の競合と「消えない幽霊」バグの回避策
実務でView Transitionsを導入したエンジニアの9割が直面するのが、「データフェッチや非同期コンポーネントの描画遅延によるアニメーションの破綻」です。
例えば、次のようなシナリオを考えてみてください。
ユーザーがリンクをクリックし、`startViewTransition` が走る。その中で、新しいページのデータがAPIからまだ返ってきていないため、`::view-transition-new`（新しい画面の状態）の中身が空っぽ、あるいはプレースホルダーのままアニメーションが進行してしまう。結果として、古い画面（`::view-transition-old`）が消えた瞬間に突然真っ白な画面になり、その数ミリ秒後にドンとコンテンツが表示されるという、最悪なUXが爆誕します。
これを防ぐためには、フレームワークや非同期処理のライフサイクルとView TransitionsのPromiseを完全に同期させるアーキテクチャが必要です。
// 堅牢な非同期遷移ハンドラーのパターン
async function transitionToPage(url) {
// 1. 新しいページのデータを事前に完全に取得（プリフェッチ＆キャッシュ）
const nextData = await fetchPageData(url);
// 2. DOMの更新準備が整うまでトランジションを開始しない
const transition = document.startViewTransition(async () => {
// DOMを新しい状態に一気に書き換える
appContainer.innerHTML = renderPage(nextData);
// 重要な子コンポーネントの画像やフォントのデコードを待つ
await document.fonts.ready;
await ensureImagesLoaded(appContainer);
});
try {
// 3. 遷移のアニメーションが完了するのを安全に待つ
await transition.finished;
console.log(‘ビュー遷移が美しく完了しました’);
} catch (error) {
// 途中でDOMの例外や中断があった場合のフォールバック
console.error(‘ビュー遷移が中断されました:’, error);
}
}
このアプローチにおいて、`::view-transition-old` は「新しいコンテンツの準備が裏で完全に完了するまでの間、ユーザーの視覚を優雅に繋ぎ止める防壁」として機能します。データフェッチが終わるまで `::view-transition-old` を意図的に長く留めておくような制御（CSSの `animation-delay` やアニメーションの一時停止の組み合わせ）も、この設計であれば美しく成立します。
—
4. 複数要素の個別制御と名前空間のアーキテクチャ
画面全体の遷移だけでなく、リストから詳細画面への遷移（Shared Element Transition）において、`view-transition-name` と組み合わせた `::view-transition-old` の制御は芸術の領域に達します。
ここで注意すべきは、「CSSの命名規則やスコープ管理を怠ると、一意な名前（ID）の衝突によってブラウザがアニメーションをサイレントスキップする」という仕様の罠です。
/ 動的に生成されるカード要素に対する個別指定 /
.item-card-1 {
view-transition-name: card-item-1;
}
/ 遷移前（古い画面）のカードの残り香を制御 /
::view-transition-old(card-item-1) {
/ 縮小しながらフェードアウトする際、重なり順を制御する /
z-index: 100;
object-fit: cover;
/ 遷移元と遷移先の形状が異なる場合のガタつきを防ぐ /
mix-blend-mode: normal;
}
もし複数の要素が同時にアニメーションする場合、ブラウザはそれぞれの擬似要素に対して独立したペイント処理を行います。ここで `mix-blend-mode` や複雑なフィルタ（`filter: blur()` など）を `::view-transition-old` に適用すると、CPU/GPUの負荷が跳ね上がります。どうしてもリッチなエフェクトを入れたい場合は、アニメーション中のみ `pointer-events: none;` を付与し、無駄なヒットテスト（当たり判定の計算）をメインスレッドから排除するのがプロの技です。
—
5. デバッグとフォールバックの極意
最後に、View Transitions未対応のブラウザ（あるいはユーザーが `prefers-reduced-motion` を有効にしている環境）への配慮について触れておきましょう。
どれほど美しい `::view-transition-old` を書き上げても、アクセシビリティを無視した実装は「技術の暴力」でしかありません。
/ モーション軽減の設定が有効なユーザーには、アニメーションを完全に殺す /
@media (prefers-reduced-motion: reduce) {
::view-transition-old(),
::view-transition-new() {
animation: none !important;
}
}
/ ビュー遷移をサポートしていないブラウザのためのプログレッシブ・エンハンスメント /
@supports not (view-transition-name: none) {
/ フォールバック用の独自のトランジション処理をここに記述 /
}
また、開発時には Chrome DevTools の「Animations」パネルや、「Rendering」タブにある「Paint flashing」を活用し、`::view-transition-old` が意図しないレイヤーの再描画を引き起こしていないかを常に監視してください。
—
まとめ
`::view-transition-old` は、単なる「古い画面をカッコよく消すためのCSSプロパティ」ではありません。それは、「過去の状態」という非同期の亡霊をブラウザのGPU上で安全にハンドリングし、ユーザーに極上の滑らかさを提供するための高度なインターフェースです。
メモリ効率を意識し、非同期の競合をコードでねじ伏せ、パフォーマンスの限界を見極める。この擬似要素を完全に手懐けた時、あなたのWebアプリケーションは、単なる「動くサイト」から、触っていて鳥肌が立つような「極上のプロダクト」へと昇華するでしょう。
さあ、エディタを開き、コンポジットレイヤーの息吹を感じながら、最高のトランジションを組み上げてください。
コメント