소프트 탐색 측정

Barry Pollard

Michal Mocny

게시: 2023년 2월 1일, 최종 업데이트: 2026년 9월 20일

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

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

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

Chrome팀은 이 문제를 오랫동안 고민해 왔으며, 기존의 다중 페이지 아키텍처 (MPA)로 구현된 웹사이트를 측정하는 방식과 유사하게 '소프트 탐색'의 정의와 이에 대한 Core Web Vitals 측정 방법을 표준화하고자 합니다.

Google은 개발자 의견을 바탕으로 제안을 여러 차례 개선했으며, Chrome 151부터 이 문제를 해결하는 데 도움이 되는 두 가지 새로운 성능 API를 출시했습니다. 또한 Chrome 사용자 경험 보고서 (CrUX)에서 소프트 탐색 측정항목을 실험용 측정항목으로 제공합니다.

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

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

• 탐색은 사용자 작업에 의해 시작됩니다.
• 탐색으로 인해 사용자에게 표시되는 URL이 변경됩니다.
• 상호작용으로 인해 표시되는 페인트가 발생합니다.

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

소프트 탐색을 위한 DevTools 지원

실시간 측정항목 뷰의 DevTools 성능 패널과 통계 및 마커 지원이 포함된 트레이스 뷰에 소프트 탐색 지원이 추가되었습니다.

Chrome은 웹 개발자를 위해 부드러운 탐색을 어떻게 구현하나요?

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

• 각 소프트 탐색이 감지된 후 soft-navigation PerformanceTiming 이벤트가 전송됩니다.
• 이 soft-navigation 항목에는 navigationId, name 속성의 새 URL, 시작 상호작용의 interactionId가 포함됩니다.
• 콘텐츠가 포함된 페인트를 유발하는 상호작용 후에 하나 이상의 interaction-contentful-paint 항목이 전송됩니다. 여기에는 소프트 탐색의 최대 콘텐츠 페인트 (LCP)를 측정하는 데 사용할 수 있는 largestContentfulPaint 항목이 포함됩니다.
• navigationId 속성이 각 성능 타이밍 (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event, layout-shift)에 추가됩니다. 이는 이벤트가 발생한 탐색 항목에 해당합니다. 이러한 항목이 부드러운 탐색에 걸쳐 있는 경우 항목이 전송된 시점에 따라 이전 또는 다음 navigationId가 포함될 수 있습니다. 자세한 내용은 적절한 URL에 대한 측정항목 보고 섹션을 참고하세요.
• soft-navigation에는 해당 탐색의 가장 큰 interaction-contentful-paint 항목을 가져오는 getLargestInteractionContentfulPaint() 함수가 포함됩니다. 그런 다음 이를 해당 탐색의 초기 LCP로 사용할 수 있으며, 해당 상호작용에 대한 더 많은 interaction-contentful-paint 항목이 관찰되면 해당 LCP를 업데이트할 수 있습니다. 이전 오리진 트라이얼에서 사용할 수 있었던 largestInteractionContentfulPaint 속성을 대체합니다.
• 일부 interaction-contentful-paint 항목은 부드러운 탐색이 발생하기 전에 발생할 수 있습니다 (URL 업데이트가 이러한 페인트 이후에 발생하지 않는 경우). 이러한 경우 getLargestInteractionContentfulPaint() 함수는 부드러운 탐색이 완료된 후 이전 항목을 버퍼링하고 다시 살펴볼 필요가 없습니다. getLargestInteractionContentfulPaint()에서 반환된 항목은 내보낸 시점의 가장 큰 interaction-contentful-paint 항목의 정확한 사본이므로, 해당 항목은 페인트가 발생한 시점이므로 이전 navigationId를 사용했을 수 있지만 이러한 페인트는 새 navigationId를 기준으로 측정해야 합니다.
• soft-navigation 항목에는 해당 탐색의 FCP로 paintTime 및 presentationTime도 포함됩니다.
• 추가 상호작용 후에도 interaction-contentful-paint 항목이 전송되지만 URL의 LCP는 이를 제외하기 위해 소프트 탐색 interactionId과 일치하는 interaction-contentful-paint 항목으로 제한되어야 하며 그 안의 largestContentfulPaint 속성으로만 제한되어야 합니다.

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

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

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

