Заблуждения о переходах между видами

View Transition API — это революционный инструмент веб-разработки. Независимо от того, является ли ваш сайт одностраничным или многостраничным, этот мощный API позволяет вам создавать плавные переходы между представлениями, что приводит к нативному опыту, который очаровывает пользователей. В настоящее время доступно в Chrome, а вскоре такие же переходы между представлениями документов будут доступны в Safari.

Поскольку все больше людей начинают изучать API View Transition, пришло время развеять некоторые заблуждения.

Заблуждение 1: API View Transition делает снимки экрана

При запуске перехода представления API делает снимки старого и нового состояния контента. Затем эти снимки анимируются. Хотя вы можете использовать термин скриншот для старого снимка, новый снимок — это не снимок экрана, а на самом деле живое представление узла. Думайте о нем как о замененном элементе.

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

Благодаря этому аспекту живого воспроизведения такие демонстрации работают, видео, полученное из нового снимка, продолжает воспроизводиться, пока происходит смена вида.

Заблуждение 2: Захват более одного элемента приводит к запуску нескольких переходов между представлениями

Когда вы захватываете несколько элементов, процесс моментального снимка захватит все старые и новые состояния. Когда вы захватываете .box в дополнение к элементу :root, вы получаете это псевдодерево:

::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)

Хотя это дерево содержит несколько пар снимков, выполняется только один переход представления.

В настоящее время Chrome ограничен запуском одного перехода представления на документ одновременно. Попробуйте быстро щелкнуть в этой демонстрации, чтобы начать новый переход представления. Вы заметите, что текущий переход заканчивается, когда начинается новый.

Заблуждение 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 при анализе таблиц стилей.

Заблуждение 4: Переходы между видами нарушают пошаговую визуализацию

Есть утверждения, что переходы между представлениями нарушают инкрементальный рендеринг. Это неправда: переходы между представлениями между документами были определены так, чтобы не нарушать этот фундаментальный аспект веба.

Браузеры начинают рендеринг страницы, когда у них есть «достаточно» контента. Это в большинстве браузеров  после загрузки всех таблиц стилей в <head>, разбора всего JavaScript, блокирующего рендеринг, и загрузки достаточной разметки. Переходы между представлениями документов не меняют этого: контент, необходимый для First Contentful Paint, остается неизменным. После этого первого рендеринга браузер может и будет постепенно рендерить вновь полученный контент.

Вы можете заблокировать рендеринг, пока определенный элемент не будет присутствовать в DOM. Это удобно в ситуациях, когда вы хотите быть уверены, что элементы, участвующие в переходе представления, присутствуют на новой странице.

Для этого используйте этот тег ссылки:

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

Это переопределяет эвристику браузера, используемую для определения времени выполнения первого рендеринга: первый рендеринг задерживается до тех пор, пока указанный элемент не появится в дереве DOM.

Эта ручная блокировка имеет некоторые встроенные защитные меры. Например, когда закрывающий тег </html> виден, а блокирующий элемент — нет, рендеринг больше не будет блокироваться. Кроме того, вы можете добавить собственную логику тайм-аута, которая удаляет блокирующий атрибут в любой момент времени.

Очевидно, что блокировку рендеринга следует использовать с осторожностью. Влияние блокировки рендеринга необходимо оценивать в каждом конкретном случае. По умолчанию избегайте использования blocking=render, если только вы не можете активно измерить и оценить ее влияние на ваших пользователей, измеряя влияние на ваши показатели производительности.

Заблуждение 5: Процесс создания моментальных снимков медленный и дорогой

Пока View Transition API подготавливает новый вид и получает его снимки, старый вид остается видимым для пользователя. Из-за этого пользователь видит старую страницу немного дольше, чем без переходов видов. Однако эта задержка незначительна, на самом деле всего несколько кадров. В Chrome влияние pageswap, например, составляет максимум два устаревших кадра: один для выполнения логики плюс один дополнительный кадр для обеспечения того, что снимки были составлены и кэшированы.

Более того, данные для снимков берутся непосредственно из компоновщика, поэтому для получения данных снимка не требуется выполнять дополнительные шаги по компоновке или перерисовке.