OpenAdLibraryOpenAdLibrary
네이티브 광고 네트워크

네이티브 위젯이 사이트 속도를 느리게 할까? 성능 영향 측정

콘텐츠 추천 위젯은 로드 시간을 추가하지만, 피해는 대부분 광고 형식 자체가 아닌 구현 방식에 관한 것입니다. 비용이 숨어 있는 곳과 해결 방법을 소개합니다.

에디토리얼 일러스트: 네이티브 위젯이 사이트 속도를 느리게 할까? 성능 영향 측정

Taboola, Outbrain, MGID 및 Revcontent의 네이티브 위젯은 주로 타사 JavaScript, 추가 광고 서버 왕복, 접힌 부분 아래의 이미지 자산 로드를 통해 측정 가능한 로드 시간을 추가합니다. 얼마나 해를 끼치는지는 구현 방식에 크게 의존합니다: 접힌 부분 아래에 배치된 비동기 로드, 지연 렌더링 위젯은 페이지 상단 근처의 메인 스레드를 차단하는 동기식 스크립트보다 훨씬 적은 비용이 듭니다.

성능 비용이 실제로 발생하는 곳#

콘텐츠 추천 위젯은 단일 요청이 아닙니다. 하나를 설치하면 일반적으로 다음이 트리거됩니다:

  • 퍼블리셔 자체의 스크립트 태그, 대부분의 최신 구현에서는 비동기식으로 로드되지만, 오래된 통합은 때때로 여전히 동기식으로 로드되어 렌더링을 차단합니다.
  • 네트워크의 광고 서버에 대한 호출로 해당 특정 페이지와 사용자에 대한 추천 세트를 가져옵니다.
  • 추가 수요측 및 헤더 비딩 왕복 - 네트워크가 직접 판매 재고 대신 프로그래매틱 경매를 실행하는 경우, 여러 헤더 비딩 파트너를 통해 연결될 수 있습니다.
  • 각 추천 항목에 대한 이미지 또는 썸네일 자산, 일반적으로 위젯 인스턴스당 6~12개입니다.
  • 렌더링 시 및 클릭 시 발화되는 트래킹 픽셀, 네트워크와 다운스트림 광고주 트래킹 모두를 위해.

이 각각이 지연 시간을 추가하며, 복합됩니다. CMS에서 "하나의 스크립트 태그"처럼 보이는 위젯은 실제로 렌더링될 때 한두 개 이상의 네트워크 요청을 트리거할 수 있습니다.

이것이 Core Web Vitals에 미치는 구체적인 영향#

가장 움직일 가능성이 높은 지표:

지표 일반적인 영향 이유
LCP (최대 콘텐츠풀 페인트) 일반적으로 낮음, 위젯 자체가 가장 큰 요소가 아닌 한 위젯이 접힌 부분 위에 렌더링되고 그 이미지가 큰 경우에만 문제
CLS (누적 레이아웃 이동) 종종 가장 큰 위험 위젯 컨테이너가 콘텐츠 로드 전에 크기가 지정되지 않으면 렌더링 시 페이지가 이동
INP (다음 페인트까지의 상호작용) 중간 메인 스레드에서 실행되는 추가 JavaScript가 클릭 및 스크롤에 대한 응답성을 지연시킬 수 있음
TTFB / 페이지 무게 작음에서 중간 추가 요청이 총 페이지 무게를 추가하지만, 올바르게 구현된 경우 일반적으로 초기 렌더링 이후

CLS는 가장 많은 퍼블리셔를 걸리게 하는 지표입니다. 왜냐하면 Google의 페이지 경험 신호가 가장 눈에 띄게 가중치를 두는 지표이기도 하기 때문입니다. 위젯이 예약된 컨테이너 크기 없이 로드되면 채워질 때 페이지가 눈에 띄게 이동하며, 이는 정확히 CLS가 패널티를 부과하는 것입니다.

