게시일: 2023년 2월 1일, 최종 업데이트: 2026년 3월 30일
핵심 성능 보고서 이니셔티브는 출시 이후 웹사이트가 생성되거나 로드되는 방식의 기술적 세부정보가 아닌 웹사이트의 실제 사용자 환경을 측정해 왔습니다. 세 가지 Core Web Vitals 측정항목은 사용자 중심 측정항목으로 만들어졌습니다. 이는 사용자가 페이지의 성능을 인식하는 방식과 관련이 없는 경우가 많았던 타이밍을 측정하는 DOMContentLoaded 또는 load와 같은 기존 기술 측정항목을 개선한 것입니다. 따라서 사이트가 제대로 작동한다면 사이트를 빌드하는 데 사용된 기술이 점수에 영향을 미치지 않습니다.
현실은 이상적인 상황보다 항상 약간 더 복잡하며 인기 있는 단일 페이지 애플리케이션 아키텍처는 핵심 웹 바이탈 측정항목에서 완전히 지원되지 않았습니다. 이러한 웹 애플리케이션은 사용자가 사이트를 탐색할 때 개별 웹페이지를 로드하는 대신 페이지 콘텐츠가 JavaScript에 의해 변경되는 소위 '소프트 탐색'을 사용합니다. 이러한 애플리케이션에서는 URL을 변경하고 브라우저 방문 기록에 이전 URL을 푸시하여 뒤로 및 앞으로 버튼이 사용자가 예상하는 대로 작동하도록 함으로써 기존 웹페이지 아키텍처의 착시를 유지합니다.
많은 JavaScript 프레임워크가 이 모델을 사용하지만 각기 다른 방식으로 사용합니다. 이는 브라우저가 기존에 '페이지'로 이해하는 것과 다르기 때문에 측정하기가 어려웠습니다. 현재 페이지에서의 상호작용과 새 페이지로 간주되는 상호작용 간의 경계는 어디에 있어야 할까요?
Chrome팀은 이 문제를 오랫동안 고려해 왔으며, 기존 다중 페이지 아키텍처 (MPA)로 구현된 웹사이트가 측정되는 방식과 유사하게 '소프트 탐색'의 정의와 핵심 성능 보고서가 이를 위해 측정되는 방식을 표준화하려고 합니다.
Google에서는 지난 오리진 트라이얼에서 개발자가 제공한 의견을 바탕으로 API를 여러 차례 개선했으며, 이제 개발자가 최신 버전을 사용해 보고 출시 전에 접근 방식에 관한 의견을 제공해 주시기를 요청하고 있습니다. 이러한 반복을 통해 API가 어디에 도달했는지 확신하며, 이번 최신 오리진 트라이얼에 대한 의견을 바탕으로 올해 말에 API를 출시할 예정입니다.
소프트 탐색이란 무엇인가요?
Google에서는 다음과 같이 소프트 탐색을 정의했습니다.
- 탐색은 사용자 작업에 의해 시작됩니다.
- 탐색으로 인해 사용자에게 URL 변경사항이 표시됩니다.
- 상호작용으로 인해 페인트가 표시됩니다.
일부 사이트의 경우 이러한 휴리스틱으로 인해 거짓양성 (사용자가 실제로 '탐색'이 발생했다고 생각하지 않음) 또는 거짓음성 (이 기준을 충족하지 않음에도 사용자가 '탐색'이 발생했다고 생각함)이 발생할 수 있습니다. 소프트 탐색 사양 저장소에서 휴리스틱에 관한 의견을 보내주시면 감사하겠습니다.
소프트 탐색을 위한 DevTools 지원
트레이스 뷰의 DevTools 성능 패널에 소프트 탐색 지원이 추가되었습니다.
부드러운 탐색과 LCP의 마커가 표시되며, 이 두 가지는 일반적인 하드 탐색 항목과 구분하기 위해 *로 표시됩니다. 이 기능은 기본적으로 사용 설정되어 있으며 다음에 설명할 성능 API 변경사항과는 별개입니다. 사이트에서 부드러운 탐색 실험이 올바르게 작동하는지 빠르게 테스트할 수 있습니다.
현재는 추적 뷰에 소프트 탐색 및 LCP 타임스탬프만 표시됩니다. 기타 측정항목 (예: LCP) 및 실시간 측정항목 뷰의 지원은 나중에 추가될 예정입니다.
Chrome은 웹 개발자를 위해 소프트 탐색을 어떻게 구현하나요?
소프트 탐색 휴리스틱이 사용 설정되면 (자세한 내용은 다음 섹션 참고) Chrome에서 일부 성능 측정항목을 보고하는 방식이 변경됩니다.
soft-navigationPerformanceTiming이벤트는 각 소프트 탐색이 감지된 후에 발생합니다.- 이
soft-navigation항목에는navigationId,name속성의 새 URL, 시작 상호작용의interactionId이 포함됩니다. - 콘텐츠가 포함된 페인트를 유발하는 상호작용 후 하나 이상의
interaction-contentful-paint항목이 방출됩니다. 이는 상호작용에서 소프트 탐색을 내보낼 때 소프트 탐색의 최대 콘텐츠 페인트 (LCP)를 측정하는 데 사용할 수 있습니다. 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항목을 포함하는largestInteractionContentfulPaint항목이 포함됩니다. 그런 다음 이 값이 해당 탐색의 초기 LCP로 사용될 수 있으며, 해당 상호작용에 대한interaction-contentful-paint항목이 더 많이 관찰되면 해당 LCP가 업데이트될 수 있습니다.- URL 업데이트가 이러한 페인트가 발생한 후에 이루어지는 경우 일부
interaction-contentful-paint항목은 소프트 탐색이 발생하기 전에 발생했을 수 있습니다. 이 경우 가장 큰largestInteractionContentfulPaint항목은 오래된 항목을 버퍼링하고 다시 살펴볼 필요가 없습니다.largestInteractionContentfulPaint는 가장 큰interaction-contentful-paint항목의 정확한 사본이므로 페인트가 발생한 시점인 이전navigationId를 사용했을 것입니다. 하지만 이러한 페인트는 새navigationId에 대해 측정해야 합니다. soft-navigation항목에는 해당 탐색의 FCP로paintTime및presentationTime도 포함됩니다.interaction-contentful-paint항목은 추가 상호작용 후에도 발생하지만 URL의 LCP는 이러한 항목을 제외하기 위해 소프트 탐색interactionId와 일치하는interaction-contentful-paint항목으로 제한해야 합니다.
이러한 변경사항을 통해 고려해야 할 몇 가지 미묘한 차이가 있지만 코어 웹 바이탈과 일부 관련 진단 측정항목을 페이지 탐색별로 측정할 수 있습니다.
Chrome에서 소프트 탐색을 사용 설정하면 어떤 영향이 있나요?
이 기능을 사용 설정한 후 사이트 소유자가 고려해야 하는 변경사항은 다음과 같습니다.
soft-navigation항목을 모니터링하면 실적 항목을 각 '탐색'으로 '분할'할 수 있습니다.- CLS 및 INP 측정항목은 이미 전체 페이지 수명 주기 동안 측정하는 대신 원하는 대로 슬라이스할 수 있지만, 소프트 탐색 API는 사용된 기본 기술과 관계없이 이러한 상황이 발생하는 시점을 표준화된 방식으로 측정합니다.
largest-contentful-paint항목은 상호작용에서 완료되므로 (소프트 탐색을 시작하는 데 필요함) 초기 '하드' 탐색 LCP를 측정하는 데만 사용할 수 있습니다. 즉, 소프트 탐색이 측정될 때 변경되지 않으므로 초기 하드 탐색 페이지 로드의 LCP를 이전과 같이 측정할 수 있습니다.- 상호작용에서 방출되는 새로운
interaction-contentful-paint항목을 사용하여 소프트 탐색의 LCP를 측정할 수 있지만, 이 항목을 사용하는 방법에 관한 몇 가지 고려사항이 있습니다. 이 도움말에서 이에 대해 설명합니다. - 특히 이전 Chrome 버전과 다른 브라우저를 사용하는 사용자의 경우 이 소프트 탐색 API를 지원하지 않을 수 있습니다. 일부 사용자는 핵심 웹 바이탈 측정항목을 보고하더라도 소프트 탐색 기반 측정항목을 보고하지 않을 수 있습니다.
- 기본적으로 사용 설정되지 않는 실험적인 새 기능이므로 사이트에서 의도치 않은 부작용이 있는지 이 기능을 테스트해야 합니다.
RUM 제공업체에 문의하여 소프트 탐색으로 핵심 성능 보고서 측정을 지원하는지 확인하세요. 많은 기업에서 이 새로운 표준을 테스트할 계획이며 이전 고려사항을 고려할 것입니다. 그동안 일부 제공업체는 자체 휴리스틱을 기반으로 실적 측정항목을 제한적으로 측정할 수 있도록 허용하기도 했습니다.
소프트 탐색의 측정항목을 측정하는 방법에 관한 자세한 내용은 소프트 탐색별 Core Web Vitals 측정 섹션을 참고하세요.
Chrome에서 소프트 탐색을 사용 설정하려면 어떻게 해야 하나요?
소프트 탐색은 Chrome에서 기본적으로 사용 설정되어 있지 않지만 이 기능을 명시적으로 사용 설정하여 실험할 수 있습니다.
개발자의 경우 chrome://flags/#soft-navigation-heuristics에서 플래그를 사용 설정하여 이를 사용 설정할 수 있습니다. 또는 Chrome을 실행할 때 --enable-features=SoftNavigationHeuristics 명령줄 인수를 사용하여 사용 설정할 수 있습니다. chrome://flags/#enable-experimental-web-platform-features 플래그를 사용 설정하면 소프트 탐색도 사용 설정됩니다.
모든 방문자가 영향을 확인할 수 있도록 이 기능을 사용 설정하려는 웹사이트의 경우 Chrome 147부터 개발자용 체험판이 실행됩니다. 체험판에 가입하고 HTML 또는 HTTP 헤더에 개발자용 체험판 토큰이 포함된 메타 요소를 포함하면 체험판을 사용 설정할 수 있습니다. 자세한 내용은 오리진 트라이얼 시작하기 게시물을 참고하세요.
사이트 소유자는 모든 사용자 또는 일부 사용자를 대상으로 페이지에 오리진 트라이얼을 포함할 수 있습니다. 특히 많은 사용자에 대해 이 오리진 트라이얼을 사용 설정하는 경우 측정항목이 보고되는 방식이 어떻게 달라지는지 위의 영향 섹션을 참고하세요. CrUX는 이 소프트 탐색 설정과 관계없이 기존 방식으로 측정항목을 계속 보고하므로 이러한 영향은 받지 않습니다. 오리진 트라이얼은 14일 동안의 중앙값으로 모든 Chrome 페이지 로드의 최대 0.5% 에서 실험 기능을 사용 설정하는 것으로 제한되지만 이는 매우 큰 사이트에서만 문제가 됩니다.
소프트 탐색 API 지원 감지 기능
다음 코드를 사용하여 API가 지원되는지 테스트할 수 있습니다.
if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
// Monitor Soft Navigations
}
supportedEntryTypes는 처음 사용할 때 고정되므로 페이지에 삽입된 오리진 트라이얼 토큰에 의해 소프트 탐색 지원이 동적으로 추가되는 경우 이 기능이 활성화되기 전의 원래 값이 반환될 수 있습니다.
이 경우 기본적으로 부드러운 탐색이 지원되지 않고 전환 상태에 있는 동안 다음 대안을 사용할 수 있습니다.
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이 단일 페이지 애플리케이션의 수명 동안 여러 번 방문될 수 있으므로). 이는 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;
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이 있습니다. - 두 번째 문제는 이 성능 측정항목의 범위가 소프트 탐색의 LCP를 넘어 확장되므로
interaction-contentful-paint항목이 최신 상호작용에 계속 발생한다는 것입니다. LCP의 경우 소프트 탐색 로드의 페인트만 고려하고 후속 상호작용의 페인트는 고려하지 않습니다.
따라서 올바른 URL을 얻기 위해 interaction-contentful-paint 항목을 soft-navigation-entries에 매핑하려면 navigationId이 아닌 interactionId를 사용해야 합니다. 이렇게 하면 이전 navigationId가 있는 항목이 처리되고 LCP에 고려해서는 안 되는 interaction-contentful-paint 항목이 필터링됩니다.
또한 soft-navigation entries가 발생하기 전에 발생하는 interaction-contentful-paint 항목을 더 쉽게 처리할 수 있도록 soft-navigation 항목의 largestInteractionContentfulPaint 항목도 처리하는 것이 좋습니다.
소프트 탐색의 startTime 가져오기
소프트 탐색을 포함한 모든 성능 타이밍과 핵심 성능 보고서 측정항목을 계산하는 데 사용되는 항목은 초기 '하드' 페이지 탐색 시간으로부터의 시간으로 보고됩니다. 따라서 소프트 탐색 시작 시간을 소프트 탐색 로드 측정항목 시간 (예: LCP)에서 빼서 이 소프트 탐색 시간과 관련하여 보고해야 합니다.
적절한 soft-navigation 항목에 매핑하고 startTime을 사용하여 비슷한 방식으로 탐색 시작 시간을 가져올 수 있습니다.
startTime는 소프트 탐색을 시작한 초기 상호작용 (예: 버튼 클릭) 시간입니다. 이는 새 페이지가 브라우저에 '커밋'되고 일부 이벤트 핸들러 코드가 실행된 후 '시작 시간'이 발생하는 '하드 탐색'과는 약간 다릅니다. 상호작용 시작 시간부터 측정하므로 소프트 탐색 시작 시간에도 이벤트 핸들러 코드가 포함됩니다.
소프트 탐색별로 Core Web Vitals 측정
핵심 성능 보고서를 측정하려면 soft-navigation 항목을 수신 대기하고 이러한 항목을 수신하면 측정항목을 재설정하세요. FCP는 presentationTime에 기반하여 방출될 수 있고 LCP는 largestInteractionContentfulPaint로 초기화될 수 있습니다. INP, CLS는 페이지 로드 시와 마찬가지로 0으로 초기화해야 합니다.
그런 다음 LCP, INP, CLS를 평소와 같이 측정하고 모니터링할 수 있습니다 (interactionId이 일치하는 경우 LCP에 interaction-contentful-paint를 사용하는 것은 예외). interactionId 및 navigationId는 앞에서 설명한 대로 URL 항목의 이름을 지정하는 데 사용할 수 있습니다.
타이밍은 원래 '하드' 탐색 시작 시간을 기준으로 계속 반환됩니다. 따라서 예를 들어 소프트 탐색의 LCP를 계산하려면 interaction-contentful-paint 타이밍을 가져와 이전에 자세히 설명한 대로 적절한 소프트 탐색 시작 시간을 빼서 소프트 탐색과 관련된 타이밍을 구해야 합니다.
일부 측정항목은 페이지 수명 전반에 걸쳐 측정되어 왔습니다. 예를 들어 LCP는 상호작용이 발생할 때까지 변경될 수 있습니다. CLS와 INP는 상호작용과 관계없이 페이지에서 다른 페이지로 이동할 때까지 업데이트할 수 있습니다. 따라서 각 새 소프트 탐색이 발생하면 이전 탐색의 측정항목이 완료되어야 합니다. 즉, 소프트 탐색으로 코어 웹 바이탈을 측정할 때 초기 '하드' 탐색 측정항목이 평소보다 일찍 완료될 수 있습니다.
마찬가지로 이러한 장기 측정항목의 새로운 소프트 탐색에 대한 측정항목을 측정하기 시작할 때 측정항목을 '재설정'하거나 '다시 초기화'하고 이전 '페이지'에 설정된 값을 기억하지 않는 새 측정항목으로 취급해야 합니다. 즉, 처음부터 다시 측정할 수 있도록 '가장 큰' 페인트, 다음 페인트에 대한 상호작용 또는 레이아웃 변경에 대한 이해가 재설정됩니다.
탐색 간에 동일하게 유지되는 콘텐츠는 어떻게 처리해야 하나요?
소프트 탐색의 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를 측정해야 하나요?
이 실험 중에는 새 구현이 최종적으로 제공되기 전에 문제가 발생하거나 변경될 수 있으므로 '하드' 페이지 탐색을 기반으로 현재 방식으로 핵심 성능 보고서를 계속 측정하는 것이 좋습니다. 이는 현재 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';
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 라이브러리는 소프트 탐색에 대해 다음 측정항목을 보고합니다.
| 측정항목 | 세부정보 |
|---|---|
| TTFB | 0으로 보고됩니다. |
| FCP | 소프트 탐색을 트리거한 상호작용에서 소프트 탐색 시작 시간과 관련된 콘텐츠가 포함된 첫 페인트 시간입니다. 이전 탐색에 표시되거나 상호작용과 연결되지 않은 기존 페인트는 고려되지 않습니다. |
| LCP | 소프트 탐색을 트리거한 상호작용에서 소프트 탐색 시작 시간을 기준으로 한 최대 콘텐츠 렌더링 시간입니다. 이전 탐색에 표시되거나 상호작용과 연결되지 않은 기존 페인트는 고려되지 않습니다. 일반적으로 LCP는 상호작용 시 또는 페이지가 백그라운드로 전환될 때 보고됩니다. 그래야만 LCP가 완료될 수 있기 때문입니다. |
| CLS | 탐색 시간 사이의 가장 큰 교대 시간 창입니다. 일반적으로 페이지가 백그라운드로 전환될 때 발생합니다. 그래야 CLS가 최종적으로 결정될 수 있기 때문입니다. 교대 근무가 없으면 0 값이 보고됩니다. |
| INP | 탐색 시간 사이의 INP입니다. 일반적으로 INP는 상호작용 시 또는 페이지가 백그라운드로 전환될 때 보고됩니다. 그래야만 INP가 최종적으로 결정될 수 있기 때문입니다. 상호작용이 없으면 0 값이 보고되지 않습니다. |
이러한 변경사항이 Core Web Vitals 측정에 포함되나요?
Google은 핵심 성능 보고서 이니셔티브에 통합할지 여부를 결정하기 전에 휴리스틱을 평가하고 사용자 환경을 더 정확하게 반영하는지 확인하려고 합니다. 궁극적인 목표는 실제 사용자의 경험으로 실적을 더 잘 측정할 수 있는 수단을 제공하는 것입니다. 따라서 이 실험이 성공하면 모든 도구에서 노출되는 대로 이러한 측정항목을 핵심 성능 보고서 측정에 포함하는 것이 목표입니다.
실험, 사용된 휴리스틱, 경험을 더 정확하게 반영하는지 여부에 관한 웹 개발자의 의견을 소중하게 생각합니다. 소프트 탐색 GitHub 저장소에서 의견을 제공하는 것이 가장 좋지만 Chrome의 구현과 관련된 개별 버그는 Chrome 문제 추적기에 신고해야 합니다.
소프트 탐색은 CrUX에서 어떻게 보고되나요?
이 실험이 성공할 경우 CrUX에 소프트 탐색이 어떻게 보고될지도 아직 결정되지 않았습니다. 현재 '하드' 탐색과 동일하게 처리된다고 단정할 수는 없습니다.
일부 웹페이지에서 소프트 탐색은 사용자의 관점에서 전체 페이지 로드와 거의 동일하며 단일 페이지 애플리케이션 기술의 사용은 구현 세부정보일 뿐입니다. 다른 경우에는 추가 콘텐츠의 부분 로드와 더 유사할 수 있습니다.
따라서 Google에서는 CrUX에서 이러한 소프트 탐색을 별도로 보고하거나 특정 페이지 또는 페이지 그룹의 핵심 웹 바이탈을 계산할 때 가중치를 부여할 수 있습니다. 휴리스틱이 발전함에 따라 부분 로드 소프트 탐색을 완전히 제외할 수도 있습니다.
팀은 이 실험의 성공 여부를 판단할 수 있는 휴리스틱 및 기술적 구현에 집중하고 있으므로 이러한 측면에서 결정된 사항은 없습니다.
의견
다음 채널에서 이 실험에 관한 의견을 적극적으로 수집하고 있습니다.
- API에 관한 의견은 GitHub의 문제로 제출해야 합니다.
- Chromium 구현의 버그는 아직 알려진 문제가 아닌 경우 Chrome 문제 추적기에 신고해야 합니다.
- 일반적인 웹 바이탈 의견은 web-vitals-feedback@googlegroups.com으로 공유할 수 있습니다.
어디에 의견을 보내야 할지 잘 모르겠다면 너무 걱정하지 마세요. 어디에 의견을 보내시든 기꺼이 문제를 분류하고 올바른 위치로 리디렉션해 드리겠습니다.
변경 로그
이 API는 실험 단계에 있으므로 안정적인 API보다 더 많은 변경사항이 적용됩니다. 자세한 내용은 소프트 탐색 휴리스틱 변경 로그를 참고하세요.
결론
소프트 탐색 실험은 Core Web Vitals 이니셔티브가 측정항목에서 누락된 최신 웹의 일반적인 패턴을 측정하기 위해 어떻게 발전할 수 있는지 보여주는 흥미로운 접근 방식입니다. 이 실험은 아직 초기 단계이며 해야 할 일이 많지만, 지금까지의 진행 상황을 더 광범위한 웹 커뮤니티에서 실험할 수 있도록 제공하는 것은 중요한 단계입니다. 이번 실험에서 의견을 수집하는 것도 실험의 중요한 부분입니다. 따라서 이번 개발에 관심이 있는 분들은 이번 기회를 활용하여 API를 구체화해 주시기 바랍니다.
감사의 말씀
이 작업은 Yoav Weiss가 Google에 있을 때 처음 시작한 작업의 연속입니다. 이 API를 위해 노력해 주신 Yoav에게 감사드립니다.