• soft-navigation 항목을 모니터링하면 성능 항목을 각 '탐색'으로 '슬라이스'할 수 있습니다.
• CLS 및 INP 측정항목은 전체 페이지 수명 주기 동안 측정되는 대신 이미 재량에 따라 분할될 수 있지만, 부드러운 탐색 기능은 사용된 기본 기술과 관계없이 이 시점을 표준화된 방식으로 측정합니다.
• largest-contentful-paint 항목은 상호작용 (소프트 탐색을 시작하는 데 필요함)에서 완료되므로 초기 '하드' 탐색 LCP를 측정하는 데만 사용할 수 있습니다. 즉, 소프트 탐색이 측정될 때 이 값이 변경되지 않으므로 초기 하드 탐색 페이지 로드의 LCP를 평소와 같이 측정할 수 있습니다.
• 상호작용에서 내보내는 새로운 interaction-contentful-paint 항목을 사용하여 그 안의 largestContentfulPaint 속성을 확인하여 부드러운 탐색의 LCP를 측정할 수 있지만, 이 항목을 사용하는 방법에 관한 몇 가지 고려사항이 있습니다. 이 도움말에서 설명하겠습니다.
• 모든 사용자가 이 소프트 탐색 기능을 지원하는 것은 아닙니다. 특히 다른 브라우저나 151 이전 버전의 Chrome을 사용하는 사용자는 지원하지 않습니다. 일부 사용자는 Core Web Vitals 측정항목을 보고하더라도 부드러운 탐색 기반 측정항목을 보고하지 않을 수 있습니다.

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

부드러운 탐색의 측정항목을 측정하는 방법에 관한 자세한 내용은 부드러운 탐색당 Core Web Vitals 측정 섹션을 참고하세요.

Chrome에서 부드러운 탐색을 사용 설정하려면 어떻게 해야 하나요?

부드러운 탐색 기능은 Chrome 151부터 기본적으로 사용 설정됩니다.

Soft Navigations API 지원을 감지하는 기능

다음 코드를 사용하여 API가 지원되는지 테스트할 수 있습니다.

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

또는

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

부드러운 탐색을 측정하려면 어떻게 해야 하나요?

지원되는 경우 다른 측정항목과 마찬가지로 PerformanceObserver API를 사용하여 측정항목을 보고할 수 있습니다. 하지만 이러한 측정항목에는 추가로 고려해야 할 사항이 있습니다.

소프트 탐색 보고

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

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

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

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

소프트 탐색이 표시되면 이전 페이지의 Core Web Vitals를 완료한 후 이전 URL에 대해 보고하고 새 URL에 대한 새 모니터링을 시작해야 합니다.

적절한 soft-navigation 항목의 name 속성에는 측정항목을 보고할 새 URL이 포함되며, navigationId는 이 탐색의 고유한 참조가 됩니다 (단일 페이지 애플리케이션의 전체 기간 동안 동일한 URL을 여러 번 방문할 수 있으므로).

이는 각 soft-navigation 항목으로 설정되어야 하며 다음 soft-navigation 항목이 수신될 때까지 측정항목을 보고하는 데 사용되어야 합니다.

interaction-contentful-paint의 올바른 URL 신고

모든 interaction-contentful-paint 항목을 navigationId를 사용하여 매핑하고 해당 URL의 LCP로 보고해야 하는 것은 아니므로 interaction-contentful-paint 항목에서 LCP를 계산하려면 추가 고려사항이 필요합니다.

