이 페이지는 Cloud Translation API를 통해 번역되었습니다.

소프트 탐색 측정 실험

Barry Pollard

Yoav Weiss

2024년 8월 업데이트: 두 번째 조용히 탐색 오리진 트라이얼이 5월 29일에 종료되었습니다. Chrome팀은 실험 의견을 검토하고 이 API의 다음 단계를 고려하는 데 시간을 보내고 있습니다. 일부 정확성 문제를 해결하고자 하며 기능을 개발하기 전에 또 다른 오리진 트라이얼이 필요할 것으로 판단됩니다. 그동안 개발자는 chrome://flags/#enable-experimental-web-platform-features를 사용 설정하여 이 기능을 실험해 볼 수 있습니다.

Core Web Vitals 이니셔티브는 출시 이후 웹사이트가 생성되거나 로드되는 방식에 관한 기술적 세부정보가 아닌 웹사이트의 실제 사용자 환경을 측정하기 위해 노력해 왔습니다. 세 가지 Core Web Vitals 측정항목은 사용자 중심 측정항목으로 만들어졌습니다. 이는 사용자가 페이지의 성능을 인지하는 방식과 관련이 없는 경우가 많았던 기존의 기술적 측정항목(예: DOMContentLoaded 또는 load)을 개선한 것입니다. 그렇기 때문에 사이트를 구축하는 데 사용된 기술이 사이트 성능이 좋더라도 점수에 영향을 주지 않습니다.

현실은 항상 이상보다 약간 더 까다롭습니다. 인기 있는 싱글 페이지 애플리케이션 아키텍처는 코어 웹 바이탈 측정항목에서 완전히 지원된 적이 없습니다. 이러한 웹 애플리케이션은 사용자가 사이트를 탐색할 때 개별 웹페이지를 로드하는 대신 '조용히 탐색'이라는 것을 사용합니다. 이때 페이지 콘텐츠는 자바스크립트로 변경됩니다. 이러한 애플리케이션에서는 URL을 변경하고 브라우저 기록에 이전 URL을 푸시하여 뒤로 및 앞으로 버튼이 사용자가 예상한 대로 작동하도록 하여 기존 웹페이지 아키텍처의 환상을 유지합니다.

많은 JavaScript 프레임워크에서 이 모델을 사용하지만 각각 다른 방식으로 사용합니다. 이는 브라우저에서 전통적으로 '페이지'로 이해하는 범위를 벗어나기 때문에 이를 측정하는 것은 항상 어려웠습니다. 현재 페이지에서의 상호작용과 이를 새 페이지로 간주하는 것 사이에는 어디에 기준을 두어야 할까요?

Chrome팀은 오랫동안 이 문제를 고려해 왔으며, 기존의 멀티페이지 아키텍처(MPA)로 구현된 웹사이트가 측정되는 것과 유사한 방식으로 '조용히 탐색'의 정의와 이를 위해 핵심 웹 바이탈을 측정하는 방법을 표준화하고자 합니다. 아직 초기 단계이지만 이제 팀에서 이미 구현된 기능을 사이트에서 실험할 수 있도록 더 광범위하게 제공할 준비가 되었습니다. 이를 통해 사이트에서 지금까지의 접근 방식에 관한 의견을 제공할 수 있습니다.

소프트 탐색이란 무엇인가요?

Google에서는 소프트 탐색의 다음과 같은 정의를 내렸습니다.

탐색은 사용자 작업에 의해 시작됩니다.
탐색하면 사용자에게 표시되는 URL이 변경되고 방문 기록이 변경됩니다.
탐색으로 인해 DOM이 변경됩니다.

일부 사이트의 경우 이러한 휴리스틱의 경우 거짓양성 (사용자가 실제로는 '탐색'이 발생한 것으로 간주하지 않음) 또는 거짓음성 (사용자가 이러한 기준을 충족하지 않더라도 '탐색'이 발생한 것으로 간주)이 발생할 수 있습니다. 소프트 탐색 사양 저장소에서 휴리스틱에 관한 의견을 보내주세요.

Chrome에서는 소프트 탐색을 어떻게 구현하나요?

조용히 탐색 휴리스틱이 사용 설정되면(다음 섹션에서 자세히 알아보기) Chrome에서 일부 실적 측정항목을 보고하는 방식이 변경됩니다.

