ビュー遷移に関する誤解

View Transition API は、ウェブ開発のゲーム チェンジャーです。ウェブサイトがシングルページでもマルチページでも、この強力な API でビューをシームレスに切り替えて、ユーザーを魅了するネイティブのようなエクスペリエンスを提供できます。現在は Chrome でご利用いただけます。同じドキュメント表示の移行は、まもなく Safari でもご利用いただけるようになる予定です。

View Transition API を検討する人が増える中、誤解を解くときが来ています。

誤解 1: View Transition API でスクリーンショットを撮る

ビュー遷移を実行すると、API はコンテンツの新旧の状態のスナップショットを作成します。これらのスナップショットは、ドキュメントの「移行の仕組み」セクションで説明されているように、アニメーション化されます。

古いスナップショットには「スクリーンショット」という用語を使用できますが、新しいスナップショットはスクリーンショットではなく、実際にはノードのライブ表現です。置き換えた要素と考えてください。

::view-transition
└─ ::view-transition-group(root)
   └─ ::view-transition-image-pair(root)
      ├─ ::view-transition-old(root) 👈 Screenshot
      └─ ::view-transition-new(root) 👈 Live representation

このライブ要素のおかげで、このようなデモがうまく機能しました。新しいスナップショットから取得した動画が、ビューの切り替え中も再生され続けます。

ビュー遷移の最小限のデモで再生中の動画。ソース

このために使用されるロジックと CSS については、こちらのドキュメントで詳しく説明しています。

誤解 2: 複数の要素をキャプチャすると、複数のビュー遷移が実行される

複数の要素をキャプチャする場合は、スナップショット プロセスで新旧の状態がすべてキャプチャされます。:root 要素に加えて .box をキャプチャすると、次のような疑似ツリーが表示されます。

::view-transition
└─ ::view-transition-group(root)
|  └─ ::view-transition-image-pair(root)
|     ├─ ::view-transition-old(root)
|     └─ ::view-transition-new(root)
└─ ::view-transition-group(box)
   └─ ::view-transition-image-pair(box)
      ├─ ::view-transition-old(box)
      └─ ::view-transition-new(box)

このツリーには複数のスナップショット ペアが含まれていますが、実行されるビュー遷移は 1 つだけです。

現在のところ、Chrome で同時に実行できるビューの移行は、1 つのドキュメントにつき 1 つのみです。このデモではすばやくクリックして、新しいビュー移行を開始してください。新しい移行が開始されると、進行中の移行が最後にスキップされます。

誤解 3: ブラウザ サポートによりビュー遷移を実装できない

多くのデベロッパーは、ビュー遷移が Chrome でのみサポートされているため実装できないのではないかと懸念しています。Safari では現在この問題の解決に取り組んでおり、まもなくリリースされる Safari 18 に含まれる予定です。

それでも、ブラウザのサポートが不安定なためにビュー遷移の実装が妨げられることのないように注意が必要です。ビュー遷移は、プログレッシブな補正に最適です。この手法をコードに追加する方法については、元のドキュメントをご覧ください。

function handleClick(e) {
    // Fallback for browsers that don't support this API:
    if (!document.startViewTransition) {
        updateTheDOMSomehow();
        return;
    }

    // With a View Transition:
    document.startViewTransition(() => updateTheDOMSomehow());
}

ブラウザが同一ドキュメント ビュー遷移をサポートしている場合は、拡充されたアニメーション バージョンが表示されます。お使いのブラウザがこのバージョンに対応しない場合は、最新のバージョンのままです。ビュー遷移をサポートするブラウザが増えるにつれて、この機能が拡充されたバージョンが自動的に表示されるユーザーが増えることになります。

ドキュメント間のビュー遷移についても同様です。サポートされていないブラウザでは、スタイルシートの解析時に CSS のオプトインは無視されます。

この手法は、こちらのケーススタディで詳述されているとおり、e コマースにうまく取り入れられています。

誤解 4: ビュー遷移によって増分レンダリングが中断される

ビュー遷移によって増分レンダリングが中断されるという主張があります。これは誤りです。ドキュメント間のビュー移行は、ウェブのこの基本的な側面を損なわないように指定されています。

ブラウザは、コンテンツが「十分」に達するとページのレンダリングを開始します。これは、ほとんどのブラウザで、<head> にすべてのスタイルシートを読み込み、<head> 内のレンダリングをブロックする JavaScript をすべてパースして、十分なマークアップを読み込んだ後に行われます。ドキュメント間のビュー遷移ではこの点は変わりません。First Contentful Paint に必要なコンテンツは変わりません。この最初のレンダリングの後、ブラウザは新しく受信したコンテンツを段階的にレンダリングします。

特定の要素が DOM 内に存在するまでレンダリングをブロックするよう選択できます。これは、ビュー遷移に関係する要素が新しいページに存在することを確認したい場合に便利です。

これを行うには、次のリンクタグを使用します。

<link rel="expect" blocking="render" href="#elementId">

これは、最初のレンダリングをいつ実行するかを決定するために使用されるブラウザのヒューリスティックをオーバーライドします。最初のレンダリングは、指定された要素が DOM ツリーに存在するまで遅延します。

この手動ブロックには、いくつかの安全保護対策が組み込まれています。たとえば、終了タグ </html> が表示され、ブロック要素が表示されなかった場合、レンダリングはブロックされなくなります。さらに、独自のタイムアウト ロジックを追加して、任意の時点でブロック属性を削除することもできます。

レンダリング ブロックは慎重に使用する必要があります。レンダリングのブロックによる影響は状況に応じて評価する必要があります。デフォルトでは、パフォーマンス指標に対する影響を測定することでユーザーへの影響を積極的に測定し測定できる場合を除き、blocking=render は使用しません。

誤解 5: スナップショット作成プロセスは低速またはコストが高い

View Transition API が新しいビューを準備し、そのスナップショットを取得している間、古いビューは引き続きユーザーに表示されます。これにより、ビュー遷移なしの場合よりも、以前のページの表示時間が若干長くなります。ただし、この遅延はごくわずかであり、実際には数フレーム程度です。たとえば Chrome では、pageswap の影響は、せいぜい 2 つの古いフレームです。つまり、1 つはロジックを実行するために、もう 1 つはスナップショットが合成およびキャッシュされるようにするための 1 つの追加フレームです。

さらに、スナップショットのデータはコンポジタから直接取得されるため、スナップショット データを取得するために追加のレイアウトや再ペイントの手順は必要ありません。

補足: View Transitions API とは

ビュー遷移について述べる際に、「View Transitions API」という用語がよく使われています。この処理は正しくありません。この API は「View Transition API」と呼ばれます。ただし、「Transition」は単数形です。

この誤解は、一部の記事(ある時点では DCC に関する Google のドキュメントを含む)に起因しており、誤った用語を使用しています。

正しい名前を覚えるためのコツは、(1 つの)View Transition API を使用して(1 つ以上の)ビュー遷移を作成することです。