블로그 광고 최적화 방법 Intersection Observer 사용방법

블로그 광고 성능과 Intersection Observer를 활용한 Core Web Vitals 향상하기

Intersection Observer 적용: 애드센스 등 무거운 블로그 광고 스크립트를 비동기 지연 로딩하여 웹 성능 저하를 방지하고 SEO 점수를 올리는 구체적인 방법을 알아보세요.​

---

웹 환경에서SEO(검색 엔진 최적화)의 핵심은 이제 사용자 경험(UX)이며, 구글은 이를 Core Web Vitals(코어 웹 바이탈)이라는 공식 지표를 통해 엄격하게 측정합니다. Core Web Vitals는 웹사이트의 로딩 속도, 상호작용 반응성, 그리고 시각적 안정성을 종합적으로 평가하는 핵심 지표입니다.

특히 광고나 무거운 서드파티 스크립트(예: Google AdSense, 데이블, 타불라 등 네이티브 광고 솔루션)를 페이지에 통합하는 과정에서 발생하는 성능 저하는 웹사이트의 생존과 검색 엔진 순위를 위협하는 가장 큰 요소입니다.

---

많은 퍼블리셔들이 "수익화 = 속도 저하"라는 잘못된 등식을 받아들이지만,이는 Intersection Observer(인터섹션 옵저버) API라는 최신 웹 표준 기술을 통해 충분히 극복하고 오히려 성능과 수익을 동시에 올릴 수 있습니다.

이제 LCP(Largest Contentful Paint), CLS(Cumulative Layout Shift), 그리고 INP(Interaction to Next Paint) 같은 핵심 지표를 손상시키지 않으면서도 광고 노출 효율, 즉 Viewability를 효율적으로 관리하는 지연 로딩(Lazy Loading)의 기술적 원리와 애드센스 광고(AdSense 코드)에 적용하는 구체적인 방법을 알아보고, 고성능 웹 아키텍처 구축을 시작합니다.

1. 블로그 광고로 인한 성능 저하의 근본 원인은 무엇일가요?

과거 수년 동안 웹 개발자들은 특정 요소가 뷰포트에 들어왔는지 감지하고 콘텐츠를 로드하기 위해 window.onscroll 이벤트 리스너에 의존해 왔습니다. 이 방식(스크롤 이벤트 기반 처리)은 근본적으로 비효율적이며, 브라우저 성능 저하의 주요 원인 중 하나입니다.

특히초기 광고 로딩 최적화를 위해 스크롤 이벤트를 활용하는 사례가 많았는데, 이는 성능 문제를 더욱 악화시키는 요인이 되었습니다. 스크롤 이벤트는 사용자 상호작용 중 가장 빈번하게 발생하는 이벤트이기 때문에, 이 리스너 내부에서 무거운 작업을 처리하면 브라우저에 큰 부담을 주게 됩니다. 이는 CPU 부하를 증가시키고 렌더링 파이프라인에 병목 현상을 유발합니다.

또한 이 방식은 디바운싱(Debouncing)이나 스로틀링(Throttling) 같은 보조적인 최적화 기법을 추가로 적용해야 하므로 코드 복잡도는 증가하고, 그럼에도 불구하고 메인 스레드에는 여전히 상당한 부담을 남기는 문제가 존재합니다. Intersection Observer는 이러한 수동적인 최적화 작업 자체를 필요 없게 만듭니다.

1. 메인 스레드(Main Thread)의 과부하와 INP 악화

window.onscroll 이벤트는 사용자가 스크롤할 때마다 매우 높은 빈도(초당 수십 회)로 콜백 함수를 실행합니다. 이 콜백 내에서 뷰포트 위치를 확인하기 위해 element.getBoundingClientRect() 같은 동기적인 레이아웃 계산 함수를 호출하는 순간, 브라우저의 메인 스레드가 강제로 점유됩니다.

메인 스레드는 DOM 조작, 스타일 계산, 레이아웃 처리, 페인팅, 그리고 사용자 이벤트 처리(클릭, 키 입력) 등 모든 중요한 작업을 담당하는 단일 작업 단위입니다.

빈번한 스크롤 이벤트 처리가 메인 스레드를 장시간 점유하게 되면, 블로그 응답 속도가 저하되고 FID(First Input Delay)는 물론, INP(Interaction to Next Paint) 점수가 악화됩니다. 메인 스레드 블로킹은 사용자 상호작용에 대한 응답을 지연시키는 장기 실행 작업(Long Task)을 유발하며, 이는 INP의 권장 임계값(300ms)을 쉽게 초과하게 만듭니다.

