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

소프트 탐색 측정 실험

Barry Pollard

Yoav Weiss

2024년 4월 업데이트: Soft Navigations Origin Trail이 5월 29일에 종료될 예정입니다. 이후 Chrome팀에서 실험 의견을 검토하고 이 API를 위한 다음 단계를 고려할 예정입니다. Google은 몇 가지 정확성 문제를 해결하고자 하며, 기능을 진행하기 전에 또 다른 오리진 트라이얼이 필요하다고 생각합니다. 그동안 개발자는 chrome://flags/#enable-experimental-web-platform-features를 사용 설정하여 이 기능을 실험해 볼 수 있습니다.

코어 웹 바이탈 이니셔티브는 출시 이후 웹사이트 생성 또는 로드 방식의 기술적 세부정보보다는 웹사이트의 실제 사용자 경험을 측정하는 데 초점을 맞췄습니다. 3가지 코어 웹 바이탈 측정항목은 사용자 중심 측정항목으로 만들어졌습니다. 이는 사용자가 페이지 성능을 인식하는 방식과 종종 관련이 없는 시간을 측정한 기존 기술 측정항목(예: DOMContentLoaded 또는 load)을 발전시킨 것입니다. 따라서 사이트 구축에 사용된 기술이 사이트 실적이 좋아도 점수에 영향을 주지 않습니다.

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

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

Chrome팀은 한동안 이 문제를 고려해 왔으며 기존의 다중 페이지 아키텍처 (MPA)에서 구현된 웹사이트를 측정하는 것과 유사한 방식으로 '소프트 탐색'이 무엇인지, 이를 위해 코어 웹 바이탈을 측정하는 방법에 대한 정의를 표준화하려고 합니다. 지금은 초기 단계이지만, 이제 팀은 이미 구현된 기능을 사이트에서 더 많이 실험할 수 있도록 할 준비가 되었습니다. 이를 통해 사이트에서 지금까지의 접근 방식에 관한 의견을 제공할 수 있습니다.

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

소프트 탐색의 정의는 다음과 같습니다.

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

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

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

소프트 탐색 휴리스틱이 사용 설정되면 (자세한 내용은 다음 섹션에서 자세히 설명) Chrome에서 일부 성능 측정항목을 보고하는 방식을 변경합니다.

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

이번 변경사항으로 인해 몇 가지 미묘한 차이가 있지만 페이지 탐색마다 코어 웹 바이탈 및 일부 관련 진단 측정항목을 측정할 수 있게 되었습니다.

Chrome에서 소프트 탐색을 사용 설정하면 어떤 영향이 있나요?

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

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

소프트 탐색의 측정항목을 측정하는 방법에 관한 자세한 내용은 소프트 탐색별 코어 웹 바이탈 측정 섹션을 참고하세요.

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

부드러운 탐색은 Chrome에서 기본적으로 사용 설정되지 않지만 이 기능을 명시적으로 사용 설정하면 Chrome 110에서 실험용으로 사용할 수 있습니다.

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

모든 방문자에게 이 기능을 사용 설정하여 영향을 확인하려는 웹사이트의 경우 Chrome 117에서 실행되는 오리진 트라이얼이 있습니다. 무료 체험판에 가입하고 HTML 또는 HTTP 헤더에 오리진 트라이얼 토큰이 있는 메타 요소를 포함하여 사용 설정할 수 있습니다. 자세한 내용은 오리진 트라이얼 시작하기 게시물을 참고하세요.

사이트 소유자는 페이지 전체 또는 일부 사용자에 대해서만 오리진 트라이얼을 포함하도록 선택할 수 있습니다. 특히 대다수의 사용자에 대해 이 오리진 트라이얼을 사용 설정하는 경우 측정항목이 보고되는 방식을 어떻게 변경하는지에 대한 이전 영향 섹션을 숙지하세요. CrUX는 이 소프트 탐색 설정과 관계없이 기존 방식으로 계속해서 측정항목을 보고하므로 이러한 영향의 영향을 받지 않습니다. 또한 오리진 트라이얼은 14일 동안의 중앙값으로 모든 Chrome 페이지 로드의 최대 0.5% 에서 실험용 기능을 사용 설정하는 것으로 제한되지만 이는 매우 큰 사이트에서만 문제가 됩니다.

소프트 탐색을 어떻게 측정할 수 있나요?

소프트 탐색 실험이 사용 설정되면 측정항목은 평소와 같이 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 플래그가 필요합니다. 성능 관찰자 수준에서 이러한 명시적인 선택은 기존 성능 관찰자가 이러한 추가 항목으로 인해 놀라지 않도록 하는 것입니다. 소프트 탐색을 위해 코어 웹 바이탈을 측정하려고 할 때 몇 가지 추가 고려사항을 고려해야 하기 때문입니다.

타이밍은 여전히 원래의 '하드' 탐색 시작 시간을 기준으로 반환됩니다. 예를 들어 소프트 탐색의 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으로 0으로 보고하는 것입니다. web-vitals 라이브러리가 현재 소프트 탐색에 사용하는 메서드입니다.

향후 Google에서는 어떤 요청이 소프트 탐색의 '탐색 요청'인지 더 정확하게 파악할 수 있는 방법을 지원할 수 있으며 더 정확한 TTFB 측정이 가능할 예정입니다. 하지만 이는 현재 실험에 포함되어 있지 않습니다.

