CSS View Transitions がウェブパフォーマンスに与える影響
view transitions がウェブパフォーマンスに影響を与える理由と状況を理解する

View Transition API がパフォーマンスに与える影響
View Transition API により、開発者は同じサイト内のビュー間でスムーズな視覚的トランジションを有効にすることができます。これはマルチページアプリケーション(MPA)でも同様です。これらの view transitions は、2つのページビュー間での CSS transitions によって処理されます。歴史的に、ページ読み込み中の CSS transitions は LCP 指標の遅延を引き起こしてきました。私たちは、これらのページ間の view transitions にも、特にモバイルデバイスや低速な CPU において、パフォーマンスへの影響があるのではないかと推測していました。私たちの Real User Monitoring(RUM)データは、これらの推測を裏付けるとともに、Core Web Vitals、特に Largest Contentful Paint(LCP)に与える影響に関する他の興味深い洞察をもたらしました。
2026年2月に Arjen Karel が最終レビュー

RUM データの調査結果
view transitions が Largest Contentful Paint に悪影響を及ぼすという考えを検証するため、5つの異なるサイトで一連の A/B テストを設定し、7日間実行しました。50%のページビューでは、ページのスタイルシートに @view-transition { navigation: auto;} を追加し、残りの50%のページビューではこれらのスタイルなしで配信しました。
50万を超えるページビューを収集し、最終的に同一サイト内のモバイルナビゲーションに由来する12万のモバイルページビューが分析されました。
Real-user monitoring データにより、View Transition API の実装が、リピートのモバイルページビューにおける Largest Contentful Paint を約 70ミリ秒 増加させることが明らかになりました。優れた user experience のためには、ページの読み込み開始から2.5秒以内に LCP が発生すべきという Google の推奨事項を考慮すると、この LCP 時間の増加は注目に値します。