각 조용히 탐색이 감지될 때마다 soft-navigation PerformanceTiming 이벤트가 발생합니다.
성능 API는 soft-navigation PerformanceTiming 이벤트에서 내보낸 soft-navigation 타이밍 항목에 대한 액세스를 제공합니다.
첫 번째 페인트(FP), 콘텐츠가 포함된 첫 페인트(FCP), 콘텐츠가 포함된 최대 페인트(LCP) 측정항목은 재설정되며 다음에 적절하게 발생하면 다시 내보내집니다. 참고: FP 및 FCP는 구현되지 않았습니다.
이벤트와 관련된 탐색 항목에 해당하는 각 성능 타이밍 (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event, layout-shift)에 navigationId 속성이 추가되어 레이아웃 변경 횟수 (CLS) 및 다음 페인트에 대한 상호작용 (INP)을 계산할 수 있습니다.

이렇게 변경하면 Core Web Vitals(및 일부 관련 진단 측정항목)를 페이지 탐색별로 측정할 수 있지만 고려해야 할 미묘한 차이가 있습니다.

Chrome에서 조용히 탐색을 사용 설정하면 어떤 이점이 있나요?

다음은 이 기능을 사용 설정한 후 사이트 소유자가 고려해야 하는 몇 가지 변경사항입니다.

소프트 탐색을 위해 추가 FP, FCP, LCP 이벤트를 다시 내보낼 수 있습니다. Chrome 사용자 환경(CrUX) 보고서는 이러한 추가 값을 무시하지만 사이트의 실제 사용자 측정(RUM) 모니터링에는 영향을 줄 수 있습니다. 이러한 측정에 영향을 미칠 수 있는지 우려되는 경우 RUM 제공업체에 문의하세요. 소프트 탐색을 위한 Core Web Vitals 측정 섹션을 참고하세요.
성능 항목의 새로운(선택사항) navigationID 속성을 이러한 항목을 사용하는 애플리케이션 코드에서 고려해야 할 수 있습니다.
Chromium 기반 브라우저에서만 이 새로운 모드를 지원합니다. 새로운 측정항목의 대부분은 Chromium 기반 브라우저에서만 사용할 수 있지만 일부 측정항목(FCP, LCP)은 다른 브라우저에서도 사용할 수 있으며 모든 사용자가 최신 버전의 Chromium 기반 브라우저로 업그레이드하지 않았을 수도 있습니다. 따라서 일부 사용자는 조용히 탐색 측정항목을 보고하지 않을 수 있습니다.
기본적으로 사용 설정되지 않는 실험용 새 기능이므로 사이트에서는 이 기능을 테스트하여 의도하지 않은 다른 부작용이 없는지 확인해야 합니다.

조용히 탐색의 측정항목을 측정하는 방법에 관한 자세한 내용은 조용히 탐색별 Core Web Vitals 측정 섹션을 참고하세요.

Chrome에서 조용히 탐색을 사용 설정하려면 어떻게 해야 하나요?

조용히 탐색은 Chrome에서 기본적으로 사용 설정되지 않지만 이 기능을 명시적으로 사용 설정하여 실험할 수 있습니다.

개발자는 chrome://flags/#enable-experimental-web-platform-features에서 실험용 웹 플랫폼 기능 플래그를 사용 설정하거나 Chrome을 실행할 때 --enable-experimental-web-platform-features 명령줄 인수를 사용하여 이 기능을 사용 설정할 수 있습니다.

조용히 탐색은 어떻게 측정하나요?

조용히 탐색 실험이 사용 설정되면 평소와 같이 PerformanceObserver API를 사용하여 측정항목이 보고됩니다. 하지만 이러한 측정항목에는 몇 가지 추가 고려사항이 있습니다.

소프트 탐색 보고

PerformanceObserver를 사용하여 조용히 탐색을 관찰할 수 있습니다. 다음은 buffered 옵션을 사용하여 이 페이지의 이전 조용히 탐색을 포함하여 조용히 탐색 항목을 콘솔에 로깅하는 코드 스니펫의 예입니다.

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

이는 이전 탐색의 전체 페이지 측정항목을 완료하는 데 사용할 수 있습니다.

적절한 URL에 대해 측정항목 보고