INP란 무엇인가요?

INP는 사용자가 페이지와 상호작용(클릭, 탭, 키 입력 등)했을 때부터 브라우저가 다음 시각적 업데이트(Next Paint)를 화면에 표시할 때까지 걸리는 시간을 측정합니다. 즉, 사용자가 액션을 취한 후 눈으로 결과를 보기까지의체감 응답 속도를 측정하는 지표이며, 웹사이트의 전반적인 반응성 품질을 나타냅니다. 50ms 이상의 응답 지연은 사용자에게 불쾌감을 줄 수 있습니다.

2. Layout Thrashing의 악순환과 강제 Re-Flow

더 심각한 문제는 레이아웃 스래싱(Layout Thrashing)입니다. 자바스크립트가 요소의 위치나 크기를 계산하기 위해 DOM에서 값을 읽어온 직후(예: offsetTop, clientWidth, getComputedStyle()), 곧바로 DOM을 변경(예: height = '200px', style.top = '10px')하면, 브라우저는 최신 값을 반영하기 위해 강제로 동기적인 재계산(Re-Flow/Re-Layout)을 수행해야 합니다.

Layout Thrashing이란, JavaScript가 화면 정보를 읽고 수정하는 작업을 반복하면서 브라우저에 강제 레이아웃 재계산을 일으키는 비효율적인 패턴입니다. 이러한 '읽기-쓰기-읽기-쓰기'의 반복적인 비효율은 레이아웃 재계산 비용을 수십 배 이상 증가시켜 CPU 부하를 극도로 증가시키며,페이지가 버벅거리는 '랙(Lag)' 현상을 유발하는 직접적인 원인이 됩니다.

특히 스크롤 기반 감지 로직은 이러한 반복을 자주 유발하지만, Intersection Observer는 이 문제를 메인 스레드에서 제거해 성능 저하를 근본적으로 해결합니다.

2. Intersection Observer의 기술적 우위: 비동기 및 브라우저 네이티브 최적화

Intersection Observer API는 이러한 구시대적 문제를 해결하기 위해 도입된 선언적(Declarative)이며 비동기적인(Asynchronous) 관찰 메커니즘입니다. 이 API는 웹 성능 최적화의 패러다임을 바꾼 핵심 기술입니다.

1. 메인 스레드로부터의 작업 분리 및 비동기 콜백의 장점

IO는 요소의 교차(Intersection) 여부를 브라우저 자체의 네이티브 코드 레벨에서, 즉 메인 스레드 밖의 합성 스레드(Compositor Thread)와 같은 더 효율적인 방식으로 감시하고 계산합니다. 따라서 스크롤 이벤트와는 달리, IO의 콜백 함수는 관찰 대상 요소가 개발자가 설정한 임계값(threshold)에 도달했을 때만 비동기적으로 호출됩니다.

이 비동기적 특성 덕분에 콜백 실행이 메인 스레드의 다른 중요한 작업(사용자 입력 처리 등)을 방해하지 않으며, 메인 스레드의 부하를 획기적으로 줄입니다.

이는 특히 First Input Delay(FID)와 INP 지표를 개선하는 데 핵심적인 역할을 합니다. IO는 특히 초기 로딩 시 보이지 않는 수많은 광고 슬롯이나 이미지의 로딩을 지연시켜 초기 로딩 성능(FCP, LCP) 개선에 결정적인 역할을 합니다. 불필요한 네트워크 요청을 줄이고 리소스를 효율적으로 사용할 수 있습니다.

2. rootMargin을 통한 스마트한 사전 로딩과 Viewability 확보 전략

IO는 관찰 영역(Root) 외에 rootMargin이라는 중요한 옵션을 제공합니다. 이 옵션을 사용하면 뷰포트에 실제로 들어오기 직전 (예: 뷰포트 하단으로부터 250px 위)에 광고 스크립트를 미리 실행하여 로딩을 시작할 수 있습니다. 이를 스마트한 사전 로딩(Pre-loading)이라고 부릅니다.

디지털 광고에서 Viewability는 광고의 중요한 수익 지표입니다.

Viewability (뷰어빌리티)란?