• 첫 번째 문제는 URL 업데이트 전에 페인트가 발생하면 부드러운 탐색이 발생하기 전에 interaction-contentful-paint 항목이 전송될 수 있다는 것입니다. 이 경우 navigationId은 이전 URL에 대한 것입니다. URL이 먼저 업데이트되면 페인트가 부드러운 탐색을 완료하고 이 경우 soft-navigation 항목이 먼저 전송되고 interaction-contentful-paint에 새 URL이 포함됩니다.
• 두 번째 문제는 interaction-contentful-paint 항목이 소프트 탐색의 LCP를 넘어 이 실적 측정항목의 범위가 확장됨에 따라 최신 상호작용에 대해 계속 내보내진다는 것입니다. LCP의 경우 후속 상호작용이 아닌 부드러운 탐색 로드의 페인트만 고려해야 합니다.

따라서 올바른 URL을 얻으려면 navigationId 대신 interactionId를 사용하여 interaction-contentful-paint 항목을 soft-navigation-entries에 매핑해야 합니다. 이렇게 하면 이전 navigationId가 있는 항목을 처리하고 LCP에 고려해서는 안 되는 interaction-contentful-paint 항목을 필터링할 수 있습니다.

또한 soft-navigation 항목의 getLargestInteractionContentfulPaint() 함수를 먼저 처리하여 soft-navigation entries가 전송되기 전에 발생한 interaction-contentful-paint 항목을 처리해야 합니다.

소프트 탐색의 startTime 가져오기

소프트 탐색을 포함한 모든 성능 타이밍과 Core Web Vitals 측정항목을 계산하는 데 사용되는 항목은 초기 '하드' 페이지 탐색 시간으로부터의 시간으로 보고됩니다. 따라서 소프트 탐색 시작 시간을 소프트 탐색 로드 측정항목 시간 (예: LCP)에서 빼서 이 소프트 탐색 시간을 기준으로 보고해야 합니다.

탐색 시작 시간은 적절한 soft-navigation 항목에 매핑하고 startTime를 사용하여 유사한 방식으로 가져올 수 있습니다.

startTime는 소프트 탐색을 시작한 초기 상호작용 (예: 버튼 클릭)의 시간입니다. 이는 '시작 시간'이 새 페이지가 브라우저에 '커밋'되고 일부 이벤트 핸들러 코드가 실행된 후인 '하드 탐색'과는 다소 다릅니다. 소프트 탐색 시작 시간에도 상호작용 시작 시간부터 측정하므로 이벤트 핸들러 코드가 포함됩니다.

소프트 탐색당 Core Web Vitals 측정

Core Web Vitals를 측정하려면 soft-navigation 항목을 수신 대기하고 이를 수신할 때 측정항목을 재설정합니다. FCP는 presentationTime를 기반으로 내보낼 수 있고 LCP는 getLargestInteractionContentfulPaint() 항목으로 초기화할 수 있습니다. INP, CLS는 페이지 로드 시와 마찬가지로 0으로 초기화해야 합니다.

그런 다음 평소와 같이 LCP, INP, CLS를 측정하고 모니터링할 수 있습니다 (interactionId 일치를 제공하는 LCP에 interaction-contentful-paint를 사용하는 경우는 예외). interactionId는 앞에서 설명한 대로 URL에 대한 항목의 이름을 지정하는 데 사용할 수 있습니다.

타이밍은 원래 '하드' 탐색 시작 시간을 기준으로 반환됩니다. 따라서 예를 들어 부드러운 탐색의 LCP를 계산하려면 interaction-contentful-paint 타이밍을 가져와 앞서 설명한 대로 적절한 부드러운 탐색 시작 시간을 빼서 부드러운 탐색과 관련된 타이밍을 가져와야 합니다.

일부 측정항목은 일반적으로 페이지의 전체 기간 동안 측정됩니다. 예를 들어 LCP는 상호작용이 발생할 때까지 변경될 수 있습니다. CLS 및 INP는 상호작용과 관계없이 페이지에서 다른 페이지로 이동할 때까지 업데이트할 수 있습니다. 따라서 새로운 소프트 탐색이 발생할 때마다 이전 탐색의 측정항목을 확정해야 합니다. 즉, 소프트 탐색으로 Core Web Vitals를 측정할 때 초기 '하드' 탐색 측정항목이 평소보다 일찍 완료될 수 있습니다.

