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

소프트 탐색 측정 실험

Barry Pollard

Michal Mocny

게시일: 2023년 2월 1일, 최종 업데이트: 2025년 7월 31일

2025년 7월 업데이트: Chrome 139 (7월 30일부터 안정화 버전 출시)부터 새로운 소프트 탐색 오리진 트라이얼이 시작됩니다. 개발자는 chrome://flags/#soft-navigation-heuristics를 사용 설정하여 Chrome 139에서 이 기능을 실험할 수도 있습니다.

핵심 성능 보고서 이니셔티브는 출시 이후 웹사이트가 생성되거나 로드되는 방식의 기술적 세부정보가 아닌 웹사이트의 실제 사용자 환경을 측정해 왔습니다. 세 가지 Core Web Vitals 측정항목은 사용자 중심 측정항목으로 만들어졌습니다. 이는 사용자가 페이지의 성능을 인식하는 방식과 관련이 없는 경우가 많았던 타이밍을 측정하는 DOMContentLoaded 또는 load와 같은 기존 기술 측정항목의 발전된 형태입니다. 따라서 사이트가 제대로 작동한다면 사이트를 빌드하는 데 사용된 기술이 점수에 영향을 미치지 않습니다.

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

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

Chrome팀은 이 문제를 한동안 고려해 왔으며, 기존의 다중 페이지 아키텍처 (MPA)로 구현된 웹사이트가 측정되는 방식과 유사하게 '소프트 탐색'의 정의와 핵심 성능 보고서가 이를 위해 측정되는 방식을 표준화하려고 합니다.

Google에서는 지난 오리진 트라이얼 이후 API를 개선하기 위해 노력해 왔으며, 이제 개발자에게 최신 버전을 사용해 보고 출시 전에 접근 방식에 관한 의견을 제공해 달라고 요청하고 있습니다.

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

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

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

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

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

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

soft-navigation PerformanceTiming 이벤트는 각 소프트 탐색이 감지된 후에 발생합니다.
의미 있는 페인트를 유발하는 상호작용 후에는 새로운 interaction-contentful-paint가 방출됩니다. 이 속성은 페인트가 소프트 탐색에 걸쳐 있는 경우 소프트 탐색의 최대 콘텐츠 렌더링 시간 (LCP)을 측정하는 데 사용할 수 있습니다. 원래 구현에서는 largest-contentful-paint 측정항목을 재설정하여 다시 내보낼 수 있었지만, 여기에서는 단순성과 향후 확장성을 위해 이 대체 접근 방식을 사용합니다.
이벤트와 관련된 탐색 항목에 해당하는 각 성능 타이밍 (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event, layout-shift)에 navigationId 속성이 추가되어 최대 콘텐츠 렌더링 시간 (LCP), 누적 레이아웃 변경 (CLS), 다음 페인트까지의 상호작용 (INP)을 계산하고 올바른 URL에 기여도를 부여할 수 있습니다.

이러한 변경사항을 통해 코어 웹 바이탈과 일부 관련 진단 측정항목을 페이지 탐색별로 측정할 수 있지만 고려해야 할 몇 가지 미묘한 차이가 있습니다.

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

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

CLS 및 INP 측정항목은 전체 페이지 수명 주기에 걸쳐 측정되는 것이 아니라 소프트 탐색 URL별로 분류될 수 있습니다.
largest-contentul-paint 항목은 상호작용에서 이미 완료되었으므로 초기 '하드' 탐색 LCP를 측정하는 데만 사용되므로 측정 방식을 변경하는 추가 로직이 필요하지 않습니다.
새 interaction-contentful-paint 측정항목은 상호작용에서 발생하며, 이를 사용하여 소프트 탐색의 LCP를 측정할 수 있습니다.
소프트 탐색을 올바른 URL에 귀속시키려면 이러한 항목을 사용하여 애플리케이션 코드에서 성능 항목의 새 navigationID 속성을 고려해야 할 수 있습니다.
특히 이전 Chrome 버전과 다른 브라우저를 사용하는 사용자는 이 소프트 탐색 API를 지원하지 않습니다. 일부 사용자는 Core Web Vitals 측정항목을 보고하더라도 소프트 탐색 측정항목을 보고하지 않을 수 있습니다.
기본적으로 사용 설정되지 않는 실험적인 새 기능이므로 사이트에서 의도치 않은 부작용이 있는지 이 기능을 테스트해야 합니다.