기존 및 신규 항목을 모두 측정하는 방법은 무엇인가요?

이 실험 중에는 CrUX가 측정하고 코어 웹 바이탈 이니셔티브의 공식 데이터 세트로 보고하는 항목과 일치하도록 '하드' 페이지 탐색을 기반으로 현재 방식으로 코어 웹 바이탈을 계속 측정하는 것이 좋습니다.

소프트 탐색을 추가로 측정하여 향후 측정 방법을 확인하고 이 구현의 실제 작동 방식에 관해 Chrome팀에 의견을 제공할 기회를 마련해야 합니다. 이렇게 하면 귀하 및 Chrome팀이 앞으로 API를 구축하는 데 도움이 됩니다.

둘 다 측정하려면 소프트 탐색 모드 (예: 여러 FCP 및 추가 LCP 이벤트)에서 발생할 수 있는 새 이벤트를 알고 있어야 하며, 소프트 탐색에만 적용되는 향후 이벤트를 무시하면서 적절한 시점에 이러한 측정항목을 마무리하여 이러한 이벤트를 적절하게 처리해야 합니다.

`web-vitals` 라이브러리를 사용하여 소프트 탐색을 위한 코어 웹 바이탈 측정

모든 미묘한 차이를 고려하는 가장 쉬운 방법은 별도의 soft-navs branch에서 소프트 탐색을 실험적으로 지원하는 web-vitals JavaScript 라이브러리를 사용하는 것입니다 (npm 및 unpkg)에서도 사용할 수 있습니다. 이는 다음과 같은 방법으로 측정할 수 있습니다 (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만 `web-vitals` 라이브러리에 의해 보고됩니다.
LCP	소프트 탐색 시작 시간을 기준으로 다음으로 가장 큰 콘텐츠가 포함된 페인트 시간입니다. 이전 탐색의 기존 페인트는 고려되지 않습니다. 따라서 LCP는 0 이상입니다. 평소와 같이 LCP가 최종 결정되기 때문에 상호작용 시 또는 페이지가 백그라운드 상태일 때 보고됩니다.
CLS	탐색 시간 사이의 가장 큰 이동 기간입니다. 평소와 같이 페이지가 백그라운드 상태일 때에만 CLS를 확정할 수 있습니다. 변동이 없으면 값 0이 보고됩니다.
INP	탐색 시간 사이의 INP입니다. 평소와 같이 이는 상호작용 시 또는 페이지가 백그라운드 상태일 때 보고됩니다. 그래야 INP를 완료할 수 있기 때문입니다. 상호작용이 없으면 0 값이 보고되지 않습니다.

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

이러한 변경사항이 코어 웹 바이탈 측정의 일부가 되나요?

이 소프트 탐색 실험은 바로 실험입니다. 코어 웹 바이탈 이니셔티브에 통합할지 결정하기 전에 휴리스틱을 평가하고 휴리스틱이 사용자 환경을 더 정확하게 반영하는지 확인하고자 합니다. Google은 이 실험을 하게 되어 매우 기쁘게 생각하지만, 이 실험으로 현재의 측정치가 대체될지 또는 언제 대체될지를 보장할 수는 없습니다.

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

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

이 실험이 성공할 경우 CrUX에서 소프트 탐색이 정확히 얼마나 정확하게 보고될지는 아직 결정되지 않았습니다. 현재의 '하드' 탐색이 처리되는 것과 동일하게 취급된다는 것은 아닙니다.

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

따라서 이러한 소프트 탐색을 CrUX에서 별도로 보고하거나, 특정 페이지 또는 페이지 그룹의 코어 웹 바이탈을 계산할 때 가중치를 부여할 수도 있습니다. 휴리스틱이 발전함에 따라 부분 로드 소프트 탐색을 완전히 제외할 수도 있습니다.

현재 이 팀은 이 실험의 성공 여부를 판단할 수 있는 휴리스틱 및 기술 구현에 집중하고 있으므로 이러한 측면에 대한 결정이 내려지지 않았습니다.

의견

Google은 다음 위치에서 이 실험에 대한 의견을 적극적으로 받고 있습니다.

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

변경 로그

이 API는 실험 단계에 있으며 안정적인 API보다 더 많은 변화가 발생하고 있습니다. 자세한 내용은 소프트 탐색 휴리스틱 변경 로그를 참고하세요.

결론

소프트 탐색 실험은 코어 웹 바이탈 이니셔티브가 현재 측정항목에서 누락된 현대 웹의 일반적인 패턴을 측정하기 위해 어떻게 발전할 수 있는지를 보여주는 흥미로운 접근 방식입니다. 이 실험은 아직 초기 단계이며 아직 해야 할 일이 많이 남아 있습니다. 그러나 지금까지 더 광범위한 웹 커뮤니티에서 실험할 수 있도록 진전을 이루는 것은 중요한 단계입니다. 이 실험에서 얻은 의견을 수집하는 것도 실험의 또 다른 중요한 부분이므로 이 개발에 관심이 있는 분들은 이번 기회를 활용하여 API를 형성하여 Google에서 측정하고자 하는 내용을 대표할 수 있도록 해주시기 바랍니다.

감사의 말

Unsplash에 속한 요르단 마드리드의 썸네일 이미지