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를 지원하지 않는 브라우저에서는 스타일시트를 파싱할 때 CSS 선택이 무시됩니다.
이 접근 방식은 전자상거래에 성공적으로 구현되었습니다. 자세한 내용은 이 우수사례를 참조하세요.
오해 4: 뷰 전환으로 인해 증분 렌더링이 중단됨
보기 전환이 증분 렌더링을 중단한다는 주장이 있습니다. 사실이 아닙니다. 문서 간 보기 전환은 웹의 이러한 기본 측면을 손상하지 않도록 지정되었습니다.
브라우저는 '충분한' 콘텐츠가 있으면 페이지를 렌더링하기 시작합니다. 이는 대부분의 브라우저에서 <head>의 모든 스타일시트를 로드하고 <head>에서 렌더링을 차단하는 모든 JavaScript를 파싱하고 충분한 마크업을 로드한 후에 수행됩니다. 문서 간 뷰 전환은 이를 변경하지 않습니다. 콘텐츠가 포함된 첫 페인트에 필요한 콘텐츠는 변경되지 않습니다. 이 첫 번째 렌더링 후 브라우저는 새로 수신된 콘텐츠를 점진적으로 렌더링할 수 있으며 렌더링합니다.
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'에 유의하세요.
이러한 오해는 DCC에 관한 자체 문서를 비롯해 잘못된 용어를 사용하는 일부 기사에서 비롯됩니다.
올바른 이름을 기억하는 요령은 하나의 View Transition API를 사용하여 하나 이상의 뷰 전환을 만드는 것입니다.