마찬가지로, 이러한 장기 측정항목의 새로운 부드러운 탐색에 대한 측정항목을 측정하기 시작할 때 측정항목을 '재설정'하거나 '재초기화'하고 이전 '페이지'에 설정된 값을 기억하지 않고 새 측정항목으로 처리해야 합니다. 즉, '최대' 페인트, 다음 페인트에 대한 상호작용 또는 레이아웃 변경에 대한 이해가 재설정되어 처음부터 다시 측정할 수 있습니다.

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

소프트 탐색의 LCP (interaction-contentful-paint에서 계산됨)는 새 페인트만 측정하며 탐색을 유발한 상호작용과 연결된 페인트만 측정합니다. 이로 인해 소프트 탐색의 콜드 로드에서 소프트 로드로의 LCP가 달라질 수 있습니다.

예를 들어 LCP 요소인 큰 배너 이미지가 포함되어 있지만 그 아래의 텍스트가 소프트 탐색마다 변경되는 페이지를 생각해 보겠습니다. 초기 페이지 로드 시 배너 이미지가 LCP 요소로 플래그 지정되고 LCP 타이밍은 이를 기반으로 합니다. 이후의 부드러운 탐색의 경우 아래의 텍스트가 부드러운 탐색 후에 페인트되는 가장 큰 요소가 되며 새로운 LCP 요소가 됩니다. 하지만 페이지가 소프트 탐색 URL에 대한 딥 링크로 로드되면 배너 이미지가 새 페인트가 되므로 LCP 요소로 간주될 수 있습니다.

마찬가지로 애니메이션은 발생하는 소프트 탐색과 관계없이 페이지의 일부를 지속적으로 업데이트할 수 있습니다. 배경 애니메이션으로 인한 새로운 페인트는 새로운 부드러운 탐색의 LCP에 고려되지 않습니다. 하지만 이 URL에서 페이지가 새로고침된 경우 LCP로 간주될 수 있습니다.

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

TTFB를 측정하는 방법

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

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

더 간단한 방법은 뒤로-앞으로 캐시 복원에 권장하는 것과 유사한 방식으로 부드러운 탐색의 TTFB를 0으로 보고하는 것입니다. 이는 web-vitals 라이브러리가 부드러운 탐색에 사용하는 방법이며 현재 이 측정항목에 권장되는 방법입니다.

두 방법론을 모두 사용하여 Core Web Vitals를 측정해야 하나요?

이러한 새로운 API는 Chromium 기반 브라우저로만 제한되지만, 사이트에서는 소프트 탐색으로 분할하고 하드 탐색으로 계속 분할하여 두 가지를 모두 측정할 수 있습니다. 이렇게 하면 브라우저 간 비교와 이전 추세 비교가 가능합니다.

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

CLS 및 INP의 경우 현재 방식과 마찬가지로 전체 페이지 수명 주기에 걸쳐 이를 측정하고, 소프트 탐색으로 타임라인을 별도로 분할하여 새로운 CLS 및 INP 값을 별도로 측정하는 것을 의미합니다.

그러면 분석을 위해 측정항목을 두 번 비콘하고 저장해야 합니다.

web-vitals 라이브러리를 사용하여 부드러운 탐색의 Core Web Vitals 측정

모든 미묘한 차이를 고려하는 가장 쉬운 방법은 v6.0.0부터 소프트 탐색을 지원하는 web-vitals JavaScript 라이브러리를 사용하는 것입니다. 이는 다음과 같은 방법으로 측정할 수 있습니다 (doTraditionalProcessing 및 doSoftNavProcessing를 적절하게 대체).

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

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

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});

