CSS View Transitions가 웹 성능에 미치는 영향

view transitions가 웹 성능에 영향을 미칠 수 있는 이유와 시기를 이해합니다.

Arjen Karel Core Web Vitals Consultant
Arjen Karel - linkedin
Last update: 2026-02-27

View Transition API가 성능에 미치는 영향

View Transition API를 사용하면 개발자가 동일한 사이트의 뷰 사이에서 부드러운 시각적 전환을 활성화할 수 있으며, 다중 페이지 애플리케이션(MPA)의 경우에도 가능합니다. 이러한 view transitions는 두 페이지 뷰 사이의 CSS 전환으로 처리됩니다. 역사적으로 페이지 로드 중 CSS 전환은 LCP 지표에 지연을 유발했습니다. 우리는 이러한 페이지 간 view transitions 역시 특히 모바일 기기와 느린 CPU에서 성능에 영향을 미칠 것이라고 의심했습니다. 우리의 Real User Monitoring (RUM) 데이터는 이러한 의심을 확인시켜 주었으며, Core Web Vitals, 특히 Largest Contentful Paint (LCP)에 미치는 영향에 대한 흥미로운 통찰력을 제공했습니다.

2026년 2월 Arjen Karel이 마지막으로 검토함

RUM 데이터 분석 결과

view transitions가 Largest Contentful Paint에 부정적인 영향을 미친다는 아이디어를 검증하기 위해, 우리는 5개의 다른 사이트에서 일련의 A/B 테스트를 설정하고 7일 동안 실행했습니다. 페이지 뷰의 50%에는 페이지의 스타일시트에 @view-transition { navigation: auto;}를 추가했고, 나머지 50%의 페이지 뷰는 이 스타일 없이 제공되었습니다.

우리는 50만 건 이상의 페이지 뷰를 수집했으며, 동일한 사이트 내의 모바일 탐색에서 발생했기 때문에 최종적으로 12만 건의 모바일 페이지 뷰를 분석했습니다.

Real-user monitoring 데이터에 따르면 View Transition API를 구현하면 반복되는 모바일 페이지 뷰의 Largest Contentful Paint에 약 70ms가 추가되는 것으로 나타났습니다. 우수한 UX를 위해 페이지가 처음 로드되기 시작한 후 2.5초 이내에 LCP가 발생해야 한다는 Google의 권장 사항을 고려할 때 LCP 시간의 이러한 증가는 주목할 만합니다.

CPU 성능 상관관계

view transitions가 LCP에 미치는 부정적인 영향을 확인한 후 추가 조사를 진행했습니다. view transitions가 있는 페이지와 없는 동일한 2개의 페이지를 자동으로 테스트하기 위한 일련의 실험을 설정했습니다. 결과는 CPU 속도와 view transitions가 LCP에 미치는 영향 사이에 명확한 상관관계가 있음을 보여줍니다. 이 결과는 CPU가 느릴수록 view transitions를 사용할 때 LCP에 미치는 부정적인 영향이 더 두드러진다는 것을 나타냅니다.

설정 View Transition 사용 View Transition 미사용 차이 (ms)
No throttling + network Caching 287 ms 282 ms 5 ms
No throttling + no network Caching 338 ms 311 ms 37 ms
6x CPU slowdown + network Caching 527 ms 523 ms 4 ms
6x CPU slowdown + no network Caching 442 ms 413 ms 29 ms
20x CPU slowdown + network Caching 756 ms 716 ms 40 ms
20x CPU slowdown + no network Caching 1281 ms 1204 ms 77 ms

직접 테스트해보고 싶다면 GitHub의 view transition 실험 홈페이지를 방문하세요.

이러한 결과는 세 가지 주요 관찰 사항을 강조합니다.

  • View transitions는 LCP를 늦춥니다: view transitions가 있는 페이지 뷰는 페이지 전환 효과가 없는 페이지 뷰보다 느립니다.
  • CPU 속도는 중요한 요소입니다: CPU 속도는 페이지 전환 효과가 있는 뷰와 없는 뷰의 LCP 차이와 높은 상관관계가 있습니다. 이는 특히 저사양 모바일 기기에서 중요합니다.
  • 페이지 속도의 '스위트 스폿(sweet spot)'이 있습니다: 6배 감속 시 LCP는 네트워크 캐시 없이 더 나은 성능을 보입니다. 간단한 이유는 이 CPU 속도에서는 네트워크 캐싱 없이 LCP 요소가 아직 디코딩되지 않았고 빈 페이지에 전환이 적용되기 때문입니다. 빈 페이지로 더 간단한 전환을 수행한 직후 LCP 요소가 페인트됩니다. 분명히 이것은 이미지 간에 전환하는 것보다 빈 페이지로 전환하는 것이 더 효율적인 스위트 스폿입니다. 물론 UX 관점에서는 이미지 사이를 전환하는 것이 좋습니다.

브라우저 지원