광고가 실제로 사용자에게 노출되었는지를 측정하는 지표입니다. 단순히 광고 페이지가 로딩되었다는 것 이상의, 광고가 사용자의 화면에 보여질 수 있는 상태였는지를 확인하는 핵심 성과 지표(KPI)입니다. IAB(Interactive Advertising Bureau)의 기준을 충족해야 광고 노출로 인정되어 수익으로 연결됩니다.

광고 유형	최소 기준
디스플레이 광고 (배너 광고)	광고 픽셀의 50% 이상이 최소 1초 이상 사용자 브라우저의 뷰포(Viewport) 내에 노출되어야 합니다.
동영상 광고 (Video Ads)	광고 픽셀의 50% 이상이 최소 2초 이상 연속적으로 뷰포트 내에 노출되어야 합니다.

rootMargin: '250px 0px 250px 0px'와 같이 설정하면, 사용자가 스크롤 했을 때 광고가 이미 로딩되어 표시되므로, 지연 로딩으로 인한 빈 공간 노출(UX 저하) 없이 광고 노출 효율(Viewability)을 높일수 있습니다. 이 값을 조정하여 성능과 수익 사이의 최적의 균형점을 찾을 수 있습니다.

3. Core Web Vitals 최적화에 미치는 직접적인 영향

Intersection Observer 기반의 지연 로딩은 LCP(Largest Contentful Paint)와 CLS(Cumulative Layout Shift)라는 두 가지 핵심 Core Web Vitals 지표를 개선하는 가장 강력하고 효과적인 수단입니다.

1. LCP(Largest Contentful Paint) 개선을 통한 SEO 점수 확보

LCP는 뷰포트 내에서 가장 큰 콘텐츠 요소(텍스트 블록, 이미지, 비디오 포스터 등)가 로드되어 사용자에게 보이는 데 걸리는 시간을 측정합니다. LCP는 페이지의 초기 로딩 체감을 측정하는 가장 중요한 지표입니다.

초기 페이지 로딩 시, 무거운 서드파티 광고 스크립트(adsbygoogle.js등)를 즉시 실행하지 않고 지연(Defer)시키면, 브라우저는 광고 처리로 인한 메인 스레드 경쟁 및 네트워크 리소스 경쟁에서 벗어나 텍스트나 메인 이미지 같은 주요 콘텐츠의 렌더링에 집중할 수 있습니다.

이는 초기 로드 시간을 단축시키고 Total Blocking Time (TBT)을 줄여 LCP를 2.5초 이내로 유지하는 데 결정적인 기여를 하며, 이는 곧 SEO 점수 향상으로 이어집니다.

2. CLS(Cumulative Layout Shift) 방지를 위한 공간 확보 의무와 CSS 전략

CLS는 예상치 못한 레이아웃 이동량을 측정하며, 광고가 늦게 로드되면서 페이지 콘텐츠를 밀어내는 것이 CLS 악화의 주요 원인입니다. Intersection Observer를 사용하더라도, 광고 영역이 로드될 때 밀림이 발생하면 CLS 점수가 급등합니다. CLS 목표는 0.1 이하입니다.

따라서 지연 로딩을 구현할 때는 광고 컨테이너(Placeholder)에 CSS를 사용하여 광고가 들어올 최소 공간(min-height, min-width)을 미리 확보해야 합니다. 광고 크기를 정확히 예측할 수 있다면 Aspect Ratio Box 기법(예: padding-bottom을 사용하여 비율 유지)을 활용하는 것이 최적입니다.

광고가 로드되어 실제 콘텐츠로 채워지더라도, 미리 확보된 공간 덕분에 주변 요소는 움직이지 않아 시각적 안정성을 보장하고 CLS를 완벽하게 방어할 수 있습니다.

4. 애드센스 광고의 세 구성 요소와 IO 적용 방법

Google AdSense 광고 코드는 세 가지 핵심 부분으로 나뉘며, Intersection Observer를 적용하는 전략은 3번 최종 실행 명령을 사용자 뷰포트 진입 시점으로 지연 제어(Lazy Execution)하는 것에 있습니다. 이 전략을 통해 광고 요청 및 렌더링을 최적의 시점에 수행하여 초기 로딩 성능을 확보합니다.

1. 1단계: 라이브러리 비동기 로드 (`adsbygoogle.js`)