RUM 제공업체에 문의하여 소프트 탐색으로 핵심 성능 보고서 측정을 지원하는지 확인하세요. 많은 기업이 이 새로운 표준을 테스트할 계획이며 이전 고려사항을 고려할 것입니다. 한편 일부 제공업체는 자체 휴리스틱을 기반으로 실적 측정항목을 제한적으로 측정할 수 있도록 허용하기도 합니다.

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

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

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

개발자의 경우 chrome://flags/#soft-navigation-heuristics에서 플래그를 사용 설정하여 이를 사용 설정할 수 있습니다. '고급 페인트 기여 분석 사용 설정 (적극적인 캐시 사전 페인트 워크)' 옵션이 권장 옵션이며 곧 기본값이 될 예정입니다. 또는 Chrome을 실행할 때 --enable-features=SoftNavigationHeuristics:mode/advanced_paint_attribution 명령줄 인수를 사용하여 사용 설정할 수 있습니다.

모든 방문자가 영향을 확인할 수 있도록 이 기능을 사용 설정하려는 웹사이트의 경우 Chrome 139부터 실행되는 개발자용 체험판이 제공됩니다. 체험판에 가입하고 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});

API가 최신 변경사항에 따라 includeSoftNavigationObservations 플래그가 더 이상 필요하지 않으며 향후 삭제될 가능성이 높지만, 현재는 Chrome에서 소프트 탐색 기능을 사용 설정하는 것 외에도 성능 관찰자 수준에서 명시적으로 선택해야 합니다.

타이밍은 여전히 원래 '하드' 탐색 시작 시간을 기준으로 반환됩니다. 따라서 예를 들어 소프트 탐색의 LCP를 계산하려면 interaction-contentful-paint 타이밍을 가져와 이전에 자세히 설명한 대로 적절한 소프트 탐색 시작 시간을 빼서 소프트 탐색과 관련된 타이밍을 구해야 합니다. 예를 들어 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: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

일부 측정항목은 페이지 수명 전반에 걸쳐 측정되어 왔습니다. 예를 들어 LCP는 상호작용이 발생할 때까지 변경될 수 있습니다. CLS와 INP는 페이지에서 벗어날 때까지 업데이트할 수 있습니다. 따라서 각 새 소프트 탐색이 발생할 때 이전 페이지의 측정항목을 완료해야 할 수 있습니다. 즉, 초기 '하드' 탐색 측정항목이 평소보다 일찍 확정될 수 있습니다.

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

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

소프트 탐색의 LCP (interaction-contentful-paint에서 계산)는 새 페인트만 측정합니다. 이로 인해 콜드 로드에서 소프트 로드로 전환하는 등 LCP가 달라질 수 있습니다.

예를 들어 LCP 요소인 큰 배너 이미지가 포함된 페이지가 있지만 그 아래의 텍스트는 각 소프트 탐색에 따라 변경된다고 가정해 보겠습니다. 초기 페이지 로드 시 배너 이미지가 LCP 요소로 표시되고 LCP 타이밍이 이를 기반으로 합니다. 이후의 소프트 탐색에서는 아래의 텍스트가 소프트 탐색 후에 페인트되는 가장 큰 요소가 되며 새로운 LCP 요소가 됩니다. 하지만 딥 링크를 사용하여 소프트 탐색 URL로 새 페이지를 로드하면 배너 이미지가 새로 렌더링되므로 LCP 요소로 간주될 수 있습니다.

이 예에서 볼 수 있듯이 소프트 탐색의 LCP 요소는 페이지가 로드되는 방식에 따라 다르게 보고될 수 있습니다. 페이지 하단의 앵커 링크로 페이지를 로드하면 LCP 요소가 달라질 수 있는 것과 마찬가지입니다.

TTFB를 측정하는 방법

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

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

더 간단한 방법은 뒤로/앞으로 캐시 복원에 권장되는 방식과 유사하게 소프트 탐색의 TTFB를 0으로 보고하는 것입니다. 이는 web-vitals 라이브러리가 소프트 탐색에 사용하는 메서드입니다.

향후에는 어떤 요청이 소프트 탐색의 '탐색 요청'인지 더 정확하게 알 수 있는 방법을 지원하여 더 정확한 TTFB 측정이 가능해질 수 있습니다. 하지만 이는 현재 구현의 일부가 아닙니다.

