분석 및 추적 스크립트를 제한해야 하는 이유

분석 및 추적 스크립트를 제한해야 하는 이유

저는 웹사이트 감사에 많은 시간을 할애하며, 그중 약 90%의 감사에서 사용되지 않는 추적 스크립트를 발견합니다. 아무도 추가한 기억이 없는 스크립트, 아무도 읽지 않는 데이터를 추적하는 스크립트, 2년 전 마케팅 팀에서 "픽셀 하나만 더"라며 추가한 스크립트들입니다. 당시에는 각각 무해해 보였을 것입니다. 하지만 이것들이 모이면 모든 페이지 로드에 몇 초의 지연이 추가됩니다.

Kaspersky의 2024년 웹 추적 보고서에 따르면, 현재 일반적인 웹사이트에는 48개의 트래커가 있습니다. 2025 Web Almanac은 90% 이상의 웹 페이지가 적어도 하나의 서드파티 스크립트를 포함하고 있으며, 방문자 수가 가장 많은 상위 1,000개 사이트의 데스크톱 환경에서는 중앙값 기준 129개의 서드파티 요청이 발생한다는 것을 보여줍니다. 이것은 추적 전략이 아닙니다. 심각한 성능 문제입니다.

최종 검토: Arjen Karel, 2026년 3월

사이트에서 분석 및 추적 스크립트를 사용하는 이유

분석 및 추적 스크립트는 실제 목적에 기여합니다. Google Analytics는 방문자의 유입 경로를 알려줍니다. Facebook Pixel은 광고 전환을 추적합니다. Hotjar는 사람들이 클릭하는 위치를 보여줍니다. 이러한 데이터가 없다면 그저 추측만 할 뿐입니다.

문제는 이러한 도구가 존재한다는 사실이 아닙니다. 대부분의 사이트가 필요 이상으로 훨씬 많은 추적 스크립트를 로드한다는 것이 문제입니다. Google Analytics, Facebook Pixel, Cloudflare 분석과 같이 널리 사용되는 도구들은 모두 JavaScript, 쿠키, HTTP 요청을 추가합니다. 그리고 페이지에 단일 추적 스크립트만 존재하는 경우는 거의 없습니다.

Fact: 모든 감사의 약 90%에서 사용되지 않는 추적 스크립트가 발견됩니다. 일반적으로 이러한 스크립트는 태그 관리자나 다른 서드파티 스크립트를 통해 나중에 주입됩니다.

이러한 스크립트들은 얼마나 무거울까요?

모든 추적 스크립트가 동일하게 만들어진 것은 아닙니다. 가장 일반적인 스크립트들이 실제로 초래하는 비용은 다음과 같습니다.

• Google Analytics 4 (gtag.js): 압축 시 134 KB, 비압축 시 371 KB입니다. 비동기식으로 로드되므로 렌더링을 차단하지는 않지만, 메인 스레드에서 여전히 JavaScript를 파싱하고 실행해야 합니다.
• Google Tag Manager: 라이브러리 자체는 압축 시 약 33 KB이며, 여기에 내부에 추가하는 태그 용량이 더해집니다. 컨테이너의 중앙값은 약 50 KB입니다. 비어 있는 GTM 컨테이너는 약 100ms의 지연을 추가합니다. GTM 내부에 8개의 추적 태그가 있을 경우 Fast 3G에서 약 3초, Slow 3G에서 약 10초의 지연이 추가됩니다.
• Facebook/Meta Pixel: 비압축 시 340 KB(압축 시 95 KB)입니다. 이는 Google Analytics보다 7배 더 큽니다. 완료되기 전까지 4번의 HTTP 요청을 수행하며, 모든 페이지 로드에 1.3~1.5초를 추가합니다.
• Consent Management Platforms: 구성에 따라 OneTrust는 124~347 KB를 추가할 수 있습니다. 한 사례에서는 동의 배너가 LCP 요소가 되어, LCP를 1.43초에서 3.61초로 증가시켰습니다.

GA4 + GTM + Facebook Pixel + 동의 배너를 중첩하면, 자체 코드가 실행되기도 전에 대략 400~600 KB의 추적 JavaScript를 마주하게 됩니다. 이는 종종 전체 페이지 콘텐츠 자체보다 더 큰 용량입니다.

추적 스크립트가 Core Web Vitals에 미치는 영향

