게시일: 2026년 4월 20일
Chrome은 올해 안에 이전에 실험했던 소프트 탐색 API를 출시할 계획입니다. 이를 위해 Chrome 147부터 Chrome 149까지 오리진 트라이얼을 한 번 더 제공합니다. 이 평가판에서는 이전 평가판의 의견을 API의 예상 최종 형태에 통합합니다. 이 기능에 관심이 있는 웹사이트 소유자는 출시 전에 API의 예상되는 최종 형태를 최종 테스트해 보시기 바랍니다.
소프트 탐색이란 무엇인가요?
'소프트 탐색'은 JavaScript가 탐색 (예: 링크 클릭)을 가로채고 새 페이지를 로드하는 대신 기존 페이지의 콘텐츠를 업데이트하는 경우를 말하며, 이때 URL은 주소 표시줄에서 계속 업데이트됩니다. 사용자에게는 이러한 탐색이 기존 탐색과 동일하게 표시되지만 브라우저의 관점에서 페이지는 여전히 원래 페이지입니다.
소프트 탐색 API의 필요성
Soft Navigations API는 단일 페이지 애플리케이션 (SPA) 사이트에서 사용하는 소프트 탐색을 감지하기 위해 제안된 API입니다. 소프트 탐색에서는 실제 페이지 탐색이 발생하지 않으므로 JavaScript가 일반적으로 탐색에서 발생하는 특정 작업을 수동으로 관리해야 합니다. 탐색 기록 관리와 같은 일부 작업은 현재 API로 가능합니다. 하지만 Core Web Vitals 측정과 같은 다른 작업은 이러한 탐색에서 불가능합니다.
소프트 탐색 API를 사용하면 소프트 탐색을 관찰할 수 있습니다. 소프트 탐색을 시작하는 JavaScript (일반적으로 JavaScript 프레임워크)는 탐색이 발생하는 시점을 인식하지만 사이트에서 사용되는 다른 JavaScript (예: 분석 스크립트)와 브라우저 자체는 인식하지 못합니다.
코어 웹 바이탈 및 SPA
Soft Navigation API의 주요 동기 중 하나는 SPA의 Core Web Vitals를 측정할 수 있도록 하는 것입니다. Core Web Vitals는 브라우저 (Chrome 사용자 경험 보고서와 같은 도구에 표시됨)와 실제 사용자 모니터링 (RUM) 솔루션을 사용하는 사이트 소유자가 측정합니다.
JavaScript 프레임워크는 SPA의 Core Web Vitals의 일부 측면을 측정할 수 있습니다. 특히 다음 페인트에 대한 상호작용 (INP)과 누적 레이아웃 이동 (CLS)은 이러한 측정항목을 계산하기 위해 모든 기간에 걸쳐 측정할 수 있는 기본 요소 (각각 Event Timing API와 Layout Instability API)를 기반으로 합니다. 하지만 최대 콘텐츠 페인트 (LCP)와 같은 다른 측정항목은 페이지 탐색을 기반으로 브라우저에서만 내보내며 상호작용 시 최종 확정됩니다.
API가 SPA의 Core Web Vitals 측정을 지원하는 방식
소프트 탐색 API는 다음 두 가지 새로운 성능 항목을 도입합니다.
- 모든 소프트 탐색 요구사항이 충족될 때 방출되는
SoftNavigationEntry항목 여기에는 소프트 탐색을 유발한 상호작용의interactionId, 고유한navigationId, 새 URL로 설정된name, 소프트 탐색의 콘텐츠가 포함된 첫 페인트를 측정하는 데 사용할 수 있는 다양한 페인트 타이밍이 포함됩니다. - 상호작용 후 여러 개의 콘텐츠 렌더링 시간을 측정하여 소프트 탐색의 LCP를 측정할 수 있는
InteractionContentfulPaint항목
이러한 새 항목은 각각 soft-navigation 및 interaction-contentful-paint 유형을 사용하여 PerformanceObserver를 통해 관찰할 수 있습니다.
또한 API는 각 largest-contentful-paint, interaction-contentful-paint, event-timing, layout-shift 성능 항목 (및 기타 항목)을 확장하여 항목이 나타내는 탐색을 나타내는 식별자 navigationId를 포함합니다. PerformanceObserver는 페이지가 유휴 상태가 될 때까지 성능 항목을 관찰하지 않으므로 성능 항목을 생성한 이벤트와 관찰 사이에 시간이 경과할 수 있습니다. 이는 페이지가 매우 바쁠 때(예: 소프트 탐색 중) 특히 그렇습니다. 이 navigationId 값은 항목을 올바른 탐색에 기여도로 부여하는 데 도움이 됩니다.
일부 interaction-contentful-paint 항목은 탐색 전에 발생할 수 있고 일부는 탐색 후에 발생할 수 있습니다. 소프트 탐색을 유발할 수 있는 모든 페인트를 추적하는 대신 soft-navigation 항목에는 지금까지 확인된 가장 큰 페인트인 largestInteractionContentfulPaint 항목이 포함됩니다.
이러한 기능을 통해 다음 항목에 대한 Core Web Vitals를 측정할 수 있습니다.
- LCP: 초기 페이지 로드에는
largest-contentful-paint를 사용하고 소프트 탐색에는 새로운interaction-contentful-paint및soft-navigation항목을 사용합니다. - CLS:
layout-shift항목을 사용하고 소프트 탐색의soft-navigation항목을 기반으로 슬라이싱합니다. - INP:
event항목을 사용하고 소프트 탐색의soft-navigation항목을 기반으로 슬라이싱합니다. - FCP: 초기 페이지 로드에
first-contentful-paint를 사용하고 소프트 탐색의 새soft-navigation항목에 페인트 타이밍 세부정보를 사용합니다.
자세한 내용은 소프트 탐색 문서를 참고하세요.
소프트 탐색은 어떻게 트리거되나요?
소프트 탐색 API는 다음이 발생할 때 소프트 탐색을 트리거합니다.
- 사용자 상호작용이 발생합니다.
- … 사용자가 콘텐츠를 볼 수 있도록 페인트됩니다.
- … URL 업데이트가 발생합니다.
이 API는 JavaScript 프레임워크가 소프트 탐색을 '내보내도록' 하거나 Navigation API를 기반으로 빌드하는 대신 다음 두 가지 이유로 이 접근 방식을 취합니다.
- 첫째, 사이트를 변경하지 않고 기존 SPA 사이트를 모두 포함합니다.
- 둘째, 프레임워크나 개발자가 탐색을 처리하는 방식과 관계없이 소프트 탐색을 구성하는 요소에 대한 일관된 이해를 지원합니다.
프레임워크나 개발자는 사용자가 탐색으로 간주하는 사용자 상호작용이나 DOM 업데이트가 없어도 조용히 탐색의 URL을 업데이트할 수 있습니다. 상호작용 시작 시, 완료 시에만, 또는 그 사이의 어느 상태에서든 URL을 업데이트할 수도 있습니다.
프레임워크 및 개발자 선택에 의존하는 대신 브라우저에 소프트 탐색 감지를 빌드하면 소프트 탐색의 Core Web Vitals을 대규모로 측정할 수 있고 이러한 측정을 대규모로 비교할 수 있는 표준 정의가 설정됩니다.
프레임워크와 개발자는 Soft Navigations API를 무시하고 기본 Event Timing, Layout Instability API, 새로운 InteractionContentfulPaint 성능 항목을 사용하여 원하는 대로 추가 성능 측정항목을 측정할 수도 있습니다. 하지만 사이트와 도구 전반에서 일관된 측정을 지원하려면 Core Web Vitals 측정에 API를 사용하는 것이 좋습니다.
소프트 탐색 API 테스트에 도움이 필요함
Soft Navigations API를 테스트하고 소프트 탐색이 발생하는 시기가 기대치와 일치하는지 확인하는 데 도움이 필요합니다. 소프트 탐색이 발생했다고 생각되는데 API가 이를 보고하지 않나요? 반대로 API에서 탐색으로 간주하지 않는 탐색을 과도하게 보고하나요?
마지막 오리진 트라이얼 이후 변경된 사항
이 최신 반복의 주요 변경사항은 InteractionContentfulPaint를 소프트 탐색에서 분리하여 해당 성능 항목의 다른 사용 사례를 지원하고 SoftNavigationEntry에 largestInteractionContentfulPaint 속성을 추가하는 것입니다.
웹사이트 관점에서 API에는 이제 replaceState도 소프트 탐색으로 포함됩니다. 많은 경우에 이를 탐색으로 고려하는 것이 중요하다는 의견을 반영한 것입니다. API가 소프트 탐색을 인식하지 못하는 다른 사례가 있다면 알려주시기 바랍니다.
또한 구현에 수많은 다른 개선사항이 적용되었습니다. 최신 반복에서 무엇이 변경되었는지 정확히 확인하려는 경우 소프트 탐색 변경사항에서 모든 변경사항의 자세한 기록을 확인할 수 있습니다.
Google은 API가 최대한 유용하도록 노력하고 있으며, 이를 위해 추가 변경사항을 적용할 수 있습니다. 사이트가 구현에 의존하기 시작하기 전에 API에 변경사항을 구현하는 것이 훨씬 쉽습니다. 따라서 SPA 개발자와 이러한 사이트의 웹 성능 측정에 관심이 있는 분들은 이 API를 테스트하고 의견을 제공해 주시기 바랍니다.
테스트 방법
API는 Chrome 플래그 또는 명령줄 옵션을 사용하여 로컬에서 테스트할 수 있습니다. 또한 오리진 트라이얼을 사용하여 필드에서 테스트할 수 있습니다 (오리진 트라이얼에 대해 자세히 알아보기).
API에 관한 기술적 세부정보, 특히 Core Web Vitals를 측정하는 방법에 관한 자세한 내용은 문서 또는 GitHub 저장소를 참고하세요.
또한 실험적인 웹 바이탈 라이브러리의 소프트 탐색 버전이 GitHub 및 npm에서 제공됩니다.
더 간단한 테스트를 위해 Chrome DevTools의 성능 패널은 기능을 사용 설정하지 않아도 Chrome 145부터 성능 트레이스에 소프트 탐색을 표시합니다.
의견
API에 관한 의견은 GitHub에서 문제로 제기하고 Chromium 구현에 관한 버그는 Chrome의 문제 추적기에 신고하세요. 어떤 카테고리에 의견이 속하는지 잘 모르겠다면 너무 걱정하지 마세요. 어느 곳에서든 의견을 보내주시면 됩니다. 두 곳 모두에서 문제를 분류하고 올바른 위치로 리디렉션해 드립니다.