이전 버전과 새 버전을 모두 측정하는 방법

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

향후 이러한 항목이 어떻게 측정될 수 있는지 확인하고 이 구현이 실제로 어떻게 작동하는지에 관해 Chrome팀에 의견을 제공할 수 있도록 소프트 탐색도 함께 측정해야 합니다. 이렇게 하면 개발자와 Chrome팀이 앞으로 API를 개선하는 데 도움이 됩니다.

LCP의 경우 이전 방식에서는 largest-contentful-paint 항목만 고려하고 새 방식에서는 largest-contentful-paint 및 interaction-contentful-paint 항목을 모두 고려해야 합니다.

CLS와 INP의 경우 이전 방식과 마찬가지로 전체 페이지 수명 주기에서 이를 측정하고, 소프트 탐색으로 타임라인을 별도로 슬라이싱하여 새 CLS 및 INP 값을 측정합니다.

`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만 보고됩니다.
LCP	소프트 탐색 시작 시간을 기준으로 한 다음 최대 콘텐츠 페인트 시간입니다. 이전 탐색에서 표시된 기존 페인트는 고려되지 않습니다. 따라서 LCP는 0 이상입니다. 일반적으로 LCP는 상호작용이 발생하거나 페이지가 백그라운드로 전환될 때 보고됩니다. 그래야만 LCP가 완료될 수 있기 때문입니다.
CLS	탐색 시간 사이의 가장 큰 교대 시간 창입니다. 일반적으로 페이지가 백그라운드로 전환될 때 발생합니다. 그래야 CLS가 최종적으로 결정될 수 있기 때문입니다. 교대근무가 없으면 0 값이 보고됩니다.
INP	탐색 시간 사이의 INP입니다. 일반적으로 INP는 상호작용 시 또는 페이지가 백그라운드로 전환될 때 보고됩니다. 그래야만 INP가 최종적으로 결정될 수 있기 때문입니다. 상호작용이 없으면 0 값이 보고되지 않습니다.

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

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

이 소프트 탐색 실험은 실험입니다. Google은 핵심 성능 보고서 이니셔티브에 통합할지 여부를 결정하기 전에 휴리스틱을 평가하고 사용자 환경을 더 정확하게 반영하는지 확인하고자 합니다. 이번 실험의 가능성에 큰 기대를 걸고 있지만, 이 실험이 현재 측정을 대체할지 여부와 시기는 보장할 수 없습니다.

실험, 사용된 휴리스틱, 경험을 더 정확하게 반영하는지 여부에 관한 웹 개발자의 의견을 소중하게 생각합니다. 부드러운 탐색 GitHub 저장소에서 의견을 제공하는 것이 가장 좋지만 Chrome의 구현과 관련된 개별 버그는 Chrome 문제 추적기에 신고해야 합니다.

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

이 실험이 성공할 경우 CrUX에 소프트 탐색이 어떻게 보고될지도 아직 결정되지 않았습니다. 현재 '하드' 탐색과 동일하게 처리된다고 단정할 수는 없습니다.

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

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

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

의견

Google에서는 다음 채널을 통해 이 실험에 대한 의견을 적극적으로 수렴하고 있습니다.

소프트 탐색 휴리스틱 및 표준화
이러한 휴리스틱의 Chrome 구현 문제
[email protected]에서 일반적인 웹 바이탈 의견을 제공할 수 있습니다.

변경 로그

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

결론

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

감사의 말씀

썸네일 이미지: 조던 마드리드(Unsplash 제공)

이 작업은 Yoav Weiss가 Google에 있을 때 처음 시작한 작업의 연속입니다. 이 API를 위해 노력해 주신 Yoav에게 감사드립니다.

소프트 탐색 측정 실험 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

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

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

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

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

소프트 탐색을 측정하려면 어떻게 해야 하나요?

소프트 탐색 보고

적절한 URL에 대해 측정항목을 보고합니다.

소프트 탐색의 startTime 가져오기

소프트 탐색별로 핵심 웹 바이탈 측정

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

TTFB를 측정하는 방법

이전 버전과 새 버전을 모두 측정하는 방법

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

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

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

의견

변경 로그

결론

감사의 말씀

소프트 탐색 측정 실험

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

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