Largest Contentful Paint

모든 스크립트는 페이지 로드 중에 네트워크 대역폭과 CPU 시간을 놓고 경쟁합니다. 비동기 스크립트조차도 LCP 이미지나 핵심 CSS에 사용될 수 있는 대역폭을 차지합니다. 히어로 이미지와 함께 8개의 추적 스크립트를 로드하면, 브라우저가 제한된 모바일 대역폭을 이 모든 항목과 공유하도록 강제하는 것입니다.

이는 모바일 네트워크에서 특히 좋지 않습니다. 2025 Web Almanac은 모바일 환경의 Total Blocking Time 중앙값이 1,916ms(2024년 대비 58% 증가)라고 보고합니다. 이러한 차단의 대부분은 서드파티 JavaScript에서 비롯됩니다. 스크립트를 지연시킬 수는 있지만, 로드가 시작되면 여전히 리소스를 놓고 경쟁하게 됩니다.

Interaction to Next Paint

Interaction to Next Paint (INP)는 추적 스크립트가 가장 큰 피해를 주는 지표입니다. 2024 Web Almanac에 따르면 프레젠테이션 지연이 열악한 INP의 주요 원인이며, 이를 유발하는 스크립트는 행동 추적 도구, 동의 제공업체 및 광고 픽셀입니다.

많은 추적 스크립트가 페이지 로드가 완료된 후에도 오랫동안 계속 작동합니다. Google Analytics는 모든 클릭을 추적하도록 구성할 수 있습니다. Hotjar와 같은 히트맵 도구는 모든 마우스 움직임을 수신합니다. 이러한 각 이벤트 리스너는 사용자 상호 작용에 처리 시간을 추가합니다. 방문자가 버튼을 클릭했을 때 사용자 코드가 이를 처리하는 데 50ms가 걸리지만, 세 개의 추적 스크립트가 함께 이벤트 리스너를 실행하여 150ms를 더 추가한다면 해당 상호 작용은 느리게 느껴질 것입니다.

수치가 이를 증명합니다. 전체 모바일 페이지의 77%가 INP를 통과하지만, 방문자 수가 가장 많은 상위 1,000개 웹사이트 중에서는 53%만이 통과합니다. 이러한 상위 사이트들은 더 복잡한 JavaScript와 더 많은 서드파티 스크립트를 가지고 있습니다. 페이지의 응답성을 유지하고 싶다면, 추적 스크립트를 가장 먼저 살펴봐야 합니다.

Time to First Byte 및 쿠키 오버헤드

각 추적 스크립트는 자체 쿠키를 배치할 수 있습니다. 개별 쿠키는 작지만(2025 Web Almanac 쿠키 챕터에 따르면 중앙값 40바이트), 쿠키 데이터는 모든 HTTP 요청과 함께 전송되기 때문에 그 집합적인 영향이 누적됩니다. 사이트가 4 KB의 쿠키를 설정하고 39개의 리소스를 로드한다면, 해당 요청 전반에 걸쳐 156 KB의 추가 업로드 데이터가 발생하는 것입니다.

총 쿠키 데이터가 약 1,500바이트를 초과하면, 요청 헤더가 더 이상 단일 TCP 패킷에 맞지 않게 됩니다. 이는 추가적인 왕복을 강제하며, 이후의 탐색 및 정적 리소스 로드 시 Time to First Byte를 직접적으로 증가시킵니다.

Cumulative Layout Shift

여기서는 동의 배너가 최악의 원인입니다. 쿠키 동의 배너가 늦게 렌더링되어 페이지 콘텐츠를 아래로 밀어낼 때 layout shift가 발생합니다. 일부 동의 플랫폼은 페이지 리플로우를 유발하는 거대한 DOM 트리(200개 이상의 노드)를 주입합니다. 문서화된 한 사례에서는 동의 배너가 실제 콘텐츠 위에 렌더링되었기 때문에, 50%의 페이지 뷰에서 해당 배너가 LCP 요소였습니다.

더 스마트한 추적을 위한 전략

실제로 사용하는 항목 감사하기

