광고 붙인 뒤 느려진 사이트, Chrome에서 원인 찾는 법

Application의 Ads에서 조사할 광고를 좁힌다

광고를 넣은 뒤 페이지가 느려졌다면 Chrome DevTools의 Application → Ads에서 광고가 사용하는 자원부터 볼 수 있다. CPU와 네트워크 사용량을 광고 요소별로 나누고, 메인 프레임에서 광고로 분류된 스크립트 목록을 보여 주는 화면이다.

Chrome의 10월 DevTools 소개에는 화면 안의 광고 개수·면적 비중과 광고의 CPU·네트워크 사용량이 함께 안내돼 있다. 광고가 눈에 얼마나 많이 보이는지와 광고 처리에 CPU·네트워크 자원이 얼마나 쓰이는지를 나눠 볼 수 있다.

검사할 페이지에서 개발자 도구를 열고 Ads를 선택한다. Highlight Ads를 켜면 Chrome이 광고로 분류한 프레임이 붉게 강조된다. 눈에 보이는 위치와 자원 사용량을 연결해 조사할 대상을 고르는 출발점이다.

어느 스크립트를 따라가야 하는지 분류 근거를 본다

10월 20일 공개된 11월 DevTools 소개는 Ads에 Ad provenance 열이 추가됐다고 알렸다. Chrome 155·156의 변경으로, 스크립트가 광고로 분류된 근거를 표시한다.

여기서는 요청 주소가 필터 규칙에 걸렸는지, 상위 광고 스크립트의 실행 연결을 통해 분류됐는지 구분할 수 있다. 파일 이름만으로 정체를 알기 어려운 스크립트도 어느 광고 호출에서 이어졌는지 조사할 실마리를 얻는다.

이 표시는 광고 분류의 근거다. 실제로 느린 작업을 하는지는 CPU 기록이나 요청 시간을 함께 봐야 한다. 광고 프레임으로 한번 분류된 iframe은 다른 주소로 이동해도 그 분류를 유지하며, 그 안에서 시작된 요청도 광고 분류를 이어받는다.

버벅임은 Performance, 느린 다운로드는 Network

CPU 사용이 문제라면 Performance에서 느려지는 동작을 녹화하고 해당 시간 구간을 선택한다. 공식 Performance 안내의 Bottom-up은 그 구간에서 시간을 많이 쓴 작업을 합산해 보여 준다.

Self Time은 작업 자체에 쓴 시간, Total Time은 하위 호출까지 포함한 시간이다. 오래 걸리는 작업과 연결된 소스를 보고, Call tree에서 어떤 호출이 그 작업을 시작했는지 따라간다. 광고 파일을 찾았다는 사실에서 한 단계 더 들어가 실제 실행 비용을 확인하는 과정이다.

네트워크는 Network의 열 제목을 오른쪽 클릭해 Is ad-related를 표시하면 광고로 분류된 요청을 식별하기 쉽다. Ad Manager 진단 안내처럼 Time이나 Waterfall로 느린 요청을 찾고, Initiator로 그 요청을 시작한 리소스·스크립트를 확인한다.

재현 조건을 맞추고 로컬 수치와 실제 이용자 집계를 구분한다

광고 차단 확장 프로그램이 켜진 브라우저에서는 문제의 광고가 아예 요청되지 않을 수 있다. 진단할 때는 방해하는 확장의 영향을 제거하고, 같은 페이지에서 문제가 나타나는 스크롤·새로고침 동작을 재현한다. 캐시 사용 여부도 측정 기록에 남겨 비교 조건을 맞춘다.

Ads에서 보는 로컬 측정값과 실제 Chrome 이용자 경험을 집계한 CrUX는 범위가 다르다. CrUX 광고 지표 안내는 75백분위 값을 제공하며, Core Web Vitals처럼 좋음·나쁨을 가르는 기준값은 없다고 설명한다.

수정 전후에는 같은 동작에서 같은 광고 요소의 실행 시간과 요청 시간을 비교한다. 원인을 외부 광고 사업자에게 전달해야 한다면 페이지 주소, 발생 시각, 재현 순서와 문제가 된 요청을 함께 남긴다. 전체 페이지가 느리다는 설명보다 어느 요청과 작업에서 지연됐는지가 개선할 대상을 분명하게 만든다.