기기에서 과도한 양의 리소스를 소비하는 광고는 성능 저하와 같은 명백한 영향에서 배터리 소모나 대역폭 허용량 소모와 같은 눈에 잘 띄지 않는 결과에 이르기까지 사용자 환경에 부정적인 영향을 미칩니다. 이러한 광고는 암호화폐 채굴기와 같이 적극적으로 악의적인 광고부터 의도치 않은 버그나 성능 문제가 있는 실제 콘텐츠까지 다양합니다.
Chrome은 광고에서 사용할 수 있는 리소스에 한도를 설정하고 한도가 초과되면 해당 광고를 언로드합니다. 자세한 내용은 Chromium 블로그의 공지를 참고하세요. 광고를 언로드하는 데 사용되는 메커니즘은 과도한 광고 개입입니다.
과도한 광고 기준
사용자가 광고와 상호작용하지 않았고 (예: 탭하거나 클릭하지 않음) 다음 기준 중 하나를 충족하는 광고는 과도한 광고로 간주됩니다.
- 총 60초 이상 동안 기본 스레드를 사용합니다.
- 30초 간격으로 15초 이상 기본 스레드를 사용합니다.
- 4MB 이상의 네트워크 대역폭 사용
광고 프레임의 하위 요소 iframe에서 사용하는 모든 리소스는 해당 광고에 개입하기 위한 한도에 반영됩니다. 메인 스레드 시간 제한은 광고를 로드한 후 경과된 시간과 다르다는 점에 유의해야 합니다. CPU가 광고 코드를 실행하는 데 걸리는 시간에 제한이 있습니다.
개입 테스트
이 개입은 Chrome 85에서 출시되었지만 기본적으로 사용자 개인 정보를 보호하기 위해 임곗값에 약간의 노이즈와 가변성이 추가됩니다.
chrome://flags/#heavy-ad-privacy-mitigations를 사용 안함으로 설정하면 이러한 보호 조치가 삭제됩니다. 즉, 제한사항이 전적으로 한도에 따라서만 확정적으로 적용됩니다. 이렇게 하면 디버깅과 테스트가 더 쉬워집니다.
개입이 트리거되면 용량이 큰 광고의 iframe에 있는 콘텐츠가 광고가 삭제됨 메시지로 대체됩니다. 포함된 세부정보 링크를 따라가면 '이 광고는 기기에서 너무 많은 리소스를 사용하여 Chrome에서 광고를 삭제했습니다.'라는 메시지가 표시됩니다.
heavy-ads.glitch.me에서 샘플 콘텐츠에 적용된 개입을 확인할 수 있습니다. 이 테스트 사이트를 사용하여 임의의 URL을 로드하여 자체 콘텐츠를 빠르게 테스트할 수도 있습니다.
테스트할 때는 개입이 적용되지 못하게 하는 여러 가지 이유가 있다는 점에 유의하세요.
- 동일한 페이지에서 동일한 광고를 새로고침하면 이 조합은 개입 대상에서 제외됩니다. 방문 기록을 삭제하고 새 태그로 페이지를 열면 도움이 될 수 있습니다.
- 페이지에 포커스가 계속 유지되도록 합니다. 페이지를 백그라운드로 전환 (다른 창으로 전환)하면 페이지의 태스크 큐가 일시중지되므로 CPU 개입이 트리거되지 않습니다.
- 테스트 중에 광고 콘텐츠를 탭하거나 클릭하지 마세요. 사용자 상호작용을 받는 콘텐츠에는 개입이 적용되지 않습니다.
취해야 할 조치는 무엇인가요?
사이트에 서드 파티 제공업체의 광고를 게재하는 경우
광고주가 취해야 할 조치는 없으며, 사이트에서 삭제된 한도를 초과하는 광고가 사용자에게 표시될 수 있다는 점에 유의하세요.
사이트에 퍼스트 파티 광고를 게재하거나 서드 파티 디스플레이용 광고를 제공하는 경우
계속해서 읽고 과도한 광고 개입을 위해 Reporting API를 통해 필요한 모니터링을 구현하세요.
광고 콘텐츠를 만들거나 광고 콘텐츠 제작 도구를 유지관리하는 경우
계속해서 콘텐츠의 성능 및 리소스 사용량 문제를 테스트하는 방법을 알아보세요. 또한 선택한 광고 플랫폼에서는 추가적인 기술적 조언이나 제한사항을 제공할 수 있으므로 디스플레이 광고 소재 가이드라인을 참고하세요. 실적이 저조한 광고가 게재되지 않도록 구성 가능한 기준점을 제작 도구에 직접 빌드하는 것이 좋습니다.
광고가 삭제되면 어떻게 되나요?
Chrome의 개입은 intervention 보고서 유형과 함께 적절한 이름의 Reporting API를 통해 보고됩니다. Reporting API를 사용하면 보고 엔드포인트에 대한 POST 요청으로 또는 JavaScript 내에서 개입에 대한 알림을 받을 수 있습니다.
이러한 보고서는 루트 광고가 태그된 iframe에서 모든 하위 요소와 함께, 즉 개입에 의해 로드 취소된 모든 프레임에서 트리거됩니다. 즉, 광고가 서드 파티 소스(예: 교차 사이트 iframe)에서 발생한 경우 해당 서드 파티(예: 광고 제공업체)에서 신고를 처리해야 합니다.
HTTP 보고서용 페이지를 구성하려면 응답에 Report-To 헤더가 포함되어야 합니다.
Report-To: { "url": "https://example.com/reports", "max_age": 86400 }
트리거된 POST 요청에는 다음과 같은 보고서가 포함됩니다.
POST /reports HTTP/1.1
Host: example.com
…
Content-Type: application/report
[{
"type": "intervention",
"age": 60,
"url": "https://example.com/url/of/ad.html",
"body": {
"sourceFile": null,
"lineNumber": null,
"columnNumber": null,
"id": "HeavyAdIntervention",
"message": "Ad was removed because its CPU usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384"
}
}]
JavaScript API는 ReportingObserver에 개입 시 제공된 콜백을 트리거하는 데 사용할 수 있는 observe() 메서드를 제공합니다. 디버깅에 도움이 되는 추가 정보를 보고서에 첨부하려는 경우 유용합니다.
// callback that will handle intervention reports
function sendReports(reports) {
for (let report of reports) {
// Log the `report` json via your own reporting process
navigator.sendBeacon('https://report.example/your-endpoint', report);
}
}
// create the observer with the callback
const observer = new ReportingObserver(
(reports, observer) => {
sendReports(reports);
},
{ buffered: true }
);
// start watching for interventions
observer.observe();
그러나 개입으로 인해 페이지가 실제로 iframe에서 삭제되므로 페이지가 완전히 사라지기 전에 보고서가 확실히 캡처되도록 하는 안전 장치를 추가해야 합니다(예: iframe 내 광고). 이를 위해 동일한 콜백을 pagehide 이벤트에 연결할 수 있습니다.
window.addEventListener('pagehide', (event) => {
// pull all pending reports from the queue
let reports = observer.takeRecords();
sendReports(reports);
});
사용자 환경을 보호하기 위해 pagehide 이벤트는 그 안에서 발생할 수 있는 작업의 양을 제한합니다. 예를 들어 보고서와 함께 fetch() 요청을 전송하려고 하면 요청이 취소됩니다.
navigator.sendBeacon()를 사용하여 보고서를 전송해야 하지만, 이 경우에도 브라우저의 최선의 방식으로 전송되며 보장되지는 않습니다.
JavaScript에서 생성된 JSON은 POST 요청에서 전송된 JSON과 유사합니다.
[
{
type: 'intervention',
url: 'https://example.com/url/of/ad.html',
body: {
sourceFile: null,
lineNumber: null,
columnNumber: null,
id: 'HeavyAdIntervention',
message:
'Ad was removed because its network usage exceeded the limit. See https://www.chromestatus.com/feature/4800491902992384',
},
},
];
개입 원인 진단
광고 콘텐츠는 웹 콘텐츠이므로 Lighthouse와 같은 도구를 사용하여 콘텐츠의 전반적인 실적을 감사하세요. 감사 결과는 개선에 관한 인라인 안내를 제공합니다. web.dev/fast 컬렉션을 참고할 수도 있습니다.
보다 고립된 맥락에서 광고를 테스트하는 것이 좋습니다. https://heavy-ads.glitch.me의 맞춤 URL 옵션을 사용하여 사전 제작된 광고 태그가 지정된 iframe으로 이를 테스트할 수 있습니다. Chrome DevTools를 사용하여 콘텐츠가 광고로 태그되었는지 확인할 수 있습니다. 렌더링 패널 (점 3개로 된 ⋮ 메뉴에서 도구 더보기 > 렌더링을 통해 액세스 가능)에서 '광고 프레임 강조 표시'를 선택합니다. 최상위 창 또는 콘텐츠가 광고로 태그되지 않은 다른 컨텍스트에서 콘텐츠를 테스트하는 경우 개입이 트리거되지 않지만 여전히 임곗값을 수동으로 확인할 수 있습니다.
프레임의 광고 상태는 Elements 창에도 표시됩니다. 이 창에서는 여는 <iframe> 태그 뒤에 ad 주석이 추가됩니다. 이는 프레임 섹션의 애플리케이션 패널에서도 확인할 수 있으며, 광고 태그가 지정된 프레임에는 '광고 상태' 속성이 포함됩니다.
네트워크 사용량
Chrome DevTools에서 Network 패널을 표시하여 광고의 전반적인 네트워크 활동을 확인합니다. 반복 로드에서 일관된 결과를 얻으려면 '캐시 사용 중지' 옵션을 선택해야 합니다.
페이지 하단의 전송된 값에는 전체 페이지에 대해 전송된 금액이 표시됩니다. 상단에 있는 필터 입력을 사용하여 광고와 관련된 요청으로만 요청을 제한하세요.
광고의 초기 요청(예: iframe의 소스)을 찾은 경우 요청 내의 이니시에이터 탭을 사용하여 이니시에이터가 트리거하는 모든 요청을 볼 수도 있습니다.
전체 요청 목록을 크기순으로 정렬하면 지나치게 큰 리소스를 찾는 데 도움이 됩니다. 최적화되지 않은 이미지와 동영상이 일반적인 원인입니다.
또한 이름순으로 정렬하면 반복되는 요청을 찾는 데 도움이 됩니다. 개입을 트리거하는 하나의 대규모 리소스가 아니라 점진적으로 한도를 초과하는 다수의 반복 요청일 수 있습니다.
CPU 사용량
DevTools의 성능 패널을 사용하면 CPU 사용량 문제를 진단할 수 있습니다. 첫 번째 단계는 Capture Settings(설정 캡처) 메뉴를 여는 것입니다. CPU 드롭다운을 사용하여 CPU 속도를 최대한 낮춥니다. CPU에 대한 개입은 고급형 개발 머신에 비해 저전력 기기에서 트리거될 가능성이 훨씬 더 높습니다.
그런 다음 Record(녹화) 버튼을 클릭하여 활동 녹화를 시작합니다. 긴 트레이스는 로드하는 데 상당한 시간이 걸릴 수 있으므로 기록하는 시기와 기간을 실험해 보는 것이 좋습니다. 녹화 파일이 로드되면 상단 타임라인을 사용하여 녹화 파일의 일부를 선택할 수 있습니다. 그래프에서 노란색, 보라색 또는 녹색으로 스크립팅, 렌더링, 페인팅을 나타내는 영역에 집중합니다.
하단의 하향식, 호출 트리, 이벤트 로그 탭을 살펴봅니다. Self Time 및 Total Time으로 열을 정렬하면 코드의 병목 현상을 식별하는 데 도움이 됩니다.
연결된 소스 파일도 여기에 연결되어 있으므로 소스 패널로 이동하여 각 행의 비용을 검사할 수 있습니다.
여기에서 확인해야 할 일반적인 문제는 연속 레이아웃 및 페인트를 트리거하는 최적화되지 않은 애니메이션 또는 포함된 라이브러리 내에 숨겨진 비용이 많이 드는 작업입니다.
잘못된 개입을 신고하는 방법
Chrome은 필터 목록과 리소스 요청을 비교하여 콘텐츠에 광고로 태그를 지정합니다. 광고가 아닌 콘텐츠에 태그가 지정된 경우 필터링 규칙과 일치하지 않도록 해당 코드를 변경하는 것이 좋습니다. 개입이 잘못 적용되었다고 생각되면 이 템플릿을 통해 문제를 제기할 수 있습니다. 개입 보고서의 예시를 캡처하고 문제를 재현할 샘플 URL을 준비해 주세요.