조용히 탐색은 발생한 후에만 확인할 수 있으므로 일부 측정항목은 이 이벤트에 따라 완료된 후 이전 URL에 대해 보고해야 합니다. 현재 URL에는 새 페이지의 업데이트된 URL이 반영되기 때문입니다.

적절한 PerformanceEntry의 navigationId 속성을 사용하여 이벤트를 올바른 URL에 다시 연결할 수 있습니다. PerformanceEntry API를 사용하여 조회할 수 있습니다.

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

이 pageUrl는 이전에 사용했을 수 있는 현재 URL이 아닌 올바른 URL에 대해 측정항목을 보고하는 데 사용해야 합니다.

소프트 탐색의 `startTime` 가져오기

내비게이션 시작 시간도 비슷한 방식으로 가져올 수 있습니다.

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

startTime은 소프트 탐색을 시작한 초기 상호작용 (예: 버튼 클릭)의 시간입니다.

조용히 탐색의 경우를 포함한 모든 성능 타이밍은 초기 '하드' 페이지 탐색 시간부터의 시간으로 보고됩니다. 따라서 이 조용히 탐색 시간을 기준으로 조용히 탐색 로드 측정항목 시간(예: LCP)의 기준을 설정하려면 조용히 탐색 시작 시간이 필요합니다.

조용히 탐색당 코어 웹 바이탈 측정

조용히 탐색 측정항목 항목을 포함하려면 성능 관찰자의 observe 호출에 includeSoftNavigationObservations: true를 포함해야 합니다.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

Chrome에서 부드러운 탐색 기능을 사용 설정하는 것 외에도 observe 메서드에 추가 includeSoftNavigationObservations 플래그가 필요합니다. 성능 관찰자 수준에서 명시적으로 선택하는 옵션은 소프트 탐색을 위해 Core Web Vitals를 측정하려고 할 때 몇 가지 추가 고려사항을 고려해야 하므로 기존 성능 관찰자가 이러한 추가 항목으로 인해 놀라지 않도록 하는 것입니다.

시간은 원래의 '실제' 내비게이션 시작 시간에 따라 계속 반환됩니다. 예를 들어 조용히 탐색의 LCP를 계산하려면 LCP 타이밍을 취하고 앞서 설명한 대로 적절한 조용히 탐색 시작 시간을 빼서 조용히 탐색과 관련된 타이밍을 가져와야 합니다. 예를 들어 LCP의 경우 다음과 같습니다.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

일부 측정항목은 전통적으로 페이지의 전체 기간 동안 측정되었습니다. 예를 들어 LCP는 상호작용이 발생할 때까지 변경될 수 있습니다. CLS 및 INP는 페이지에서 벗어날 때까지 업데이트할 수 있습니다. 따라서 각 '탐색'(원래 탐색 포함)은 새로운 소프트 탐색이 발생할 때마다 이전 페이지의 측정항목을 완료해야 할 수 있습니다. 즉, 초기 '하드' 탐색 측정항목이 평소보다 일찍 완료될 수 있습니다.

마찬가지로 이러한 장기 측정항목의 새 소프트 탐색에 대한 측정항목을 측정하기 시작할 때는 측정항목을 '재설정' 또는 '재초기화'하고 이전 '페이지'에 설정된 값을 기억하지 않고 새 측정항목으로 처리해야 합니다.

탐색 간에 동일하게 유지되는 콘텐츠는 어떻게 처리해야 하나요?

조용히 탐색의 FP, FCP, LCP는 새 페인트만 측정합니다. 이로 인해 LCP가 달라질 수 있습니다(예: 조용히 탐색의 콜드 로드에서 조용히 로드로).

예를 들어 LCP 요소인 대형 배너 이미지가 포함된 페이지가 있지만 그 아래의 텍스트가 소프트 탐색할 때마다 변경되는 페이지를 생각해 보세요. 초기 페이지 로드 시 배너 이미지가 LCP 요소로 표시되고 이를 기반으로 LCP 타이밍이 설정됩니다. 후속 조용히 탐색의 경우 아래 텍스트가 조용히 탐색 후 페인팅되는 가장 큰 요소가 되며 새 LCP 요소가 됩니다. 하지만 새 페이지가 소프트 탐색 URL로 연결되는 딥 링크를 사용하여 로드되는 경우 배너 이미지는 새 페인트가 되므로 LCP 요소로 간주될 수 있습니다.