동일한 위젯이 다른 사이트에서 다르게 성능을 보이는 이유#

기술적으로 동일한 Taboola 또는 Outbrain 통합을 실행하는 두 퍼블리셔는 의미 있게 다른 Core Web Vitals 결과를 볼 수 있으며, 그 차이는 거의 항상 위젯 코드 자체가 아닌 주변 페이지에서 비롯됩니다. 이미 가볍고, 타사 스크립트가 최소화되며, 이미지가 최적화되고, 빠른 호스팅 스택을 가진 페이지는 하나의 추가 비동기 위젯을 거의 눈에 띄는 영향 없이 흡수합니다. 왜냐하면 페이지의 로딩 예산에 여유 용량이 있기 때문입니다. 이미 여러 다른 타사 스크립트(분석, 채팅 위젯, 두 번째 광고 네트워크, 소셜 임베드)를 운반하는 페이지는 네이티브 위젯의 요청이 사용자가 실제로 눈치채는 요청이 되는 임계값을 넘어섭니다. 비록 그것이 총 페이지 무게의 작은 부분을 차지할지라도 말입니다. 위젯 추가 후 성능 불만을 해결하는 경우, 먼저 페이지에서 실행 중인 다른 모든 것을 감사하세요. 위젯은 종종 가장 최근에 추가된 가장 눈에 띄는 용의자이지만, 반드시 실제 병목 현상은 아닙니다.

속도 점수를 떨어뜨리지 않고 하나를 설치하는 방법#

측정 가능한 비용이 전혀 들지 않는 위젯과 사이트를 눈에 띄게 느리게 하는 위젯의 차이는 일반적으로 네트워크 자체가 아닌 구현 선택에서 비롯됩니다:

  1. 스크립트를 비동기식으로 로드하세요, 페이지 상단 근처에 차단 동기식 태그를 사용하지 마세요.
  2. 컨테이너 공간을 예약하세요 - 위젯이 채워지기 전에 고정 높이 또는 종횡비 CSS로 레이아웃 이동을 방지합니다.
  3. 접힌 부분 아래를 지연 로드하세요, 그래서 위젯의 요청이 초기 페이지 로드 중 대역폭을 주요 콘텐츠와 경쟁하지 않게 합니다.
  4. 주요 콘텐츠 뒤에 배치하세요, 독자 경험뿐만 아니라 LCP를 결정하는 실제 콘텐츠가 렌더링된 후에 로드를 자연스럽게 지연시키기 때문입니다.
  5. 가능한 경우 페이지당 하나의 위젯 인스턴스로 제한하세요. 여러 추천 위젯을 쌓는 것은 감소하는 수익률을 위해 요청 수를 곱합니다.
  6. 실제 장치 스로틀링으로 테스트하세요, 데스크톱 광대역만이 아닙니다. 모바일 4G 성능은 위젯 무게가 가장 고통스럽게 나타나는 곳입니다.

수익이 속도 절충 가치가 있을까요?#

이것이 실제 결정이며, 페이지 속도가 특정 사이트에 얼마나 가치 있는지에 따라 달라집니다. 유기 검색 트래픽에 크게 의존하고 페이지 경험이 순위에 의미 있게 영향을 미치는 경우, Core Web Vitals 점수를 떨어뜨리는 잘못 구현된 위젯은 광고 수익보다 검색 가시성에서 더 많은 비용을 치를 수 있습니다. 트래픽이 대부분 직접, 소셜 또는 뉴스레터 출처에서 오는 경우, 검색 순위가 더 작은 요소라면 속도 비용은 RPM 증가에 비해 상대적으로 덜 중요합니다.

어느 쪽이든, 해결책은 "네이티브 위젯을 실행하지 마세요"가 거의 아닙니다. 거의 항상 "구현을 수정하세요"입니다. 잘 구현된 비동기, 지연 로드, 적절히 크기가 지정된 Taboola, Outbrain, MGID 또는 Revcontent 위젯은 잘못 구현된 위젯보다 훨씬 적은 비용이 들며, 동일한 수익을 위해.

