게시일: 2025년 7월 31일
Chrome에서는 이전에 실험했던 Soft Navigations API를 위해 Chrome 139부터 새로운 오리진 트라이얼을 시작합니다. 이 오리진 트라이얼을 통해 사이트는 실제 사용자를 대상으로 사이트에서 API를 사용해 API를 현장 테스트하고 Chrome팀에 의견을 제공할 수 있습니다.
소프트 탐색이란 무엇인가요?
소프트 탐색은 JavaScript가 탐색(예: 링크 클릭)을 가로채고 새 페이지를 로드하는 대신 기존 페이지의 콘텐츠를 업데이트하는 경우입니다. 이때 뒤로 및 앞으로 소프트 탐색을 허용하는 기록 상태와 함께 주소 표시줄의 URL이 업데이트됩니다. 사용자에게는 이러한 탐색이 기존 탐색과 동일하게 보이지만 브라우저에서는 페이지가 여전히 원래 페이지입니다.
소프트 탐색 API가 필요한 이유
Soft Navigations API는 싱글 페이지 애플리케이션 (SPA) 사이트에서 사용되는 소위 '소프트 탐색'을 휴리스틱 기반으로 감지할 수 있도록 제안된 API입니다. 소프트 탐색에서는 실제 페이지 탐색이 발생하지 않으므로 일반적으로 탐색 시 발생하는 특정 작업을 JavaScript로 수동으로 관리해야 합니다. 탐색 기록 관리와 같은 일부 작업은 현재 API로 가능합니다. 하지만 코어 웹 바이탈 측정과 같은 다른 작업은 이러한 탐색에서 불가능합니다.
소프트 탐색 API를 사용하면 소프트 탐색을 관찰할 수 있습니다. 소프트 탐색을 시작하는 JavaScript (일반적으로 JavaScript 프레임워크)는 탐색이 발생하는 시점을 인식하지만 다른 JavaScript와 브라우저 자체는 인식하지 못합니다.
코어 웹 바이탈 및 SPA
Soft Navigation API의 주요 동기 중 하나는 SPA의 Core Web Vitals를 측정할 수 있도록 하는 것입니다. 코어 웹 바이탈은 브라우저 (Chrome 사용자 환경 보고서와 같은 도구에 표시)와 실제 사용자 모니터링 (RUM) JavaScript 라이브러리 모두에 의해 측정됩니다.
JavaScript 프레임워크는 코어 웹 바이탈의 일부 측면을 측정할 수 있습니다. 특히 다음 페인트에 대한 상호작용 (INP)과 누적 레이아웃 이동 (CLS)은 INP 및 CLS 측정항목을 계산하기 위해 모든 기간에 걸쳐 측정할 수 있는 기본 요소 (각각 이벤트 타이밍 API 및 레이아웃 불안정성 API)를 기반으로 합니다. 하지만 콘텐츠가 포함된 최대 페인트 (LCP)와 같은 다른 측정항목은 페이지 탐색을 기반으로 브라우저에서만 발생하며 상호작용 시 완료됩니다.
Soft Navigation API를 통해 SPA의 Core Web Vitals를 측정하는 방법
소프트 탐색 API의 첫 번째 반복에서는 소프트 탐색 휴리스틱이 LCP 재설정과 결합되었습니다. 재설정된 후에는 새로운 콘텐츠 페인트의 소프트 탐색에 대해 LCP를 다시 내보낼 수 있으므로 소프트 탐색에 대해 이 측정항목을 측정할 수 있습니다.
이 최신 반복에서는 다른 접근 방식을 취하고 이러한 개념을 소프트 탐색 API와 새로운 Interaction to Contentful Paint 성능 항목으로 분리합니다. interaction-contentful-paint 항목은 상호작용 후 '콘텐츠 페인트'를 측정합니다. 현재는 소프트 탐색에 대해서만 발생하지만 모든 상호작용에 대해 사용 설정하면 LCP를 넘어 다른 잠재적 사용 사례가 열립니다.
또한 API는 각 largest-contentful-paint, interaction-contentful-paint, event-timing, layout-shift 성능 항목을 확장하여 항목이 적용되는 탐색의 식별자를 포함했습니다. 성능 항목은 측정하는 이벤트 후에, 일반적으로 유휴 시간 동안 방출됩니다. 따라서 실적 항목이 방출될 때쯤이면 URL이 변경된 경우가 많습니다. 진입과 함께 탐색을 포함하면 성능 진입 시간과 소프트 탐색 진입 시간을 일치시키지 않고도 지정된 URL의 코어 웹 바이탈을 훨씬 쉽게 측정할 수 있습니다.
휴리스틱을 사용하는 이유
소프트 탐색 API는 다음이 발생할 때 소프트 탐색을 고려합니다.
- 사용자 기반 상호작용이 발생합니다 (사용자 상호작용 없이 URL이 업데이트되는 경우는 제외).
- … DOM 수정 및 페인트가 발생합니다.
- … URL 업데이트가 발생합니다.
- 기록 변경을 포함한 URL 업데이트
이 API는 JavaScript 프레임워크가 소프트 탐색을 '내보내기'하거나 탐색 API를 기반으로 빌드하도록 허용하는 대신 휴리스틱 기반 접근 방식을 취합니다. 이렇게 하면 프레임워크나 개발자가 프레임워크를 사용하는 방식과 관계없이 소프트 탐색을 구성하는 요소를 일관되게 이해할 수 있습니다.
프레임워크나 개발자는 사용자가 탐색으로 간주할 수 있는 사용자 상호작용이나 DOM 업데이트가 없더라도 소프트 탐색의 URL을 업데이트할 수 있습니다. 또한 상호작용 시작 시점이나 완료된 후 종료 시점, 또는 그 사이의 어느 시점에서 URL을 업데이트할 수도 있습니다.
프레임워크 선택에 의존하는 대신 브라우저에 소프트 탐색 감지를 빌드하면 대규모로 소프트 탐색의 Core Web Vitals를 측정하고 대규모로 이러한 측정을 비교할 수 있는 표준 '휴리스틱'이 설정됩니다(이 오리진 트라이얼의 의견 포함).
프레임워크와 개발자는 소프트 탐색 API 휴리스틱을 무시하고 기본 이벤트 타이밍, 레이아웃 불안정성, 상호작용에서 콘텐츠 페인트까지 API를 사용하여 원하는 추가 성능 측정항목을 측정할 수도 있지만, 휴리스틱을 사용하는 Core Web Vitals를 사용하여 사이트 전반에서 측정하는 것이 좋습니다.
소프트 탐색 API 테스트에 도움이 필요함
휴리스틱이 소프트 탐색이 발생한 시점에 대한 기대치와 올바르게 일치하는지 테스트하기 위해 소프트 탐색 API를 테스트하는 데 도움이 필요합니다. API가 발생한 것으로 간주되는 소프트 탐색을 보고하지 않는 경우가 있나요? 반대로 소프트 탐색으로 간주하지 않는 반복 탐색에서 API가 과도하게 호출되나요?
문제를 일으키는 예로는 기록을 추가하는 대신 replaceState로 URL을 업데이트하는 경우나 사용자가 시작하지 않은 탐색이 발생하는 경우 (예: 시간 초과 시 로그아웃)가 있습니다. 두 경우 모두 휴리스틱과 일치하지 않아 발생하며 Chrome팀은 이를 포함하지 않아도 된다고 생각하지만 웹 개발자의 의견을 듣고 싶습니다. 특히 휴리스틱이 충족되는 것으로 보이지만 API에서 여전히 소프트 탐색을 인식하지 못하는 경우에 대해 알려주시면 감사하겠습니다.
또한 이 API와 새로운 Interaction to Contentful Paint 프리미티브가 SPA의 Core Web Vitals 측정을 허용하는 기본 사용 사례를 해결하는지 파악하고자 합니다.
Google은 API가 최대한 유용하기를 바라며, API가 출시되고 사이트가 구현에 의존하기 전에 이 목표를 달성하는 것이 훨씬 쉽습니다. 따라서 SPA 개발자와 이러한 사이트의 웹 성능 측정에 관심이 있는 분들은 이 API를 사용해 보고 어떻게 작동하는지 알려주시기 바랍니다.
테스트 방법
API는 Chrome 플래그 또는 명령줄 옵션을 사용하여 로컬에서 테스트할 수 있습니다. 또한 오리진 트라이얼을 사용하여 필드에서 테스트할 수 있습니다.
API의 기술적 세부정보, 특히 핵심 웹 바이탈을 측정하는 방법에 관한 자세한 내용은 문서 또는 GitHub 저장소를 참고하세요. 실험적인 웹 바이탈 라이브러리의 소프트 탐색 버전도 사용할 수 있습니다.
의견
Google에서는 다음 채널을 통해 이 실험에 대한 의견을 적극적으로 수렴하고 있습니다.
- API에 관한 의견은 GitHub의 문제로 제출해야 합니다.
- Chromium 구현의 버그는 아직 알려진 문제가 아닌 경우 Chrome 문제 추적기에 신고해야 합니다.
- 일반적인 웹 바이탈 의견은 web-vitals-feedback@googlegroups.com으로 공유할 수 있습니다.
어디에 의견을 제출해야 할지 잘 모르겠다면 너무 걱정하지 마세요. 어디에 의견을 제출하든 Google에서 문제를 분류하고 올바른 위치로 리디렉션해 드립니다.