이 예에서 볼 수 있듯이 페이지가 로드되는 방식에 따라 조용히 탐색의 LCP 요소가 다르게 보고될 수 있습니다. 페이지 아래쪽에 앵커 링크가 있는 페이지를 로드하면 다른 LCP 요소가 발생하는 것과 마찬가지입니다.

TTFB 측정 방법

기존 페이지 로드의 첫 바이트까지의 시간(TTFB)은 원래 요청의 첫 번째 바이트가 반환되는 시간을 나타냅니다.

조용히 탐색하는 경우 이 질문은 더 까다롭습니다. 새 페이지에 대한 첫 번째 요청을 측정해야 하나요? 모든 콘텐츠가 이미 앱에 있고 추가 요청이 없는 경우 어떻게 해야 하나요? 이 요청이 미리 로드로 사전에 이루어지면 어떻게 하나요? 사용자 관점에서 소프트 탐색과 관련 없는 요청(예: 분석 요청)인 경우 어떻게 해야 하나요?

더 간단한 방법은 조용히 탐색에 대해 TTFB 0을 보고하는 것입니다. 이는 뒤로/앞으로 캐시 복원에 권장되는 방법과 유사합니다. 이 메서드는 web-vitals 라이브러리에서 조용히 탐색하는 데 사용합니다.

향후 Google에서는 어떤 요청이 조용히 탐색의 '탐색 요청'인지를 더 정확하게 파악하는 방법을 지원하고 더 정확한 TTFB 측정을 할 수 있게 될 것입니다. 하지만 이는 현재 실험의 일부가 아닙니다.

기존 및 새 제품을 모두 측정하는 방법

이 실험이 진행되는 동안에는 CrUX에서 핵심 성능 보고서 이니셔티브의 공식 데이터 세트로 측정하고 보고할 내용과 일치하도록 '하드' 페이지 탐색을 기반으로 현재 방식으로 핵심 성능 보고서를 계속 측정하는 것이 좋습니다.

향후 이러한 측정항목이 어떻게 측정될지 확인하고 이 구현이 실제로 작동하는 방식에 관한 의견을 Chrome팀에 제공할 수 있도록 부드러운 탐색도 측정해야 합니다. 이렇게 하면 개발자와 Chrome팀이 향후 API를 설계하는 데 도움이 됩니다.

둘 다 측정하려면 조용히 탐색 모드에서 실행될 수 있는 새 이벤트(예: 여러 FCP 및 추가 LCP 이벤트)를 인식하고 적절한 시점에 이러한 측정항목을 수정하여 적절하게 처리해야 하며, 조용히 탐색에만 적용되는 향후 이벤트는 무시해야 합니다.

`web-vitals` 라이브러리를 사용하여 조용히 탐색의 Core Web Vitals 측정

모든 뉘앙스를 고려하는 가장 쉬운 방법은 별도의 soft-navs branch(npm 및 unpkg에서도 사용 가능)에서 조용히 탐색을 위한 실험적 지원이 있는 web-vitals JavaScript 라이브러리를 사용하는 것입니다. 이는 다음과 같은 방식으로 측정할 수 있습니다 (doTraditionalProcessing 및 doSoftNavProcessing를 적절하게 대체).

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

앞서 언급한 대로 올바른 URL에 대해 측정항목이 보고되는지 확인합니다.

web-vitals 라이브러리는 조용히 탐색에 대해 다음과 같은 측정항목을 보고합니다.

측정항목	세부정보
TTFB	0으로 보고됩니다.
FCP	페이지의 첫 번째 FCP만 보고됩니다.
LCP	조용히 탐색 시작 시간을 기준으로 두 번째로 긴 콘텐츠 렌더링 시간입니다. 이전 탐색에서 나타나는 기존 페인트는 고려되지 않습니다. 따라서 LCP는 0보다 큽니다. 평소와 같이 상호작용 시 또는 페이지가 백그라운드로 전환될 때 보고됩니다. 그래야만 LCP가 완료될 수 있기 때문입니다.
CLS	탐색 시간 간의 가장 큰 전환 시간입니다. 평소와 같이 페이지가 백그라운드에 있을 때만 CLS를 최종화할 수 있습니다. 전환이 없으면 0 값이 보고됩니다.
INP	탐색 시간 간의 INP입니다. 평소와 같이 상호작용 시 또는 페이지가 백그라운드로 전환될 때 보고됩니다. 그때만 INP를 완료할 수 있기 때문입니다. 상호작용이 없는 경우 0 값이 보고되지 않습니다.

