이 사례 연구에서는 서드 파티 리소스의 실적을 개선하여 비즈니스 측정항목을 높이는 방법을 중점적으로 설명합니다. 이전 연구에서는 추가된 광고 지연 시간의 비용을 측정했지만, 이 연구에서는 실제 실적 개선의 가치를 보여줍니다.
0.5%
게시자 수익 증가
2%
초기 광고 스크립트 로드 증가
출처: Google 내부 데이터, 2019년 6월~7월
배경
Google 게시자 태그 (GPT)는 웹에서 디스플레이 광고를 요청하고 렌더링하는 Google Ad Manager의 광고 태그 지정 스크립트입니다. GPT에 stale-while-revalidate HTTP 헤더를 구현함으로써 GPT팀은 게시자 파트너를 위한 Google 디스플레이 광고의 속도와 실적을 개선할 수 있었습니다. 이와 동일한 기법은 최신 코드를 로드하는 것보다 스크립트를 최대한 빨리 로드하는 것이 더 중요한 다른 시나리오에도 적용할 수 있습니다.
문제
GPT는 15분의 짧은 TTL (수명)이 부여된 부트스트랩 스크립트인 gpt.js로 배포됩니다. 이 짧은 TTL을 사용하면 스크립트를 빠르게 업데이트하거나 롤백할 수 있습니다. 로드되면 gpt.js는 TTL이 더 긴 추가 구현 스크립트를 요청하고 로드합니다.
15분 TTL이 만료되면 캐시의 gpt.js 버전이 오래되어 다시 확인해야 합니다. 이전에는 이 재검증 프로세스에 동기식 네트워크 요청을 통해 스크립트의 최신 사본을 가져와 첫 번째 광고 요청에 지연 시간을 추가하는 작업이 포함되었습니다.
솔루션
stale-while-revalidate 속성은 Cache-Control 헤더에서 사용되며, 애셋이 비동기식으로 재검증되는 동안 캐시가 오래된 애셋을 사용할 수 있는 추가 시간 범위를 정의합니다. 이를 통해 개발자는 즉시성—캐시된 콘텐츠를 즉시 로드—과
최신성—캐시된 콘텐츠에 대한 업데이트가 향후 사용되도록 보장 간의 균형을 맞출 수 있습니다.
Google 디스플레이 광고 사례 연구
GPT팀은 브라우저가 stale-while-revalidate를 구현할 것으로 예상하고 2016년에 gpt.js HTTP 응답에 이 Cache-Control 헤더를 추가했습니다.
cache-control: private, max-age=900, stale-while-revalidate=3600
이 설정은 이전 캐시된 값 이후 15~60분 사이에 gpt.js가 요청되면 오래된 값이라도 캐시된 값을 사용하여 요청을 처리한다는 의미입니다. 동시에 향후 사용을 위해 캐시에 최신 값을 채우는 재검증 요청이 백그라운드에서 이루어집니다.
Chrome은 버전 75에서 모든 트래픽의 99% 에 stale-while-revalidate를 출시했으며, 영향을 측정하기 위해 1% 의 트래픽에서 이 기능을 일시적으로 사용 중지했습니다. GPT팀은 광고 스크립트에 stale-while-revalidate의 효과를 테스트하기 위해 이 1% (실험 그룹)의 측정항목과 기능이 사용 설정된 트래픽의 1% 샘플 (통제 그룹)을 로깅했습니다. 52억 건의 Google 디스플레이 광고 노출 샘플 크기에서 로깅된 2주간의 측정항목을 통해 통제 그룹은 다음을 관찰했습니다.
- 광고 노출수 0.3% 증가
- 수익 0.5% 증가
- 초기 광고 스크립트 로드 2% 증가(페이지 로드 시작 후 500밀리초 미만)
- 전반적으로 성공적인 광고 스크립트 로드 1.1% 증가 출처:
차트에 표시된 대로 이 실험의 결과는 성공적인 광고 스크립트 로드의 증가에 기인하며, 대부분은 페이지 로드 프로세스 초기에 발생합니다.
사이트에 stale-while-revalidate 구현
GPT팀은 stale-while-revalidate를 사용하여 HTTP 헤더를 비교적 작게 변경하면 속도를 개선하고 비즈니스 측정항목을 높일 수 있음을 확인했습니다. 자체 사이트에 stale-while-revalidate를 구현하는 방법에 관한 자세한 내용은
stale-while-revalidate로 최신 상태 유지하기
를 참고하세요.