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

소프트 탐색 측정 실험

Barry Pollard

Yoav Weiss

2024년 8월 업데이트: 두 번째 소프트 탐색 오리진 트레일이 5월 29일에 종료되었습니다. Chrome팀은 시간을 들여 실험 의견을 검토하고 이 API의 다음 단계를 고려하고 있습니다. Google은 일부 정확성 문제를 해결하기 위해 노력하고 있으며 기능을 개발하기 전에 오리진 트라이얼이 또 한 번 더 필요하다고 생각합니다. 그동안 개발자는 chrome://flags/#enable-experimental-web-platform-features를 사용 설정하여 이 기능을 실험해 볼 수 있습니다.

코어 웹 바이탈 이니셔티브는 출시 이후 웹사이트 생성 또는 로드 방식의 기술적인 세부정보보다는 웹사이트의 실제 사용자 경험을 측정하는 데 중점을 두었습니다. 세 가지 Core Web Vitals 측정항목은 사용자 중심 측정항목으로 만들어졌습니다. 이는 사용자가 페이지 성능을 인식하는 방식과 관련이 없는 경우가 많았지만 DOMContentLoaded 또는 load와 같은 기존 기술 측정항목을 발전시킨 것입니다. 그렇기 때문에 사이트를 구축하는 데 사용된 기술이 사이트 성능이 좋더라도 점수에 영향을 주지 않습니다.

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

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

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

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

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

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

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

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

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

soft-navigation PerformanceTiming 이벤트는 각 소프트 탐색이 감지된 후에 내보내집니다.
Performance 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 기반 브라우저로 업그레이드한 것은 아닙니다. 따라서 일부 사용자는 소프트 탐색 측정항목을 보고하지 않을 수 있습니다.
기본적으로 사용 설정되지 않는 실험용 새 기능이므로 사이트에서는 이 기능을 테스트하여 의도하지 않은 다른 부작용이 없는지 확인해야 합니다.

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

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)의 기준을 설정하는 데 필요합니다.

소프트 탐색당 Core Web Vitals 측정

소프트 탐색 측정항목 항목을 포함하려면 성능 관찰자의 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 라이브러리가 소프트 탐색에 사용하는 메서드입니다.

향후 어떤 요청이 소프트 탐색의 '탐색 요청'인지 알 수 있는 더 정확한 방법을 지원할 수 있습니다. 더 정확한 TTFB를 측정할 수 있게 됩니다 하지만 이는 현재 실험에 포함되어 있지 않습니다.

이전 및 새 항목을 모두 측정하는 방법

이 실험 중에는 '어려움'을 기반으로 한 현재 방식으로 Core Web Vitals를 계속 측정하는 것이 좋습니다. CrUX가 Core Web Vitals 이니셔티브의 공식 데이터 세트로 측정하고 보고하는 내용과 일치하는 페이지 탐색입니다.

소프트 탐색을 추가로 측정하여 향후 소프트 탐색 측정 방식을 파악하고 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 구현은 현재 개발 중이며 브랜치에 새로운 변경사항이 게시됨에 따라 변경될 수 있습니다. 소프트 탐색에서는 FCP를 지원하지 않습니다. Chrome에서 더 많은 기본 작업이 필요하기 때문입니다. web-vitals JavaScript 라이브러리를 사용하는 사용자는 프로덕션 사이트에서 이 라이브러리를 사용하려는 경우 이 점을 알고 있어야 하며 로컬 사본을 가져와서 해당 버전을 테스트하고 브랜치에서 변경사항을 모니터링해야 합니다.

이러한 변경사항이 Core Web Vitals 측정에 반영되나요?

이번 소프트 탐색 실험은 바로 실험입니다. Core Web Vitals 이니셔티브에 통합할지 여부를 결정하기 전에 휴리스틱을 평가하고 사용자 경험을 더 정확하게 반영하는지 확인하고자 합니다. 이 실험을 진행할 수 있게 되어 매우 기쁩니다. 다만 이 실험이 현재의 측정값을 대체할지 또는 언제인지 보장할 수는 없습니다.

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

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

이 실험이 성공할 경우 CrUX에서 소프트 탐색이 정확히 어떻게 보고될지도 정해야 합니다. 현재 '어려움'과 동일하게 취급된다는 뜻은 아닙니다. 탐색이 처리됩니다.

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

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

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

의견

Google에서는 다음 위치에서 이 실험에 관한 의견을 기다리고 있습니다.

소프트 탐색 휴리스틱 및 표준화.
이러한 휴리스틱의 Chrome 구현 문제
일반적인 웹 vitals 의견(web-vitals-feedback@googlegrouops.com)

변경 로그

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

결론

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

감사의 말씀

Unsplash에 Jordan Madrid 제공 썸네일 이미지