OpenAdLibrary가 약속하기 전에 비교하는 데 어떻게 도움을 주나요#

사용하지 않은 네트워크에서 위젯을 추가하기 전에, 판매 피치뿐만 아니라 다른 사이트에서 실제 인벤토리와 형식이 어떻게 보이는지 확인하는 것이 가치 있습니다. OpenAdLibrary를 사용하면 Taboola, Outbrain, MGID, Revcontent 및 기타 네트워크의 라이브 크리에이티브를 탐색하여 실제로 통합하게 될 형식, 이미지 밀도 및 클릭스루 메커니즘을 볼 수 있으며, 이는 데모 계정만으로 하는 것보다 구현 결정에 더 구체적인 기초가 됩니다.

실제로 자신의 사이트에 미치는 영향을 측정하는 방법#

이 글의 범위를 포함한 일반적인 영향 추정에 의존하지 마세요. 자신의 사이트를 직접 측정하세요:

  1. 먼저 기준선을 설정하세요. PageSpeed Insights 또는 WebPageTest와 같은 도구를 통해 주요 페이지를 실행하고, LCP, CLS 및 INP을 총 페이지 무게 및 요청 수와 함께 기록하세요.

  2. 위젯을 설치한 후 동일한 조건에서 동일한 페이지를 다시 테스트하세요. 스로틀링되지 않은 데스크톱뿐만 아니라 스로틀링된 모바일 연결 프로필을 사용하세요. 왜냐하면 영향이 가장 많이 나타나는 곳이기 때문입니다.

  3. 위젯의 기여도를 구체적으로 분리하세요. 대부분의 테스트 도구는 요청 출처별로 워터폴을 필터링할 수 있으므로, 위젯 자체가 자신의 사이트 기준선 대비 총 로드 시간 및 요청 수에서 얼마나 책임이 있는지 정확히 볼 수 있습니다.

  4. 구현 수정 후 다시 테스트하세요 (비동기 로드, 예약된 컨테이너 높이, 지연 로드) - 수정이 작동했다고 가정하지 마세요. 컨테이너 높이가 고정 픽셀 값 대응 반응형 종횡비 박스로 설정되는지와 같은 작은 구현 세부 사항은 동일한 기본 위젯에서도 의미 있게 다른 CLS 결과를 생성할 수 있습니다.

  5. 주기적으로 반복하세요, 시작 시 한 번만이 아닙니다. 네트워크는 때때로 퍼블리셔 측 통지 없이 자체 스크립트 동작이나 광고 밀도를 변경하므로, 6개월 전에 깨끗하게 측정된 설정은 다시 확인할 가치가 있습니다.

일반적인 구현 실수#

몇 가지 반복되는 문제가 대부분의 피할 수 있는 성능 비용을 차지합니다:

  • 예약된 컨테이너 높이 없음, 그래서 위젯이 채워질 때 페이지가 눈에 띄게 이동하여 CLS에 직접적인 손해를 줍니다.
  • 주요 콘텐츠 내부 또는 위에 위젯 배치 - 주요 콘텐츠 뒤가 아닌, 초기 로드 대역폭 및 우선순위를 실제 콘텐츠와 경쟁하게 합니다.
  • 한 페이지에 여러 위젯 인스턴스 쌓기, 제한된 추가 수익을 위해 요청 수를 곱합니다.
  • 오래된 동기식 통합 스니펫 사용 - 퍼블리셔가 몇 년 전에 복사하고 다시 방문하지 않은 것, 네트워크가 이후 비동기 버전을 출시했을 때.
  • 모바일에서 구체적으로 테스트하지 않음 - 느린 연결과 작은 뷰포트의 조합이 로드 시간과 레이아웃 이동 문제를 데스크톱 광대역에서 보이는 것보다 더 눈에 띄게 만드는 곳.

