Core Web Vitals 측정항목을 모니터링하는 도구가 다른 수치를 보고하는 이유와 이러한 차이를 해석하는 방법을 알아보세요.
Google은 사이트 소유자가 정책을 모니터링하는 데 도움이 되는 여러 도구를 제공합니다. 코어 웹 바이탈 점수를 확인할 수 있습니다 이러한 도구는 두 가지 주요 카테고리:
- 실험실 데이터를 보고하는 도구: 제어된 환경에서 수집된 데이터 및 사전 정의된 기기 및 네트워크 설정을 사용할 수 있습니다.
- 필드 데이터를 보고하는 도구: 확인할 수 있습니다.
문제는 실험실 도구에서 보고하는 데이터가 상당히 상당히 많을 수 있다는 점입니다. 현장 도구로 보고되는 데이터와는 다를 수 있습니다! 실험실 데이터에 다음과 같은 문제가 있을 수 있습니다. 확인하려고 하지만 현장 데이터에 따르면 개선할 수 있습니다 또는 필드 데이터에 모든 페이지가 정상이라고 표시될 수 있지만 실험실 데이터가 매우 낮은 점수를 보고할 수 있습니다.
web.dev에서 제공하는 PageSpeed Insights 보고서의 실제 예는 다음과 같습니다. 경우에 따라 실험실 및 현장 데이터가 모든 핵심 구성 요소에서 다를 수 있습니다. 웹 바이탈 측정항목:
도구 간의 차이점에 대해 혼란을 야기하는 이해할 수 있는 원인 있습니다. 이 게시물에서는 이러한 차이가 발생할 수 있는 주된 이유를 설명합니다. 각 Core Web Vitals 측정항목을 다루는 구체적인 예시가 마련되어 있으며 해야 할 일에 대해 알아보겠습니다.
실험실 데이터와 현장 데이터 비교
왜 실험실과 필드 도구가 서로 다른 값을 보고하는지 이해하기 위해 정확히 동일한 웹 페이지(실습과 현장의 차이점을 이해해야 함) 데이터를 수집하는 데 사용됩니다
실험실 데이터
실험실 데이터는 제어된 환경에서 웹페이지를 로드하여 사전 정의된 네트워크 및 기기 조건 세트입니다. 이러한 조건을 실습 환경을 생성하는 데 사용됩니다. 합성 환경이라고도 합니다.
실험실 데이터를 보고하는 Chrome 도구가 일반적으로 실행 중임 Lighthouse.
실험실 테스트의 목적은 최대한 많은 요소를 제어하는 것이므로 결과는 (최대한 일관되고) 실행마다 재현 가능합니다.
필드 데이터
필드 데이터는 페이지를 방문하는 모든 사용자를 모니터링하고 실적 측정항목을 바탕으로 개인 있습니다. 필드 데이터는 실제 사용자 방문을 기반으로 하기 때문에 사용자의 실제 기기, 네트워크 상태 및 지리적 위치에 대한 정보를 수집할 수 있습니다.
일반적으로 필드 데이터는 실제 사용자 모니터링이라고도 합니다. (RUM) 데이터 두 개의 항 서로 바꿔서 사용할 수 있습니다.
필드 데이터를 보고하는 Chrome 도구는 일반적으로 Chrome 사용자 환경 보고서 (CrUX) 또한 사이트 소유자가 필드 데이터를 수집하는 것이 일반적이며 권장됩니다. 왜냐하면 자체적으로 CrUX만 사용할 때보다 활용 가능한 분석 정보를 더 많이 얻을 수 있습니다.
필드 데이터에 대해 이해해야 할 가장 중요한 것은 숫자의 분포입니다. 즉, 웹사이트를 방문하는 일부 사람들은 매우 빠르게 로드되는 반면 어떤 경우에는 매우 느리게 로드될 수 있습니다. 사이트의 필드 데이터에는 모든 실적 데이터가 포함됩니다. 확인할 수 있습니다
일례로 CrUX 보고서는 실제 사용자 경험과 28일 동안의 Chrome 사용자 거의 모든 CrUX 보고서를 보면 사이트를 방문하는 일부 사용자가 매우 우수한 경험을 하는 것을 다른 사람들은 매우 좋지 않은 경험을 할 수 있습니다.
도구에서 특정 측정항목에 대해 단일 숫자를 보고하는 경우 일반적으로 분포의 특정 지점을 나타냅니다. Core Web을 보고하는 도구 Vitals 필드 점수는 75번째 백분위수
위 스크린샷에 있는 필드 데이터의 LCP를 보면 배포:
- 방문의 88% 에서 LCP가 2.5초 이하입니다 (양호).
- 방문의 8% 가 2.5~4초 사이에 LCP를 경험했습니다 (개선 필요).
- 전체 방문의 4% 에서 LCP가 4초 넘게 지속되었습니다 (나쁨).
75번째 백분위수에서 LCP는 1.8초였습니다.
같은 페이지의 실험실 데이터에는 LCP 값이 3.0초로 표시됩니다. 이 값은 필드 데이터에 표시된 1.8초보다 길더라도 여전히 유효한 LCP입니다. 전체 분포를 구성하는 여러 값 중 하나이므로 여러 기능을 제공합니다
실험실 데이터와 필드 데이터가 다른 이유
위 섹션에서 설명했듯이, 실험실 데이터와 현장 데이터는 실제로 할 수 있습니다.
현장 데이터에는 다양한 네트워크 및 장치 상태뿐만 아니라 사용자 행동을 확인할 수 있습니다. 여기에는 다른 요인도 포함됩니다. 브라우저 최적화처럼 사용자 환경에 영향을 주는 뒤로-앞으로 캐시 (bfcache) 또는 AMP 캐시.
이와 대조적으로 실험실 데이터는 관련된 변수의 수를 의도적으로 제한합니다. 가 실험실 테스트는 다음으로 구성됩니다.
- 단일 기기
- 단일 네트워크에 연결됨...
- 광고를 게재할 수 있습니다.
실험실 테스트의 세부사항은 특정 페이지 또는 사이트에 대한 필드 데이터의 75번째 백분위수입니다.
실험실의 통제된 환경은 문제를 디버깅하거나 테스트할 때 유용합니다. 이러한 요소를 제어할 때는 실제로 존재하는 편차를 명시적으로 나타내지 않습니다. 지리적 위치에 관계없이 광고를 게재할 수 있습니다. 나 또한 일반적으로 실제 사용자 행동이 성능에 미치는 영향을 포착하지 못하고 있습니다. 페이지에서 스크롤, 텍스트 선택 또는 요소 탭하기
실습 조건과 조건 간의 연결 해제 외에도 '다수의 실제 사용자'와 같지만 몇 가지 미묘한 차이가 몇 가지 사항을 살펴봤습니다 발생할 수 있는 차이점을 설명할 수 있습니다.
다음 몇 개 섹션에서는 콘텐츠 게시 중단의 가장 일반적인 원인을 자세히 살펴보겠습니다. 각 Core Web의 실험실 데이터와 현장 데이터 간에 차이가 있을 수 있습니다. vitals 측정항목:
LCP
다양한 LCP 요소
실험실 테스트에서 식별된 LCP 요소는 LCP와 동일하지 않을 수 있음 사용자가 페이지를 방문할 때 보게 되는 요소입니다.
특정 페이지에 대해 Lighthouse 보고서를 실행하면 LCP 요소를 업데이트합니다. 그러나 같은 페이지의 필드 데이터를 보면 일반적으로 출력 장치에 따라 달라지는 다양한 LCP 요소를 상황별로 파악할 수 있습니다.
예를 들어 다음 요소가 모두 다른 LCP에 영향을 미칠 수 있습니다. 다음과 같은 요소가 결정됩니다.
- 기기 화면 크기가 다르면 다른 요소가 표시됨 표시 영역 내에서만 볼 수 있습니다.
- 사용자가 로그인했거나 일부 채널에서 맞춤 콘텐츠가 표시되는 경우 LCP 요소는 사용자마다 매우 다를 수 있습니다.
- 이전 요점과 마찬가지로 페이지에서 A/B 테스트를 실행하면 매우 다른 요소가 표시됩니다.
- 사용자의 시스템에 설치된 글꼴 모음이 글꼴의 크기에 영향을 페이지 (따라서 어떤 요소가 LCP 요소인지)
- 실험실 테스트는 일반적으로 페이지의 '기반'에서 실행됩니다. URL - 검색어 매개변수 없음 해시 조각이 추가되었습니다. 하지만 실제로는 사용자들이 URL을 공유하는 경우가 많습니다. 프래그먼트 식별자 또는 텍스트 조각이 되므로 LCP 요소는 '상단 또는 하단'으로 이동하는 것이 아니라 '접기').
필드의 LCP는 전체 사용자 방문의 75번째 백분위수로 계산되므로 사용자 중 상당수가 페이지에 로드된 LCP 요소를 가진 경우 매우 빠르게(예: 시스템 글꼴로 렌더링된 텍스트 단락) 이러한 사용자 중 일부가 크고 느리게 로드되는 이미지를 LCP로 사용하더라도 요소가 25% 미만이면 해당 페이지의 점수에 있습니다.
또는 그 반대일 수도 있습니다. 실험실 테스트는 문자를 LCP 요소로 사용하는 것이 좋습니다. 페이지의 히어로 이미지가 초기에 렌더링되는 경우 표시됩니다. 하지만 현장 데이터에는 따라서 느리게 로드되는 히어로 이미지는 LCP 요소입니다.
캐시 상태가 LCP에 미치는 영향
실험실 테스트는 일반적으로 콜드 캐시로 페이지를 로드하지만 해당 페이지의 리소스 중 일부가 이미 캐시되어 있을 수 있습니다.
사용자가 페이지를 처음 로드할 때는 느리게 로드될 수 있지만 적절한 캐싱이 구성된 경우 다음번에 사용자가 바로 로드되기 때문입니다.
일부 실습 도구는 동일한 페이지를 여러 번 실행하는 것을 지원하지만 실험 도구에서는 URL이 실제로 어떻게 작동하는지를 알 수는 없습니다. 재방문자 대비 신규 사용자의 실제 방문 비중
캐시 구성이 잘 최적화되어 있고 재방문자가 많은 사이트는 실제 LCP가 실험실 데이터에서 나타난 것보다 훨씬 빠르다는 것을 발견했습니다.
AMP 또는 Signed Exchange 최적화
AMP로 구축되었거나 서명된 교환을 사용하는 사이트 (SXG)는 Google Cloud와 같은 콘텐츠 애그리게이터가 미리 로드할 수 있음 검색 이렇게 하면 사용자의 로드 성능이 크게 향상됩니다. 페이지를 방문하는 경우가 여기에 해당합니다.
교차 출처 미리 로드 외에도 사이트 자체에서 콘텐츠를 미리 로드하기만 하면 해당 페이지의 LCP도 개선할 수 있습니다
실험실 도구는 이러한 최적화로 얻는 이익을 시뮬레이션하지 않으며, 트래픽이 차지하는 비율을 알 수 없는 경우에는 다른 소스 대비 Google 검색과 같은 플랫폼과 비교하여
bfcache가 LCP에 미치는 영향
페이지가 bfcache에서 복원되면 로드 환경이 거의 일어남 이러한 경험이 여러분의 분야에 포함됩니다. 데이터)를 참조하세요.
실험실 테스트에서는 bfcache로 인한 차이가 없으므로 페이지가 bfcache-친근한 경우 필드에 보고되는 LCP 점수가 더 빨라집니다.
사용자 상호작용이 LCP에 미치는 영향
LCP는 이벤트 영역에서 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간을 하지만 페이지가 로드되거나 표시 영역에 동적으로 추가됩니다.
이 실습에서는 브라우저가 페이지가 완전히 로드될 때까지 기다린 후에 LCP 요소가 무엇인지 결정합니다. 하지만 필드에서 브라우저가 멈춥니다. 더 큰 요소를 위한 모니터링 사용자가 페이지를 스크롤하거나 페이지와 상호작용한 후
이는 일반적으로 사용자가 회의의 결과를 기다리고 있기 때문에 페이지가 '표시'될 때까지 페이지와 상호작용할 때 이는 LCP와 정확히 일치하는 측정항목의 감지가 목표입니다 또한 피처스토어에 추가된 요소를 사용자가 상호작용한 후에 표시 영역이 닫히지 않도록 해야 사용자가 한 행동 때문에 로드된 경우가 있습니다.
하지만 이렇게 하면 페이지의 필드 데이터가 LCP 시간(해당 페이지에서 사용자의 행동에 따라 다름)
INP
INP에는 실제 사용자 상호작용이 필요합니다.
INP 측정항목은 사용자 상호작용에 페이지가 얼마나 반응하는지, 사용자가 광고와 상호작용하기로 선택했을 때입니다
문장의 두 번째 부분은 매우 중요한데, 왜냐하면 실험실 테스트, 심지어 스크립트 사용자 동작을 지원하고 사용자가 언제 선택할지 정확하게 예측할 수 없음 페이지와 상호작용할 수 없으므로 FID를 정확하게 측정할 수 없습니다.
TBT는 사용자 행동을 고려하지 않음
총 차단 시간 (TBT) 실습 측정항목은 페이지 로드 중에 기본 스레드가 얼마나 차단되는지 정량화하므로 INP 관련 문제를 진단하는 데 도움이 됩니다.
동기 JavaScript나 다른 집약적 JavaScript가 많은 페이지는 사용자가 기본 스레드를 호출할 때 첫 번째 상호작용입니다 하지만 사용자가 INP가 매우 낮을 수 있습니다.
사용자가 페이지와 상호작용하기로 선택하는 시점은 대체로 상호작용처럼 보이므로 TBT로 측정할 수 없습니다.
TBT는 탭 지연을 고려하지 않음
사이트가 모바일 보기에 최적화되지 않은 경우에는 브라우저에 300ms 지연 이벤트 핸들러를 실행하기 전에 탭 후 이벤트 핸들러를 실행할 수 있습니다. 이렇게 하는 이유는 확대/축소하기 위해 사용자가 두 번 탭하여 실행하려고 하는지 확인 정의할 수 있습니다.
이러한 지연은 실제 입력에 기여하므로 페이지의 INP에 반영됩니다. 지연 시간을 최소화합니다 그러나 이 지연은 기술적으로 Long 태스크의 경우 페이지의 TBT에는 영향을 미치지 않습니다. 즉, TBT 점수가 매우 높아도 페이지의 INP가 낮을 수 있습니다.
캐시 상태와 bfcache가 INP에 미치는 영향
적절한 캐싱이 현장에서 LCP를 개선할 수 있는 것처럼 INP를 개선합니다.
실생활에서는 사이트의 자바스크립트가 캐시하므로 처리하는 데 필요한 지연 시간이 줄어듭니다
bfcache에서 복원된 페이지의 경우에도 마찬가지입니다. 이 경우 JavaScript가 메모리에서 복원되므로 처리가 거의 또는 전혀 없을 수 있음 시간이 전혀 걸리지 않습니다.
CLS
사용자 상호작용이 CLS에 미치는 영향
실습에서 측정되는 CLS는 위에서 발생하는 레이아웃 변경만 고려합니다. 하지만 이것은 실제로 CLS가 하는 것의 하위 집합일 뿐입니다. 대책을 세울 수 있습니다
필드에서 CLS는 예상치 못한 레이아웃을 모두 고려함 발생하는 모든 변화를 페이지의 수명(사용자가 스크롤하거나 사용자 상호작용 후 느린 네트워크 요청에 대한 응답입니다.
예를 들어 페이지에서 지연 로드(지연 로드)를 사용하지 않고 이미지나 iframe을 이로 인해 레이아웃이 사용자가 페이지의 해당 섹션으로 스크롤하면 바뀌는 것을 볼 수 있습니다. 그러나 이러한 변화는 사용자가 아래로 스크롤해야만 발생하며 이는 보통 실험실 테스트에서 발견되지 않습니다.
맞춤 콘텐츠
타겟팅 광고, A/B 테스트 등의 개인 맞춤 콘텐츠는 페이지에 로드됩니다. 또한 맞춤설정이 적용되어 로드 방식에도 영향을 줍니다. 나중에 로드되어 페이지의 주요 콘텐츠에 삽입되는 경우가 많아 있습니다.
실험실에서는 일반적으로 페이지가 맞춤설정된 콘텐츠 없이 로드되거나 교대 근무 전환을 트리거할 수도 있고 트리거하지 않을 수도 있는 일반적인 '테스트 사용자'를 위한 콘텐츠 확인할 수 있습니다.
필드 데이터에는 모든 사용자의 경험이 포함되므로 필드 데이터의 양과 정도는 페이지의 레이아웃 변경 중 발생하는 비율은 확인할 수 있습니다
캐시 상태와 bfcache가 CLS에 미치는 영향
로드 중에 레이아웃이 변경되는 가장 일반적인 두 가지 원인은 이미지와 위에 언급된 대로 크기가 없는 iframe 및 웹 로드 속도가 느림 이 두 가지 문제 모두 사용자가 사이트를 처음 방문할 때 캐시가 삭제되거나 비어 있습니다.
페이지의 리소스가 캐시되거나 페이지 자체가 bfcache로 인해 브라우저는 일반적으로 대기 중이었습니다. 이로 인해 필드의 CLS 값이 낮아질 수 있습니다. 더 많을 수 있습니다
결과가 다를 때 해결 방법
일반적으로 특정 페이지에 대한 필드 데이터와 실험실 데이터가 모두 있는 경우 필드 데이터는 작업의 우선순위를 지정하기 위해 사용해야 합니다. 이후 필드 데이터 이를 통해 실제 사용자가 경험하고 있는 상황을 반영할 수 있습니다. 사용자가 무엇을 어려워하는지, 무엇을 개선해야 하는지 확인할 수 있습니다
반면에 필드 데이터가 전반적으로 좋은 점수를 나타내지만 실험실 데이터에 따르면 여전히 개선의 여지가 있으므로 어떤 추가 최적화를 할 수 있는지 이해하는 데 도움이 됩니다.
또한 현장 데이터는 실제 사용자 경험을 캡처하지만 실제 사용자 경험을 성공적으로 사이트를 로드할 수 있는 사용자를 대상으로 합니다. 실험실 데이터는 때로는 사이트의 도달범위를 넓힐 수 있는 기회를 파악하고 속도가 느린 네트워크나 저사양 기기를 사용하는 사용자가 더 쉽게 액세스할 수 있습니다.
전반적으로 실험실 데이터와 현장 데이터는 모두 효과적인 테스트 진행을 위해 중요한 부분입니다. 실적 측정입니다. 둘 다 각자의 강점과 한계가 있으며, 둘 중 하나만 사용하고 있으므로 검색 캠페인을 개선할 기회를 개선할 수 있습니다