태그 관리자를 열고 모든 단일 태그를 검토하십시오. 각 태그에 대해 '누가 이 데이터를 읽는가?', '마지막으로 확인한 시점은 언제인가?'를 질문해 보십시오. 아무도 대답할 수 없다면 제거하십시오. 저는 수개월 전에 종료된 캠페인의 A/B 테스트 도구 태그, 회사에서 더 이상 사용하지 않는 광고 플랫폼의 픽셀, 그리고 중복된 분석 구현(GTM을 통한 GA4와 하드코딩된 gtag.js 모두 존재)을 일상적으로 발견합니다.

비필수 스크립트 지연하기

모든 항목이 페이지 뷰 시점에 로드될 필요는 없습니다. 히트맵 스크립트가 기록을 시작하는 데 3초가 걸렸다고 해서 실망하는 사람은 아무도 없습니다. 분석 및 추적 태그를 Window Loaded 이벤트에서 실행하거나, 더 나은 방법으로는 사용자가 페이지와 상호 작용할 때까지 지연시키십시오. AnalyticsMania의 테스트에 따르면 페이지 로드 후 태그 실행을 1.5초 지연시켰을 때 Slow 3G 환경에서 6초를 단축했습니다.

// Load analytics only after first user interaction
const events = ['click', 'scroll', 'mousemove', 'touchstart'];
const loadAnalytics = () => {
    events.forEach(e => document.removeEventListener(e, loadAnalytics));
    // Load your analytics script here
    const script = document.createElement('script');
    script.src = 'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXX';
    document.head.appendChild(script);
};
events.forEach(e => document.addEventListener(e, loadAnalytics, {once: true}));

사용자 지정 이벤트에 Beacon API 사용하기

사용자 지정 분석 이벤트(양식 제출, 버튼 클릭, 스크롤 깊이)를 전송하는 경우 XMLHttpRequest 대신 navigator.sendBeacon()을 사용하십시오. Beacon API는 메인 스레드를 차단하지 않고 데이터를 비동기적으로 전송하며, 페이지 탐색 중에도 완료를 보장합니다. 이는 분석 호출을 트리거하는 상호 작용에서 INP를 낮게 유지하는 데 특히 중요합니다.

// Send analytics data without blocking the interaction
document.querySelector('.buy-button').addEventListener('click', (e) => {
    // Use sendBeacon - non-blocking, survives page navigation
    navigator.sendBeacon('/analytics', JSON.stringify({
        event: 'purchase_click',
        timestamp: Date.now()
    }));
});

서버 사이드 대안 고려하기

추적 JavaScript를 제거하는 가장 효과적인 방법은 아예 로드하지 않는 것입니다. Cloudflare Zaraz는 분석 실행을 에지(Edge)로 이동시켜, 클라이언트 사이드의 태그 관리자 스크립트를 경량화된 비콘으로 대체합니다. GTM 서버 사이드 컨테이너는 공급업체의 JavaScript가 브라우저에 도달하지 않고도 서버가 분석 제공업체에 데이터를 전달할 수 있게 해줍니다. 이러한 접근 방식은 설정하는 데 더 많은 노력이 필요하지만 성능에 미치는 영향은 거의 0에 가깝습니다.

더 단순한 요구 사항의 경우, Plausible(1 KB 미만) 또는 Umami(약 2 KB)와 같은 경량 대안을 사용하면 GA4의 134 KB 비용의 극히 일부만으로 트래픽 분석을 제공할 수 있습니다.

이상적인 형태

CoreDash에서 모니터링하는 사이트 전체를 보면, 서드파티 스크립트를 5개 미만으로 로드하는 페이지는 약 88%의 확률로 INP를 통과하는 반면, 15개 이상 로드하는 페이지는 64%에 불과합니다. LCP의 차이 역시 분명합니다. 경쟁하는 요청이 적다는 것은 브라우저가 방문자에게 실제로 중요한 요소의 우선순위를 높일 수 있다는 의미입니다.

모든 추적을 제거할 필요는 없습니다. 로드할 항목, 로드할 시점, 데이터의 실제 활용 여부에 대해 의도적으로 접근해야 합니다. 태그 관리자를 감사하는 것부터 시작하십시오. 필요하지 않은 것은 제거하십시오. 필요한 것은 지연시키십시오. 추적 스크립트가 실제 네트워크 환경 및 실제 사용자 행동과 어떻게 상호 작용하는지 실험실 테스트만으로는 전체적인 상황을 파악할 수 없으므로, Real User Monitoring을 사용하여 필드 데이터의 개선 사항을 확인하십시오.