CPU パフォーマンスとの相関関係
view transitions が LCP に与える悪影響を確認した後、さらに調査を進めました。view transitions の有無で同じ2つのページを自動的にテストする一連の実験を設定しました。結果は、CPU 速度と、view transitions が LCP に与える影響との間に明確な相関関係があることを示しています。この調査結果は、CPU が遅いほど、view transitions を使用した際の LCP への悪影響がより顕著になることを示しています。
| 設定 | View Transition あり | View Transition なし | 差分 (ms) |
|---|---|---|---|
| スロットリングなし + ネットワークキャッシュあり | 287 ms | 282 ms | 5 ms |
| スロットリングなし + ネットワークキャッシュなし | 338 ms | 311 ms | 37 ms |
| CPU 6倍減速 + ネットワークキャッシュあり | 527 ms | 523 ms | 4 ms |
| CPU 6倍減速 + ネットワークキャッシュなし | 442 ms | 413 ms | 29 ms |
| CPU 20倍減速 + ネットワークキャッシュあり | 756 ms | 716 ms | 40 ms |
| CPU 20倍減速 + ネットワークキャッシュなし | 1281 ms | 1204 ms | 77 ms |
ご自身でテストしたい場合は、GitHub 上の view transition 実験ホームページ をご覧ください。
これらの結果は、3つの重要な観察事項を浮き彫りにしています:
- View transitions は LCP を遅延させる: view transitions を伴うページビューは、view transition エフェクトのないページビューよりも遅くなります。
- CPU 速度は重要な要素である: CPU 速度は、ページトランジションエフェクトの有無による LCP の差と高い相関があります。これは特に ローエンドのモバイルデバイス において重要です。
- ページスピードの「スイートスポット」が存在する: 6倍の減速環境では、ネットワークキャッシュがない方が LCP のパフォーマンスが向上します。その単純な理由は、この CPU 速度ではネットワークキャッシュがないと LCP 要素がまだデコードされておらず、空白のページに対してトランジションが適用されるためです。空白のページへのよりシンプルなトランジションの直後に LCP 要素が描画されます。画像間でトランジションするよりも、空白のページにトランジションする方が効率的である、このスイートスポットが存在するようです。もちろん UX の観点からは、画像間でトランジションする方が優れています。
ブラウザのサポート
View Transition API は、2025年10月に Baseline Newly Available ステータスに到達しました。現在、Same-document view transitions は Chrome 111以降、Edge 111以降、Firefox 144以降、Safari 18以降で機能し、世界のブラウザトラフィックの約89%をカバーしています。Cross-document view transitions(@view-transition { navigation: auto; } によってトリガーされるもの)のサポートはやや狭まりますが、古い Firefox バージョンを除くすべての主要ブラウザで機能します。
この幅広いサポートにより、より多くの開発者が view transitions を採用することになり、パフォーマンスへの影響がさらに重要な課題となります。
@view-transition { navigation: auto; } の理解
従来、view transitions の実装には CSS と JavaScript を広範に使用する必要がありました。View Transition API は、開発者がトランジションを宣言的に定義できるようにすることで、このプロセスを簡素化します。View Transition API は、ドキュメントの古い状態と新しい状態のスナップショットをキャプチャし、レンダリングを抑制しながら DOM を更新し、CSS animations を使用してトランジションを実行することで機能します。
実装例
以下は、CSS で cross-document view transitions を有効にするための基本的な例です:
@view-transition {
navigation: auto;
} または、タブレットやデスクトップデバイスをターゲットとするメディアクエリと組み合わせる場合:
@media (min-width: 768px) {
@view-transition {
navigation: auto;
}
} このシンプルな追加により、同一オリジン上のページ間を移動する際、ブラウザがトランジションを自動的に処理できるようになります。
アクセシビリティ: prefers-reduced-motion
視差効果を減らすことを好むユーザーにアニメーションを強制するべきではありません。view transition のルールは prefers-reduced-motion メディアクエリで囲みましょう。これにより、対象ユーザーにおける LCP ペナルティも排除されます。
@media (prefers-reduced-motion: no-preference) {
@view-transition {
navigation: auto;
}
} Speculation Rules を使用した LCP コストの排除
LCP のペナルティなしで view transitions を使用する最善の方法は、それらを Speculation Rules API と組み合わせることです。ユーザーがクリックする前にブラウザが次のページを事前レンダリングすると、view transition は既にレンダリングされた2つの状態間でアニメーションします。LCP 要素はすでにロードされてデコードされているため、トランジションによる測定可能な遅延は発生しません。美しさとパフォーマンスの両方を重視する場合、この組み合わせが推奨されます。
推奨事項
View Transition API は、ナビゲーション間でスムーズかつ視覚的に心地よいトランジションを提供します。これにより、直帰率の低下やエンゲージメントの向上など、ビジネス指標に小さなメリットをもたらす可能性があります。しかし、特に ローエンドのモバイルデバイス において、開発者はパフォーマンスへの影響を慎重に考慮する必要があります。以下に推奨事項を示します:
- まず LCP バジェットを確認する。 モバイルの LCP がすでに2.0秒を超えている場合、70ミリ秒のトランジションのオーバーヘッドを追加すると、目標未達に近づくことになります。まず LCP を改善し、その後で transitions を追加してください。
- Speculation Rules と組み合わせる。 遷移先のページを事前レンダリングすることで、view transitions の LCP コストを完全に排除できます。
- prefers-reduced-motion を使用する。 view transitions を視差効果を減らすメディアクエリで囲むことで、ユーザーの好みを尊重し、アニメーションを望まないユーザーのパフォーマンスコストを取り除くことができます。
- 実際のユーザーでテストする。 ラボテストでは、訪問者が使用するデバイスやネットワーク条件の全範囲を把握することはできません。CoreDash で A/B テストを実行し、view transitions を有効にする前後の LCP への実際の影響を測定してください。
- デスクトップのみを検討する。 私たちのデータによると、高速な CPU を搭載したデスクトップデバイスでは LCP への影響がほとんどない(5ミリ秒)ことがわかっています。
min-widthメディアクエリを使用して view transitions をデスクトップに制限することは、合理的な妥協案です。

