실적 모니터링

성능을 우선순위로 설정하는 것은 사용자뿐만 아니라 비즈니스에도 도움이 될 수 있습니다. 이 컬렉션의 권장사항은 주로 Google 게시자 태그 (GPT) 통합을 최적화하는 데 중점을 두지만 다른 여러 요소가 특정 페이지의 전반적인 성능에 기여합니다. 변경사항을 적용할 때마다 이러한 변경사항이 사이트 성능의 모든 측면에서 미치는 영향을 평가하는 것이 중요합니다.

페이지 성능 측정

변경사항이 사이트 성능에 미치는 영향을 이해하려면 먼저 비교할 기준을 설정해야 합니다. 이를 위한 가장 좋은 방법은 사이트가 현재 충족되거나 충족되지 않을 수 있는 아이디어 기준을 정의하는 성능 예산을 만드는 것입니다. 하지만 일정 수준의 성능을 유지하는 데 관심이 있다면 사이트의 현재 성능 측정항목을 기준으로 사용할 수 있습니다.

성능 측정을 시작하려면 다음 방법을 함께 사용하는 것이 좋습니다.

  • 합성 모니터링
    Lighthouse, Lighthouse 게시자 광고 감사와 같은 도구를 사용하여 실습 설정에서 페이지 성능을 측정할 수 있습니다. 이 유형의 측정에는 최종 사용자 상호작용이 필요하지 않으므로 자동화된 테스트에 사용하기에 적합하며 사용자에게 변경사항을 적용하기 전에 변경사항의 성능을 검증하는 데 사용할 수 있습니다.
  • 실제 사용자 모니터링 (RUM)
    Google 애널리틱스PageSpeed Insights와 같은 도구를 사용하여 실제 성능 데이터를 사용자로부터 직접 수집할 수 있습니다. 이 유형의 측정은 최종 사용자 상호작용을 기반으로 하므로 합성 테스트로는 쉽게 발견하기 어려운 라스트 마일 성능 문제를 식별하는 데 유용합니다.

주기적으로 측정하고 기준치와 정기적으로 비교하세요. 이렇게 하면 시간이 지남에 따라 사이트의 실적이 올바른 방향으로 추세를 보이고 있는지 알 수 있습니다.

측정할 항목 선택하기

성능 측면에서 사이트 실적에 대해 알아야 할 모든 것을 알려주는 단일 측정항목은 없습니다. 종합적으로 이해하려면 페이지 성능의 다양한 측면을 다루는 다양한 측정항목을 살펴봐야 합니다. 주요 성능 영역 및 추천 측정항목은 아래 표에 나열되어 있습니다.

성능 영역
인지 로드 속도 측정값

페이지가 모든 UI 요소를 로드하고 렌더링하는 속도.


추천 측정항목

콘텐츠가 포함된 첫 페인트 (FCP)
콘텐츠가 포함된 최대 페인트 (LCP)
첫 번째 광고를 렌더링하는 시간

페이지 로드 응답 속도 측정값

초기 로드 후 페이지가 반응하는 속도를 나타냅니다.


추천 측정항목

최초 입력 반응 시간 (FID)
상호작용 시간 (TTI)
총 차단 시간 (TBT)

시각적 안정성 측정값

UI 요소의 이동 정도와 이러한 변화가 사용자 상호작용에 방해가 되는지 여부 자세한 내용은 레이아웃 변경 최소화를 참고하세요.


추천 측정항목

누적 광고 이동
레이아웃 변경 횟수 (CLS)

페이지 실적 외에도 광고별 비즈니스 측정항목을 측정할 수 있습니다. 슬롯별 노출수, 클릭수, 조회가능성과 같은 정보는 Google Ad Manager 보고서에서 확인할 수 있습니다.

테스트 변경사항

성능 측정항목을 정의하고 이를 정기적으로 측정하기 시작하면 이 데이터를 사용하여 사이트에 발생한 변경사항의 성능에 미치는 영향을 평가할 수 있습니다. 이렇게 하려면 변경 전에 측정된 측정항목과 변경 전에 측정된 측정항목 (또는 이전에 설정한 기준)을 비교하면 됩니다. 이러한 유형의 테스트를 통해 성능 문제가 비즈니스 또는 사용자에게 심각한 문제가 되기 전에 이를 감지하고 해결할 수 있습니다.

