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)
이 트리에는 여러 스냅샷 쌍이 포함되어 있지만 단일 뷰 전환만 실행됩니다.
현재 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>의 모든 스타일시트를 로드하고, <head>의 모든 렌더링 차단 JavaScript를 파싱하고, 충분한 마크업을 로드한 후에 실행됩니다. 교차 문서 뷰 전환은 이를 변경하지 않습니다. 콘텐츠가 포함된 첫 페인트에 필요한 콘텐츠는 변경되지 않습니다. 이 첫 번째 렌더링 후에는 브라우저가 새로 수신된 콘텐츠를 점진적으로 렌더링할 수 있습니다.
특정 요소가 DOM에 있을 때까지 렌더링을 차단하도록 선택할 수 있습니다. 뷰 전환에 참여하는 요소가 새 페이지에 있는지 확인하려는 경우에 유용합니다.
이렇게 하려면 다음 링크 태그를 사용하세요.
<link rel="expect" blocking="render" href="#elementId">
이렇게 하면 첫 번째 렌더링을 실행할 시기를 결정하는 데 사용되는 브라우저의 휴리스틱이 재정의됩니다. 지정된 요소가 DOM 트리에 있을 때까지 첫 번째 렌더링이 지연됩니다.
이 수동 차단에는 몇 가지 보호 장치가 내장되어 있습니다. 예를 들어 닫는 </html> 태그가 표시되었지만 차단 요소는 표시되지 않으면 렌더링이 더 이상 차단되지 않습니다. 또한 언제든지 차단 속성을 삭제하는 자체 시간 제한 로직을 추가할 수 있습니다.
렌더링 차단은 주의해서 사용해야 합니다. 렌더링 차단의 영향은 사례별로 평가해야 합니다. 기본적으로 blocking=render는 실적 측정항목에 미치는 영향을 측정하여 사용자에게 미치는 영향을 적극적으로 측정하고 평가할 수 없는 한 사용하지 않는 것이 좋습니다.
오해 5: 스냅샷 프로세스가 느리거나 비용이 많이 듭니다.
View Transition API가 새 뷰를 준비하고 스냅샷을 가져오는 동안 이전 뷰는 사용자에게 계속 표시됩니다. 따라서 뷰 전환이 없는 경우보다 사용자가 이전 페이지를 조금 더 오래 보게 됩니다. 그러나 이 지연은 무시할 수 있으며 실제로는 몇 프레임 정도입니다. 예를 들어 Chrome에서 pageswap의 영향은 최대 2개의 비활성 프레임입니다. 하나는 로직을 실행하기 위한 프레임이고 하나는 스냅샷이 합성되고 캐시되었는지 확인하기 위한 추가 프레임입니다.
또한 스냅샷의 데이터는 컴포저이터에서 직접 가져오므로 스냅샷 데이터를 가져오기 위해 실행해야 하는 추가 레이아웃 또는 다시 칠하기 단계가 없습니다.
보너스 오해: 뷰 전환 API
뷰 전환을 이야기할 때 'View Transitions API'를 언급하는 경우가 많습니다. 잘못되었습니다. 이 API는 'View Transition API'라고 합니다. 단수형 'Transition'에 유의하세요.
이 오해는 잘못된 용어를 사용하는 일부 도움말(예: 한때 DCC에 관한 자체 문서)에서 비롯되었습니다.
올바른 이름을 기억하는 요령은 (하나의) 뷰 전환 API를 사용하여 (하나 이상의) 뷰 전환을 만드는 것입니다.