이 코드는 head 또는 body 상단에 반드시 async 속성과 함께 삽입되어야 합니다. async 속성은 스크립트 다운로드 자체는 HTML 파싱을 블로킹하지 않도록 보장하지만, 다운로드가 완료되는 즉시 스크립트 실행이 시작될 수 있습니다. 이를 통해 광고 라이브러리 다운로드 지연이LCP에 미치는 영향을 최소화합니다.

2. 2단계: 광고 컨테이너 (Placeholder) 정의 및 CLS 방지

애드센스(AdSense)광고의 TML 요소는 광고 슬롯 ID를 포함하며, 이것이 바로 Intersection Observer의 관찰 대상이 됩니다. SEO 관점에서 가장 중요한 것은 이 요소 또는 이를 감싸는 부모에공간 확보 CSS를 적용하는 것입니다. min-height를 지정하여 광고가 로드될 때 다른 콘텐츠를 밀어내는 것을 방지하는 것이 CLS 방지를 위한 선결 조건입니다.

3. 3단계: IO를 활용한 최종 실행 명령 지연 및 Offloading

원래 즉시 실행되던 광고 요청 및 렌더링 명령인 (adsbygoogle = window.adsbygoogle || []).push({});를 자바스크립트 함수 내부로 캡슐화하고,Intersection Observer의 콜백 함수에서만 실행되도록 엄격히 제어합니다. 이로써 광고 스크립트의 무거운 실행 작업을 페이지 로딩 초기 단계에서 지연(Offloading)시켜 메인 스레드의 부하를 줄입니다. 이는 초기 성능 지표를 크게 개선합니다.

자동화 광고가 SEO에 악영향을 주는 주요 원인

자동화 광고는 스크립트가 페이지에 동적으로 광고를 삽입하기 때문에, 특히 다음 세 가지 Core Web Vitals 지표를 악화시킬 위험이 높습니다. 가능하면 최적의 광고 위치를 선정해서 수동으로 광고를 적용하세요!

1.CLS (Cumulative Layout Shift) 악화

• 문제: 자동화 광고는 페이지 로드 시점에 광고가 들어갈 영역의 공간을 미리 확보하지 못하는 경우가 많습니다. 페이지 콘텐츠가 모두 로드된 후에 광고 스크립트가 실행되어 갑자기 광고가 삽입되면, 주변 텍스트나 버튼이 아래로 밀려납니다.
• 결과: 이러한 예상치 못한 시각적 불안정성 때문에 CLS 점수가 높아지고, 이는 사용자 경험 저하로 이어져 SEO에 부정적인 영향을 미칩니다. (사용자가 버튼을 클릭하려는데 광고 때문에 위치가 바뀌어 실수로 광고를 클릭하는 등의 문제 발생)

2. LCP (Largest Contentful Paint) 지연

• 문제: 자동 광고를 로드하는 스크립트(adsbygoogle.js 등)는 무거운 서드파티 스크립트입니다. 이 스크립트가 초기 로딩 단계에서 실행되면, 브라우저의 메인 스레드를 점유하여 가장 큰 콘텐츠(LCP)인 메인 이미지나 텍스트의 렌더링을 방해할 수 있습니다.
• 결과: 페이지 로드 속도(체감 속도)가 느려져 LCP 점수가 권장 기준(2.5초 이내)을 초과할 가능성이 높아집니다. 초기 페이지 렌더링에 광고 리소스가 경쟁하면서 중요한 콘텐츠의 표시가 지연됩니다.

3. INP (Interaction to Next Paint) 악화

• 문제: 자동 광고 스크립트가 복잡한 광고 콘텐츠를 로드하고 렌더링하는 과정에서 메인 스레드를 장시간 점유하여 블로킹이 발생합니다. 이는 수백 밀리초에 달하는 긴 작업(Long Task)을 유발할 수 있습니다.
• 결과: 이 시점에 사용자가 버튼을 클릭하거나 스크롤하는 등의 상호작용을 시도하면, 메인 스레드가 광고 처리에 바빠 사용자 입력에 대한 응답이 지연됩니다. 이로 인해 INP 점수가 악화됩니다.

고성능 웹사이트의 필수적인 광고 최적화 아키텍처