또한 web-vitals 라이브러리는 콜백에 제공된 항목에 navigationId와 navigationURL가 모두 포함되어 있으므로 앞에서 설명한 대로 올바른 URL에 대해 측정항목을 보고하도록 합니다.

web-vitals 라이브러리는 부드러운 탐색에 대해 다음 측정항목을 보고합니다.

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

궁극적인 목표는 실제 사용자가 경험하는 실적을 더 잘 측정할 수 있는 수단을 제공하는 것입니다. 따라서 API가 출시된 후 모든 도구에서 노출되는 Core Web Vitals 측정에 이러한 측정항목을 포함하는 것이 목표입니다.

CrUX에서 부드러운 탐색은 어떻게 보고되나요?

CrUX에서 Core Web Vitals 측정항목의 실험용 버전을 출시했습니다. 이렇게 하면 첫 번째 소프트 탐색 후 '하드 탐색' CLS 및 INP가 종료되고 각 소프트 탐색에 대한 추가 LCP, CLS, INP 측정도 포함됩니다. 2027년 5월에 이러한 실험용 측정항목을 안정적인 측정항목으로 전환할 계획입니다. 자세한 내용은 이제 CrUX에서 실험용 소프트 탐색 측정항목을 사용할 수 있음 블로그 게시물을 참고하세요.

다른 브라우저에서 부드러운 탐색을 처리하는 방법

API를 지원하지 않는 브라우저에서는 소프트 탐색을 프로그래매틱 방식으로 감지하기 어렵습니다. 이것이 바로 이 API를 개발한 이유입니다.

Navigation API를 사용하여 URL 변경사항을 모니터링할 수 있습니다. 이를 통해 URL별로 INP를 슬라이스할 수 있습니다 (CLS도 마찬가지지만 현재는 Chromium 전용이므로 측정되지 않음). 하지만 이 방법으로는 근사치만 구할 수 있는 페인트 측정항목 (FCP 및 LCP)을 해결할 수 없습니다.

동시에 이 API에서 제공하는 통계는 소프트 탐색의 타이밍을 측정하고 측정항목을 올바른 탐색에 기여하는 데 있어 무시하기에는 너무 가치가 있다고 생각합니다. 현재 교차 브라우저 지원이 부족하지만 이 새로운 API를 사용하는 것이 좋습니다. Core Web Vitals가 출시되었을 때와 마찬가지로, 현재는 Chromium 기반 브라우저에만 표시되더라도 확인된 문제와 성능 솔루션은 모든 브라우저에 영향을 미칠 가능성이 높습니다.

Google은 계속해서 표준화 프로세스를 진행하고 다른 브라우저 공급업체와 협력하여 이 API의 중요성을 보여줄 것입니다.

의견

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

• API에 관한 의견은 GitHub의 문제로 제기해야 합니다.
• Chromium 구현의 버그가 아직 알려진 문제 중 하나가 아닌 경우 Chrome의 Issue Tracker에서 제기해야 합니다.
• 일반적인 Web Vitals 의견은 web-vitals-feedback@googlegroups.com으로 공유할 수 있습니다.

확실하지 않더라도 걱정하지 마세요. 어느 곳에서든 의견을 듣고 두 곳 모두에서 문제를 분류하여 올바른 위치로 리디렉션합니다.

변경 로그

이 API가 개발되면서 안정적인 API보다 더 많은 변경사항이 발생했습니다. 자세한 내용은 소프트 탐색 변경 로그를 참고하세요.

결론

부드러운 탐색 기능은 Core Web Vitals 이니셔티브가 어떻게 발전하여 현재 측정항목에서 누락된 최신 웹의 일반적인 패턴을 측정할 수 있는지에 관한 흥미로운 접근 방식입니다. Google은 광범위한 웹 커뮤니티에서 상당한 의견을 수집했으며 이 API의 잠재력에 고무되어 있습니다.

감사의 말씀

썸네일 이미지: Jordan Madrid(Unsplash 제공)

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