코어 웹 바이탈 측정항목을 모니터링하는 도구에서 보고되는 수치가 서로 다른 이유와 이러한 차이를 해석하는 방법을 알아보세요.
Google은 사이트 소유자가 코어 웹 바이탈 점수를 모니터링하는 데 도움이 되는 여러 도구를 제공합니다. 이러한 도구는 크게 두 가지 카테고리로 나뉩니다.
- 실험실 데이터(사전 정의된 기기 및 네트워크 설정을 사용하는 통제된 환경에서 수집된 데이터)를 보고하는 도구
- 필드 데이터(사이트를 방문하는 실제 사용자로부터 수집된 데이터)를 보고하는 도구입니다.
문제는 실험실 도구에서 보고한 데이터가 현장 도구에서 보고되는 데이터와 다를 수 있다는 점입니다. 실험실 데이터에 따르면 사이트 성능이 우수하다고 할 수 있지만 필드 데이터를 보면 개선이 필요한 것으로 나타납니다. 또는 필드 데이터에 모든 페이지가 양호하다고 표시되지만 실험실 데이터의 점수가 매우 낮을 수 있습니다.
web.dev의 PageSpeed Insights 보고서를 보여주는 다음 실제 예를 보면, 경우에 따라 실험실 및 필드 데이터가 모든 코어 웹 바이탈 측정항목에서 다를 수 있습니다.
도구 간의 차이는 개발자에게 혼란을 줄 수 있습니다. 이 게시물에서는 이러한 차이가 발생할 수 있는 주요 이유(각 코어 웹 바이탈 측정항목을 설명하는 구체적인 예시와 함께)와 페이지에서 차이를 발견했을 때 취해야 할 조치를 설명합니다.
실험실 데이터와 필드 데이터 비교
실험실 및 현장 도구가 정확히 동일한 웹페이지에 대해서도 다른 값을 보고하는 이유를 이해하려면 실험실 데이터와 필드 데이터의 차이를 이해해야 합니다.
실험실 데이터
실험실 데이터는 사전 정의된 네트워크 및 기기 조건 집합으로 통제된 환경에서 웹페이지를 로드하여 결정됩니다. 이러한 조건을 실습 환경이라고 하며, 합성 환경이라고도 합니다.
실험실 데이터를 보고하는 Chrome 도구는 일반적으로 Lighthouse를 실행합니다.
실험실 테스트의 목적은 최대한 많은 요소를 제어하는 것이므로 실행마다 결과가 (최대한) 일관되고 재현 가능합니다.
필드 데이터
필드 데이터는 페이지를 방문하는 모든 사용자를 모니터링하고 각 사용자의 개별 환경에 대한 지정된 성능 측정항목 집합을 측정하여 결정됩니다. 필드 데이터는 실제 사용자 방문을 기반으로 하므로 실제 기기, 네트워크 상태, 사용자의 지리적 위치가 반영됩니다.
필드 데이터는 일반적으로 RUM(Real User Monitoring) 데이터라고도 하며, 두 용어는 서로 바꿔 사용할 수 있습니다.
필드 데이터를 보고하는 Chrome 도구는 일반적으로 Chrome 사용자 환경 보고서(CrUX)에서 이 데이터를 가져옵니다. 또한 CrUX만 사용할 때보다 더 활용 가능한 분석 정보를 제공할 수 있으므로 사이트 소유자가 필드 데이터를 직접 수집하는 것이 일반적이고 권장됩니다.
필드 데이터에 대해 이해해야 할 가장 중요한 점은 필드 데이터가 하나의 숫자가 아니라 숫자의 분포라는 점입니다. 즉, 사이트를 방문하는 사용자 중에는 빠르게 로드되는 경우도 있고 매우 느리게 로드되는 경우도 있습니다. 사이트의 필드 데이터는 사용자로부터 수집된 모든 성능 데이터의 전체 집합입니다.
예를 들어 CrUX 보고서에는 28일 동안 실제 Chrome 사용자의 성능 측정항목 분포가 표시됩니다. 거의 모든 CrUX 보고서를 살펴보면 사이트를 방문하는 일부 사용자는 매우 좋은 경험을 하는 반면 다른 사용자는 매우 불만족스러워할 수 있음을 알 수 있습니다.
도구에서 특정 측정항목에 대해 단일 숫자를 보고하는 경우 일반적으로 분포의 특정 지점을 나타냅니다. 코어 웹 바이탈 필드 점수를 보고하는 도구는 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번째 백분위수를 정확하게 나타내거나 나타내지 않을 수 있습니다.
랩의 통제된 환경은 프로덕션에 배포하기 전에 문제를 디버깅하거나 기능을 테스트할 때 유용하지만 이러한 요소를 제어할 때 모든 유형의 네트워크, 기기 기능 또는 지리적 위치에서 실제로 볼 수 있는 변동을 명시적으로 나타내지 않습니다. 또한 스크롤, 텍스트 선택, 페이지의 요소 탭하기와 같은 실제 사용자 동작이 성능에 미치는 영향도 일반적으로 포착하지 않습니다.
실습 조건과 대부분의 실제 사용자의 조건 간에 차이가 있을 수 있습니다. 그 외에도 실습 및 필드 데이터를 최대한 활용하려면 다양한 미묘한 차이와 차이점을 이해해야 합니다.
다음 섹션에서는 각 코어 웹 바이탈 측정항목의 실험실 데이터와 필드 데이터 간에 차이가 있을 수 있는 가장 일반적인 이유를 자세히 설명합니다.
LCP
다양한 LCP 요소
실험실 테스트에서 식별된 LCP 요소는 사용자가 페이지를 방문할 때 표시되는 LCP 요소와 다를 수 있습니다.
특정 페이지에 대해 Lighthouse 보고서를 실행하면 매번 동일한 LCP 요소가 반환됩니다. 하지만 동일한 페이지의 필드 데이터를 살펴보면 일반적으로 각 페이지 방문의 여러 상황에 따라 달라지는 다양한 LCP 요소를 확인할 수 있습니다.
예를 들어 다음 요인은 모두 동일한 페이지에서 다른 LCP 요소가 결정되는 데 영향을 미칠 수 있습니다.
- 기기 화면 크기가 다르면 표시 영역 내에 다른 요소가 표시됩니다.
- 사용자가 로그인하거나 맞춤설정된 콘텐츠가 어떤 식으로든 표시되는 경우 LCP 요소는 사용자마다 매우 다를 수 있습니다.
- 이전 항목과 마찬가지로 페이지에서 A/B 테스트가 실행 중인 경우 매우 다른 요소가 표시될 수 있습니다.
- 사용자 시스템에 설치된 글꼴 모음은 페이지의 텍스트 크기에 영향을 미칠 수 있습니다 (그리고 어떤 요소가 LCP 요소인지).
- 실험실 테스트는 일반적으로 쿼리 매개변수나 해시 프래그먼트를 추가하지 않고 페이지의 '기본' URL에서 실행됩니다. 하지만 실제로는 사용자가 프래그먼트 식별자 또는 텍스트 프래그먼트가 포함된 URL을 공유하는 경우가 많으므로 LCP 요소는 실제로 '스크롤 없이 볼 수 있는 부분'이 아닌 페이지의 중간 또는 하단에 있을 수 있습니다.
필드의 LCP는 모든 사용자 페이지 방문 중 75번째 백분위수로 계산되므로, 이러한 사용자 중 상당수가 매우 빠르게 로드되는 LCP 요소(예: 시스템 글꼴로 렌더링된 텍스트 단락)가 있는 경우, 일부 사용자에게 LCP 요소로 크고 느린 로딩 이미지가 표시되더라도 페이지 점수가 2% 미만에 해당하더라도 페이지 점수에 영향을 미치지 않을 수 있습니다.
또는 그 반대의 경우도 있습니다. 실험실 테스트에서는 텍스트 블록을 LCP 요소로 식별할 수 있습니다. 표시 영역이 비교적 작고 페이지의 히어로 이미지가 처음에는 화면 밖으로 렌더링되는 Moto G4 휴대전화를 에뮬레이션하기 때문입니다. 하지만 필드 데이터에는 대형 화면의 Pixel XL 사용자가 대부분 포함될 수 있으므로 이 사용자에게는 느리게 로드되는 히어로 이미지가 LCP 요소입니다.
캐시 상태가 LCP에 미치는 영향
실험실 테스트에서는 일반적으로 콜드 캐시가 포함된 페이지를 로드하지만, 실제 사용자가 해당 페이지를 방문할 때 이미 리소스 중 일부가 캐시되었을 수 있습니다.
사용자가 페이지를 처음 로드할 때는 페이지가 느리게 로드될 수 있지만, 페이지에 적절한 캐싱이 구성되어 있다면 사용자가 다음에 다시 돌아올 때 페이지가 바로 로드될 수 있습니다.
일부 실습 도구는 (재방문자의 환경을 시뮬레이션하기 위해) 동일한 페이지의 여러 실행을 지원하지만, 실험실 도구는 신규 사용자와 재방문 사용자의 실제 방문 비율을 알 수 없습니다.
캐시 구성이 잘 최적화되어 있고 재방문자가 많은 사이트에서 실제 LCP가 실험실 데이터에 표시된 것보다 훨씬 빠를 수 있습니다.
AMP 또는 Signed Exchange 최적화
AMP로 빌드되었거나 서명된 교환(SXG)을 사용하는 사이트는 Google 검색과 같은 콘텐츠 애그리게이터가 미리 로드할 수 있습니다. 이렇게 하면 해당 플랫폼에서 페이지를 방문하는 사용자의 로드 성능이 크게 향상됩니다.
교차 출처 미리 로드 외에도 사이트 자체에서 사이트의 후속 페이지의 콘텐츠를 미리 로드하여 해당 페이지의 LCP도 개선할 수 있습니다.
실험실 도구는 이러한 최적화를 통해 얻는 이점을 시뮬레이션하지 않으며, 시뮬레이션하더라도 다른 소스에 비해 Google 검색과 같은 플랫폼에서 발생하는 트래픽의 비율을 알 수 없습니다.
bfcache에 LCP의 영향
페이지가 bfcache에서 복원되면 로드 환경이 거의 즉각적으로 이루어지며 이러한 환경은 필드 데이터에 포함됩니다.
실험실 테스트에서는 bfcache를 고려하지 않으므로 페이지가 bfcache에 적합하다면 필드에 보고되는 LCP 점수가 더 빨라질 수 있습니다.
사용자 상호작용이 LCP에 미치는 영향
LCP는 표시 영역에서 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간을 식별하지만 이 가장 큰 요소는 페이지가 로드되거나 새 콘텐츠가 표시 영역에 동적으로 추가될 때 변경될 수 있습니다.
실습에서 브라우저는 페이지가 완전히 로드될 때까지 기다렸다가 LCP 요소가 무엇인지 판단합니다. 하지만 현장에서는 사용자가 페이지를 스크롤하거나 페이지와 상호작용하면 브라우저가 더 큰 요소에 대한 모니터링을 중지합니다.
이는 일반적으로 LCP 측정항목에서 감지하려는 목표인 페이지가 로드되어 '표시'될 때까지 사용자가 페이지와 상호작용하기를 기다리므로 합리적이며 필요합니다. 또한 사용자 상호작용 후에 표시 영역에 추가된 요소를 고려하는 것도 적합하지 않습니다. 이러한 요소는 사용자의 작업 때문으로만 로드되었을 수 있기 때문입니다.
하지만 페이지의 필드 데이터가 페이지에서의 사용자 행동 방식에 따라 더 빠른 LCP 시간을 보고할 수 있다는 의미입니다.
FID
FID에는 실제 사용자 상호작용이 필요합니다.
FID 측정항목은 사용자가 실제로 상호작용하기로 선택한 시점의 사용자 상호작용에 대한 페이지의 반응성을 측정합니다.
이 문장의 두 번째 부분은 매우 중요합니다. 스크립트 사용자 동작을 지원하는 실험실 테스트도 사용자가 페이지와 상호작용할 시점을 정확하게 예측할 수 없으므로 FID를 정확하게 측정할 수 없기 때문입니다.
TBT는 사용자 행동을 고려하지 않음
총 차단 시간 (TBT) 실습 측정항목은 페이지 로드 중에 기본 스레드가 차단된 정도를 수치화하므로 FID 문제를 진단하는 데 도움이 됩니다.
동기 자바스크립트 또는 기타 집약적인 렌더링 작업이 많은 페이지에서는 사용자가 처음 상호작용할 때 기본 스레드가 차단될 가능성이 높습니다. 그러나 사용자가 JavaScript 실행이 완료될 때까지 페이지와 상호작용하기를 기다리면 FID가 매우 낮을 수 있습니다.
사용자가 페이지와 상호작용하도록 선택하는 시점은 페이지가 대화형으로 보이는지 여부에 따라 크게 달라지며, TBT로는 측정할 수 없습니다.
TBT는 탭 지연을 고려하지 않음
사이트가 모바일 보기에 최적화되지 않은 경우 브라우저에서 이벤트 핸들러를 실행하기 전에 탭한 후 300ms의 지연을 추가합니다. 마우스나 클릭 이벤트를 실행하기 전에 사용자가 두 번 탭하여 확대/축소하려고 하는지 확인해야 하기 때문입니다.
이러한 지연은 사용자가 경험하는 실제 입력 지연 시간에 영향을 미치므로 페이지의 FID에 반영됩니다. 하지만 이 지연은 기술적으로 장기 작업이 아니므로 페이지의 TBT에 영향을 미치지 않습니다. 즉, TBT 점수는 매우 높지만 페이지의 FID가 낮을 수 있습니다.
캐시 상태 및 bfcache가 FID에 미치는 영향
적절한 캐싱이 필드의 LCP를 개선하는 것처럼 FID도 개선할 수 있습니다.
실제로는 사용자의 캐시에 사이트의 JavaScript가 이미 있을 수 있으므로 처리하는 데 시간이 덜 걸릴 수 있고 결과적으로 지연도 줄어듭니다.
bfcache에서 복원된 페이지의 경우에도 마찬가지입니다. 이러한 경우 자바스크립트가 메모리에서 복원되므로 처리 시간이 거의 없거나 전혀 없을 수 있습니다.
CLS
사용자 상호작용이 CLS에 미치는 영향
실습에서 측정된 CLS는 스크롤 없이 볼 수 있는 부분과 로드 중에 발생하는 레이아웃 변경만 고려하지만 이는 CLS가 실제로 측정하는 것의 하위 집합일 뿐입니다.
이 필드에서 CLS는 페이지의 수명 기간에 발생하는 모든 예상치 못한 레이아웃 변경을 고려합니다. 여기에는 사용자가 스크롤할 때 또는 사용자 상호작용 후 느린 네트워크 요청에 대한 응답으로 이동하는 콘텐츠가 포함됩니다.
예를 들어 페이지에서 크기가 없는 이미지나 iframe을 지연 로드하는 것이 일반적이며 이로 인해 사용자가 페이지의 해당 섹션으로 스크롤할 때 레이아웃이 변경될 수 있습니다. 그러나 이러한 이동은 사용자가 아래로 스크롤해야만 발생할 수 있으며, 이는 보통 실험실 테스트에서 포착되지 않습니다.
맞춤 콘텐츠
개인 맞춤 콘텐츠(타겟팅 광고 및 A/B 테스트 포함)는 페이지에 로드되는 요소에 영향을 미칩니다. 또한 맞춤설정된 콘텐츠는 나중에 로드되어 페이지의 기본 콘텐츠에 삽입되어 레이아웃이 변경되기 때문에 로드 방식에도 영향을 미칩니다.
실험실에서는 일반적으로 페이지가 맞춤설정된 콘텐츠 없이 로드되거나 일반 '테스트 사용자'를 위한 콘텐츠와 함께 로드되므로 실제 사용자에게 표시되는 변화를 트리거할 수도 있고 트리거하지 않을 수도 있습니다.
필드 데이터에는 모든 사용자의 환경이 포함되므로 페이지에서 발생하는 레이아웃 변경의 양과 정도는 로드되는 콘텐츠에 따라 크게 달라집니다.
캐시 상태 및 bfcache가 CLS에 미치는 영향
로드 중에 레이아웃이 변경되는 가장 일반적인 두 가지 원인은 크기가 없는 이미지와 iframe (위에서 언급한 대로) 및 느린 웹 글꼴 로드입니다. 이 두 가지 문제 모두 사용자가 사이트를 처음 방문할 때 캐시가 비어 있는 환경에 영향을 미칠 가능성이 더 큽니다.
페이지 리소스가 캐시되거나 페이지 자체가 bfcache에서 복원되는 경우 브라우저는 일반적으로 이미지와 글꼴을 다운로드할 때까지 기다리지 않고 즉시 렌더링할 수 있습니다. 이로 인해 필드의 CLS 값이 실습 도구에서 보고하는 값보다 낮을 수 있습니다.
결과가 다를 경우 취해야 할 조치
일반적으로 특정 페이지에 필드 데이터와 실험실 데이터가 모두 있는 경우 작업 우선순위를 지정하는 데 필드 데이터를 사용해야 합니다. 필드 데이터는 실제 사용자가 경험하는 것을 나타내므로 사용자가 겪는 어려움과 개선이 필요한 부분을 가장 정확하게 파악할 수 있습니다.
반면에 필드 데이터에서 전반적인 점수가 높지만 실험실 데이터에 따르면 아직 개선의 여지가 있는 것으로 나타난다면 어떤 추가 최적화를 할 수 있는지 이해하는 것이 좋습니다.
또한 필드 데이터는 실제 사용자 환경을 캡처하지만 사이트를 성공적으로 로드할 수 있는 사용자에게만 해당합니다. 실험실 데이터는 때때로 사이트의 도달범위를 확장하고 네트워크 속도가 느린 네트워크나 저사양 기기를 사용하는 사용자가 더 쉽게 사이트에 액세스할 수 있도록 하는 데 도움이 될 수 있습니다.
전반적으로 실험실 데이터와 필드 데이터는 모두 효과적인 성능 측정의 중요한 부분입니다. 두 가지 모두 장단점이 있으며, 하나만 사용하면 사용자 환경을 개선할 기회를 놓칠 수 있습니다.