Intersection Observer 기반의 지연 로딩은 더 이상 선택적 기능이 아니라, Core Web Vitals를 충족하고 SEO 경쟁에서 우위를 점하기 위한 필수적인 기술 스택입니다. 이 방법은 스크립트 실행을 사용자 시점에 맞춰 비동기적으로 지연시켜 LCP와 INP를 단축하고, 공간 확보 CSS와의 결합을 통해 CLS를 완벽하게 방어합니다.

이 최적화된 아키텍처를 통해 페이지 속도 문제와 SEO 패널티 걱정 없이, 방문자에게 최상의 경험을 제공하고 광고 수익을 올릴수 있는 성공적인 웹사이트를 구축하시길 바랍니다.

---

Q1. 스크롤 이벤트 기반 광고 로딩 방식이 왜 성능을 저하시킬까요?

스크롤 이벤트는 초당 수십 회 발생하며, 이때마다 DOM 위치 계산과 레이아웃 재계산이 동기적으로 반복됩니다. 이는 메인 스레드를 장시간 점유해 INP와 FID를 악화시키며, 광고 로딩 시 버벅임 현상을 유발합니다.

Q2. Intersection Observer는 기존 방식과 어떤 근본적인 차이가 있나요?

Intersection Observer는 뷰포트 진입 여부를 브라우저 네이티브 레벨에서 비동기적으로 감지하며, 스크롤 이벤트 없이도 요소들의 노출 상태를 효율적으로 관찰합니다. 이 방식은 메인 스레드 부하를 크게 줄여 Core Web Vitals를 개선합니다.

Q3. Layout Thrashing은 어떤 상황에서 발생하며 왜 위험한가요?

자바스크립트가 화면 정보를 읽기,쓰기를 반복할 때 브라우저가 강제로 레이아웃을 재계산하면서 CPU 사용량이 급증합니다. 특히 스크롤 기반 광고 감지 코드에서 흔히 발생하며 페이지 전체를 버벅거리게 만듭니다.

Q4. 광고 Viewability를 올리면서도 LCP,INP를 지킬 수 있는 방법이 있나요?

Intersection Observer의 rootMargin 옵션을 활용하면, 뷰포트 진입 직전에 광고를 사전 로딩하여 빈 공간 노출 없이 광고가 즉시 표시됩니다. 이는 광고 수익 지표(Viewability)를 높이면서도 성능 저하를 막습니다.

구글 애드센스 광고 적용 코드 예제

아래 코드를 자신의 애드센스 코드를 적용해서 HTML 코드 /BODY 부분위에 넣어 주시면 됩니다.

script
document.addEventListener("DOMContentLoaded", function() {
 let isAdsenseLibraryLoaded = false;
 
 // =========================================================
 // 1. 애드센스 라이브러리 로드 함수 (첫 번째 광고가 뷰포트에 들어올 때 단 한 번 실행됨)
 // =========================================================
 function loadAdsenseLibrary() {
 if (isAdsenseLibraryLoaded) return;
 
 const script = document.createElement('script');
 script.async = true;
 // 중요: 아래 'ca-pub-XXXXXXXXXXXX' 부분을 본인의 AdSense 클라이언트 ID로 반드시 교체하세요.
 script.src = 'https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-XXXXXXXXXXXX';
 script.crossOrigin = 'anonymous';
 document.head.appendChild(script);
 isAdsenseLibraryLoaded = true;
 }

 // =========================================================
 // 2. Intersection Observer 생성 및 처리 로직
 // =========================================================
 const adsenseObserver = new IntersectionObserver((entries, observer) = {
 entries.forEach(entry = {
 if (entry.isIntersecting) {
 const target = entry.target;

 if (target.classList.contains('adsbygoogle')) {
 // 1. 애드센스 라이브러리를 동적으로 로드 (최초 1회)
 loadAdsenseLibrary();
 // 2. 해당 슬롯의 광고 로드를 요청
 (window.adsbygoogle = window.adsbygoogle || []).push({});
 }

 // 3. 광고 로드 명령 실행 후 해당 요소 관찰 중단
 observer.unobserve(target);
 }
 });
 }, {
 // 뷰포트 상하 500px 전에 미리 로드 시작
 rootMargin: '500px 0px 500px 0px', 
 threshold: 0.0
 });

 // =========================================================
 // 3. 모든 애드센스 광고 요소에 대해 관찰 시작
 // =========================================================
 document.querySelectorAll('.adsbygoogle').forEach(adElement = {
 adsenseObserver.observe(adElement);
 });
});
/script