ビュー遷移に関する誤解

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

View Transition API に注目するユーザーが増えているため、この 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 つの古いフレームです。

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

ボーナスに関する誤解: View Transitions API である

ビュー遷移について語るとき、多くの場合「View Transitions API」という用語が使用されます。不正解です。この API は「View Transition API」と呼ばれます(「Transition」は単数形です)。

この誤解は、一部の記事(Google のDCC に関するドキュメントも一時的にそうでした)で誤った用語が使用されていることに起因しています。

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