경고: web-vitals 구현은 현재 개발 중이며 브랜치에 새로운 변경사항이 게시됨에 따라 변경될 수 있습니다. 조용히 탐색 시에는 Chrome에서 더 많은 기본 작업이 필요하므로 FCP가 지원되지 않습니다. web-vitals JavaScript 라이브러리를 사용하는 경우 프로덕션 사이트에서 이 라이브러리를 사용하려는 경우 이를 인지하고 로컬 사본을 가져와 해당 버전을 테스트하고 브랜치의 변경사항을 모니터링해야 합니다.

이러한 변경사항이 Core Web Vitals 측정의 일부가 되나요?

이 조용히 탐색 실험은 실험입니다. Google은 이 휴리스틱을 평가하고 Core Web Vitals 이니셔티브에 통합할지 여부를 결정하기 전에 휴리스틱이 사용자 경험을 더 정확하게 반영하는지 확인하고자 합니다. YouTube는 이번 실험의 가능성에 대해 매우 기대하고 있지만, 현재 측정 방식이 대체될지, 언제 대체될지는 보장할 수 없습니다.

Google은 실험, 사용된 휴리스틱, 이러한 환경이 경험을 더 정확하게 반영한다고 생각하는지 여부에 대한 웹 개발자의 의견을 소중하게 생각합니다. 조용히 탐색 GitHub 저장소가 이러한 의견을 제공하는 가장 좋은 장소이지만, Chrome에서 구현한 조용히 탐색의 개별 버그는 Chrome Issue Tracker에서 제기해야 합니다.

소프트 탐색은 CrUX에서 어떻게 보고되나요?

이 실험이 성공할 경우 CrUX에서 조용히 탐색이 정확히 어떻게 보고될지도 아직 결정되지 않았습니다. 이러한 탐색이 현재의 '하드' 탐색과 동일하게 처리된다고 가정할 수는 없습니다.

일부 웹페이지에서는 사용자가 볼 때 소프트 탐색이 전체 페이지 로드와 거의 동일하며 단일 페이지 애플리케이션 기술의 사용은 구현 세부정보에 불과합니다. 다른 경우에는 추가 콘텐츠의 부분 로드에 더 가깝습니다.

따라서 Google은 이러한 조용히 탐색을 CrUX에 별도로 보고하거나 특정 페이지 또는 페이지 그룹의 Core Web Vitals를 계산할 때 가중치를 부여할 수 있습니다. 휴리스틱이 발전함에 따라 부분 로드 조용히 탐색을 완전히 제외할 수도 있습니다.

YouTube는 이 실험의 성공 여부를 판단할 수 있는 휴리스틱 및 기술적 구현에 집중하고 있으므로 아직 결정된 사항은 없습니다.

의견

다음 위치에서 이 실험에 관한 의견을 적극적으로 수렴하고 있습니다.

조용히 탐색 휴리스틱 및 표준화
이러한 휴리스틱의 Chrome 구현 문제.
일반적인 Core Web Vitals 의견은 web-vitals-feedback@googlegrouops.com으로 보내주세요.

변경 로그

이 API는 실험 단계에 있으므로 안정적인 API를 사용할 때보다 더 많은 변화가 일어나고 있습니다. 자세한 내용은 조용히 탐색 휴리스틱 변경 로그를 참고하세요.

결론

조용히 탐색 실험은 Core Web Vitals 이니셔티브가 측정항목에서 누락된 현대 웹의 일반적인 패턴을 측정하도록 발전할 수 있는 흥미로운 접근 방식입니다. 이 실험은 아직 초기 단계이고 아직 해야 할 일이 많이 있지만, 지금까지의 진전을 광범위한 웹 커뮤니티에 제공하여 실험할 수 있도록 하는 것은 중요한 단계입니다. 이 실험에서 의견을 수집하는 것도 실험의 중요한 부분이므로 이 개발에 관심이 있는 경우 이 기회를 활용하여 Google에서 측정하고자 하는 내용을 대표할 수 있도록 API를 수정하는 데 도움을 주시기 바랍니다.

감사의 말씀

Unsplash의 조던 마드리드님 제공 썸네일 이미지