자동 테스트

합성 테스트를 통해 사용자 상호작용에 종속되지 않는 측정항목을 측정할 수 있습니다. 이러한 종류의 테스트는 개발 프로세스 중에 최대한 자주 실행하여 출시되지 않은 변경사항이 성능에 미치는 영향을 파악해야 합니다. 이러한 사전 예방적 테스트는 변경사항이 사용자에게 출시되기 전에 성능 문제를 파악하는 데 도움이 됩니다.

이렇게 할 수 있는 한 가지 방법은 변경될 때마다 테스트가 자동으로 실행되는 지속적 통합 (CI) 워크플로의 일부로 합성 테스트를 만드는 것입니다. Lighthouse CI를 사용하면 합성 성능 테스트를 여러 CI 워크플로에 통합할 수 있습니다.

A/B 테스트

사용자 상호작용에 종속되는 측정항목은 변경사항이 실제로 사용자에게 출시될 때까지 완전히 테스트할 수 없습니다. 변경사항이 어떻게 작동할지 잘 모르는 경우 위험할 수 있습니다. 이 위험을 완화하는 한 가지 기법은 A/B 테스트입니다.

A/B 테스트 중에 페이지의 여러 대안이 사용자에게 무작위로 게재됩니다. 이 기법을 사용하여 수정된 버전의 페이지를 전체 트래픽의 일부에 제공할 수 있으며, 수정되지 않은 페이지는 대부분 계속 제공됩니다. RUM과 결합하면 두 그룹의 상대적 실적을 평가하여 트래픽의 100% 를 위험에 빠뜨리지 않고 어느 쪽의 실적이 더 우수한지 판단할 수 있습니다.

A/B 테스트의 또 다른 이점은 변경사항의 영향을 더 정확하게 측정할 수 있다는 점입니다. 많은 사이트에서 성능의 미세한 차이가 최근 변경사항으로 인한 것인지 아니면 트래픽의 정상적인 변동으로 인한 것인지 판단하기 어려울 수 있습니다. A/B 테스트의 실험 그룹은 전체 트래픽의 고정된 비율을 나타내므로 측정항목은 일정한 비율로 통제 그룹과 달라야 합니다. 따라서 두 그룹 간에 관찰된 차이가 테스트 중인 변경사항으로 인해 발생한 것이 더 확실할 수 있습니다.

최적화 도구Google 최적화 도구와 같은 도구를 사용하면 A/B 테스트를 설정하고 실행할 수 있습니다. 그러나 태그 기반 A/B 테스트 (이러한 도구의 기본 구성)는 성능에 부정적인 영향을 미치고 오해의 소지가 있는 결과를 제공할 수 있습니다. 따라서 서버 측 통합을 사용하는 것이 좋습니다.

A/B 테스트 결과

A/B 테스트를 사용하여 변경사항의 영향을 측정하려면 통제 그룹과 실험 그룹 모두에서 측정항목을 수집하고 서로 비교합니다. 이렇게 하려면 어떤 트래픽이 어떤 그룹에 속하는지 알 수 있는 방법이 필요합니다.

페이지 성능 측정항목의 경우, 각 페이지에 통제군 버전과 실험 버전 중 어느 것이 제공되었는지 나타내는 간단한 식별자를 포함하는 것만으로도 충분한 경우가 많습니다. 이 식별자는 측정항목을 파싱하고 상호 연관시킬 수 있는 대상이라면 무엇이든 상관없습니다. 사전 빌드된 테스트 프레임워크를 사용하는 경우 일반적으로 자동으로 처리됩니다.

광고별 비즈니스 측정항목의 경우 GPT의 키-값 타겟팅 기능을 사용하여 통제 그룹과 실험 그룹의 광고 요청을 구분할 수 있습니다.

// On control group (A) pages, set page-level targeting to:
googletag.pubads().setTargeting('your-test-id', 'a');

// On experimental group (B) pages, set page-level targeting to:
googletag.pubads().setTargeting('your-test-id', 'b');

그런 다음 Google Ad Manager 보고서를 실행할 때 이러한 키-값을 참조하여 그룹별로 결과를 필터링할 수 있습니다.