View Transition API는 2025년 10월에 Baseline Newly Available 상태에 도달했습니다. 동일 문서(Same-document) view transitions는 이제 Chrome 111+, Edge 111+, Firefox 144+, Safari 18+에서 작동하며 전 세계 브라우저 트래픽의 약 89%를 포괄합니다. 교차 문서(Cross-document) view transitions(@view-transition { navigation: auto; }에 의해 트리거되는 전환)는 지원 범위가 약간 좁지만 구형 Firefox 버전을 제외한 모든 주요 브라우저에서 작동합니다.

이러한 광범위한 지원은 더 많은 개발자가 view transitions를 채택하여 성능에 미치는 영향을 더욱 중요하게 만들 것임을 의미합니다.

@view-transition { navigation: auto; } 이해하기

전통적으로 view transitions를 구현하려면 CSS 및 JavaScript를 광범위하게 사용해야 했습니다. View Transition API는 개발자가 선언적으로 전환을 정의할 수 있도록 하여 이 프로세스를 단순화합니다. View Transition API는 문서의 이전 및 새 상태의 스냅샷을 캡처하고, 렌더링을 억제하면서 DOM을 업데이트하며, CSS 애니메이션을 사용하여 전환을 실행하는 방식으로 작동합니다.

구현 예시

다음은 CSS에서 교차 문서(cross-document) view transitions를 활성화하는 방법에 대한 기본 예입니다.

@view-transition {
  navigation: auto;
}

또는 태블릿이나 데스크톱 기기를 타겟팅하는 미디어 쿼리와 조합하여 사용할 수 있습니다.

@media (min-width: 768px) {
  @view-transition {
    navigation: auto;
  }
}

이 간단한 추가를 통해 브라우저는 동일한 출처(origin)의 페이지 간을 탐색할 때 전환을 자동으로 처리할 수 있습니다.

접근성: prefers-reduced-motion

움직임 감소를 선호하는 사용자가 강제로 애니메이션을 보게 해서는 안 됩니다. view transition 규칙을 prefers-reduced-motion 미디어 쿼리로 래핑하세요. 이렇게 하면 해당 사용자에 대한 LCP 페널티도 제거됩니다.

@media (prefers-reduced-motion: no-preference) {
  @view-transition {
    navigation: auto;
  }
}

Speculation Rules로 LCP 비용 제거하기

LCP 페널티 없이 view transitions를 사용하는 가장 좋은 방법은 이를 Speculation Rules API와 결합하는 것입니다. 사용자가 클릭하기 전에 브라우저가 다음 페이지를 미리 렌더링(prerender)할 때, view transition은 이미 렌더링된 두 상태 사이에서 애니메이션을 적용합니다. LCP 요소가 이미 로드되고 디코딩되었으므로 전환은 측정 가능한 지연을 추가하지 않습니다. 미학과 성능 모두에 관심이 있다면 이 조합을 사용해야 합니다.

권장 사항

View Transition API는 탐색 간에 매끄럽고 시각적으로 즐거운 전환을 제공합니다. 이는 이탈률 감소 및 참여도 증가와 같은 비즈니스 지표에 작은 이점을 가져올 수 있습니다. 그러나 특히 저사양 모바일 기기에서는 개발자가 성능에 미치는 영향을 신중하게 고려해야 합니다. 다음은 저의 권장 사항입니다.

  • LCP 예산을 먼저 확인하세요. 모바일 LCP가 이미 2.0초를 초과하는 경우 전환 오버헤드로 70ms를 추가하면 실패에 더 가까워집니다. LCP를 먼저 수정하고 나중에 전환을 추가하세요.
  • Speculation Rules와 결합하세요. 대상 페이지를 미리 렌더링(prerendering)하면 view transitions의 LCP 비용이 완전히 제거됩니다.
  • prefers-reduced-motion을 사용하세요. view transitions를 움직임 감소 미디어 쿼리로 래핑하면 사용자의 기본 설정을 존중하고 애니메이션을 원하지 않는 사용자에 대한 성능 비용을 제거할 수 있습니다.
  • 실제 사용자를 대상으로 테스트하세요. 랩(Lab) 테스트는 방문자가 사용하는 전체 기기 및 네트워크 조건을 캡처하지 않습니다. CoreDash로 A/B 테스트를 실행하여 view transitions를 활성화하기 전후에 LCP에 미치는 실제 영향을 측정하세요.
  • 데스크톱 전용을 고려하세요. 우리의 데이터에 따르면 빠른 CPU를 갖춘 데스크톱 기기는 LCP 영향이 거의 없는 것(5ms)으로 나타났습니다. min-width 미디어 쿼리를 통해 view transitions를 데스크톱으로 제한하는 것은 합리적인 타협안입니다.

About the author

Arjen Karel is a web performance consultant and the creator of CoreDash, a Real User Monitoring platform that tracks Core Web Vitals data across hundreds of sites. He also built the Core Web Vitals Visualizer Chrome extension. He has helped clients achieve passing Core Web Vitals scores on over 925,000 mobile URLs.

진짜 뭐가 느린지부터.

실제 필드 데이터로 Critical Rendering Path를 뜯어봅니다. Lighthouse 리포트가 아니라 우선순위가 매겨진 수정 목록을 드립니다.

감사 받기
CSS View Transitions가 웹 성능에 미치는 영향Core Web Vitals CSS View Transitions가 웹 성능에 미치는 영향