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를 사용하여 (하나 이상의) 뷰 전환을 만드는 것입니다.