이들 대부분은 템플릿 코드에서 일회성 수정이며, 지속적인 유지 관리 부담이 아니므로, 모든 페이지 로드에 지속적이고 측정 가능한 저항을 견디는 것보다 제대로 한 번 수행할 가치가 있습니다.

결론#

네이티브 위젯은 측정 가능한 무게를 추가하며, CLS는 일반적으로 가장 면밀히 주시해야 할 지표입니다. 비용은 주로 광고 형식의 고유한 속성이 아닌 구현 품질(비동기 로드, 예약된 컨테이너 공간, 접힌 부분 아래 지연 로드)의 함수입니다. 평판에 기반한 영향을 가정하기보다 실제 장치 테스트로 실제 사전 및 사후를 측정하고, 형식 자체가 가치가 없다고 결론 내리기 전에 구현 문제를 수정하세요.

자주 묻는 질문

네이티브 위젯이 가장 많이 영향을 미치는 Core Web Vitals 지표는 무엇인가요?
누적 레이아웃 이동(CLS)이 일반적으로 가장 큰 위험입니다. 위젯 컨테이너가 로드되기 전에 크기가 지정되지 않으면 추천 항목이 채워질 때 페이지가 눈에 띄게 이동하기 때문입니다. LCP와 INP도 영향을 받을 수 있지만, 올바른 구현에서는 일반적으로 덜 심각합니다.
콘텐츠 추천 위젯을 동기식으로 로드해야 하나요, 비동기식으로 로드해야 하나요?
항상 비동기식으로 로드해야 합니다. 페이지 상단 근처의 동기식 스크립트 태그는 로드되는 동안 렌더링을 차단하여 로드 시간에 직접적인 손해를 줍니다. 거의 모든 주요 네이티브 네트워크는 비동기 로드를 지원합니다. 오래된 통합은 때때로 여전히 동기식을 기본값으로 사용하므로 특정 설정을 확인하세요.
한 페이지에 여러 네이티브 위젯을 실행하면 성능이 더 나빠지나요?
네, 요청 수와 스크립트 실행은 각 추가 위젯 인스턴스마다 대략적으로 곱해지며, 단위당 수익률은 감소합니다. 대부분의 퍼블리셔는 여러 개를 쌓는 것보다 한 페이지당 하나의 위젯을 잘 실행하는 것이 더 나은 결과를 얻습니다.
네이티브 광고 위젯을 지연 로드할 수 있나요?
네, 가능하며 위젯이 접힌 부분 아래에 위치한다면 해야 합니다. 지연 로드는 독자가 그 근처로 스크롤할 때까지 위젯의 네트워크 요청을 지연시켜 초기 페이지 로드 중 대역폭을 주요 콘텐츠와 경쟁하지 않게 합니다.
느리게 로드되는 위젯이 검색 순위에 해를 끼칠까요?
가능합니다. Core Web Vitals 점수가 이미 경계선에 있고 위젯이 이를 실패 범위로 밀어넣는 경우, 페이지 경험은 많은 순위 요소 중 하나이기 때문입니다. 해결책은 거의 항상 구현 방식(비동기 로드, 예약된 컨테이너 공간, 지연 로드)이며, 위젯을 완전히 제거하는 것이 아닙니다.
OpenAdLibrary 팀
작성자OpenAdLibrary 팀
광고 인텔리전스 및 네이티브 광고 리서치

우리는 오픈 광고 투명성 플랫폼인 OpenAdLibrary를 구축합니다. 매일 저희 시스템은 Taboola, Outbrain, MGID, Revcontent, Teads, Yahoo 및 MSN에서 라이브 네이티브 광고를 캡처하고, 각 광고 뒤의 실제 광고주를 식별하며, 클릭을 따라 랜딩 페이지까지 추적합니다. 이 가이드는 해당 데이터에서 확인한 내용을 정제하여 시장을 더 빠르게 연구할 수 있도록 돕습니다.