기기에서 과도하게 많은 리소스를 소비하는 광고는 성능 저하의 명백한 영향부터 배터리 소모 또는 대역폭 허용량 소모와 같은 눈에 덜 띄는 결과까지 사용자 환경에 부정적인 영향을 미칩니다. 이러한 광고는 암호화폐 마이너와 같이 적극적으로 악성 광고부터 의도치 않은 버그나 성능 문제가 발생한 진짜 콘텐츠에 이르기까지 다양합니다.
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를 통해 필요한 모니터링을 구현하세요.
광고 콘텐츠를 제작하거나 유지관리하는 광고 콘텐츠 제작 도구
계속 읽으면서 성능 및 리소스 사용 문제가 있는지 콘텐츠를 테스트하는 방법을 알고 있는지 확인합니다. 또한 선택한 광고 플랫폼에 관한 안내도 추가적인 기술적 조언이나 제한사항을 제공할 수 있으므로 참고해야 합니다. 예를 들어 Google 디스플레이 광고 소재 가이드라인을 참고하세요. 구성 가능한 기준점을 작성 도구에 직접 빌드하여 실적이 저조한 광고가 야생으로 유출되지 않도록 하는 것이 좋습니다.
광고가 삭제되면 어떻게 되나요?
Chrome에서의 개입은 intervention 보고서 유형과 함께 적절한 이름의 Reporting API를 통해 보고됩니다. Reporting API를 사용하면 보고 엔드포인트에 대한 POST 요청 또는 자바스크립트 내에서 개입에 대한 알림을 받을 수 있습니다.
이러한 보고서는 모든 하위 요소, 즉 개입으로 인해 로드 취소된 모든 프레임과 함께 광고가 태그된 루트 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는 개입 시 제공된 콜백을 트리거하는 데 사용할 수 있는 observe() 메서드와 함께 ReportingObserver를 제공합니다. 이는 디버깅에 도움이 되도록 보고서에 추가 정보를 첨부하려는 경우에 유용할 수 있습니다.
// 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 패널을 표시하여 광고의 전반적인 네트워크 활동을 확인합니다. 반복되는 로드에서 일관된 결과를 얻으려면 'Disable cache' 옵션을 선택하는 것이 좋습니다.
페이지 하단의 전송된 값에는 전체 페이지에서 전송된 금액이 표시됩니다. 상단에 있는 필터 입력을 사용하여 광고와 관련된 요청으로만 요청을 제한해 보세요.
광고의 초기 요청(예: iframe의 소스)을 찾은 경우 요청 내 Initiator 탭을 사용하여 광고가 트리거하는 모든 요청을 확인할 수도 있습니다.
전체 요청 목록을 크기별로 정렬하면 지나치게 큰 리소스를 파악하는 데 도움이 됩니다. 일반적인 원인으로는 최적화되지 않은 이미지와 동영상이 있습니다.
또한 이름별로 정렬하면 반복되는 요청을 파악하는 데 도움이 됩니다. 이는 개입을 트리거하는 하나의 큰 리소스가 아니라 점진적으로 한도를 초과하는 대량의 반복 요청일 수 있습니다.
CPU 사용량
DevTools의 Performance 패널은 CPU 사용량 문제를 진단하는 데 도움이 됩니다. 첫 번째 단계는 Capture Settings 메뉴를 여는 것입니다. CPU 드롭다운을 사용하여 CPU 속도를 최대한 높입니다. CPU 개입은 고급형 개발 머신에 비해 저전력 기기에서 트리거될 가능성이 훨씬 높습니다.
그런 다음 Record 버튼을 클릭하여 활동 기록을 시작합니다. 긴 트레이스는 로드하는 데 시간이 꽤 오래 걸릴 수 있으므로 기록하는 시기와 기간을 실험해 보는 것이 좋습니다. 녹화가 로드되면 상단 타임라인을 사용하여 기록의 일부를 선택할 수 있습니다. 스크립팅, 렌더링, 페인팅을 나타내는 노란색, 보라색 또는 녹색의 그래프 영역에 초점을 맞춥니다.
하단의 Bottom-Up, Call Tree, Event Log 탭을 살펴봅니다. Self Time(자체 시간) 및 Total Time(총 시간)을 기준으로 열을 정렬하면 코드에서 병목 현상을 식별하는 데 도움이 될 수 있습니다.
연결된 소스 파일도 여기에 연결되어 있으므로 Sources 패널로 이동하여 각 줄의 비용을 확인할 수 있습니다.
여기서 찾아야 할 일반적인 문제는 포함된 라이브러리 내에 숨겨진 연속 레이아웃 및 페인트 또는 비용이 많이 드는 작업을 트리거하는 잘못 최적화된 애니메이션입니다.
잘못된 개입을 신고하는 방법
Chrome은 리소스 요청을 필터 목록과 일치시켜 콘텐츠에 광고로 태그를 지정합니다. 광고가 아닌 콘텐츠에 태그가 추가된 경우 필터링 규칙과 일치하지 않도록 코드를 변경하는 것이 좋습니다. 개입이 잘못 적용되었다고 생각되면 이 템플릿을 통해 문제를 제기할 수 있습니다. 개입 보고서의 예를 캡처하고 문제를 재현할 수 있는 샘플 URL이 있는지 확인하세요.