광고 네트워크에 preconnect를 해야 할까요? LCP에 달려 있습니다

간단히 말해서: LCP에 달려 있습니다

저는 사이트를 감사할 때 항상 리소스 힌트 전략을 살펴봅니다. 때때로 클라이언트들은 광고 속도를 높이고 수익을 증가시키기를 바라며 광고 네트워크에 preconnect를 사용합니다. 이것이 도움이 될지 해가 될지는 전적으로 한 가지에 달려 있습니다: 여러분의 Largest Contentful Paint 이미지가 이미 제대로 최적화되어 있습니까?

2026년 3월 Arjen Karel이 마지막으로 검토함

LCP 이미지가 (JavaScript에 의해 주입되지 않고) HTML에 존재하며, 지연 로딩(lazy loaded)되지 않고, fetchpriority="high" 속성을 가지고 있다면, 브라우저는 다른 어떤 곳에 preconnect를 하더라도 해당 이미지를 우선순위에 둡니다. 이 경우 기본 광고 네트워크 출처(origin)에 preconnect를 하는 것은 안전하며, 실제로 몇 밀리초 더 빠르게 광고를 게재하여 수익을 창출할 수 있습니다.

하지만 LCP가 최적화되어 있지 않다면, 추가하는 모든 preconnect는 최악의 타이밍에 대역폭 및 CPU 사이클을 놓고 경쟁하게 됩니다. 저는 일일 페이지뷰가 5,000에서 1,500만에 달하는 사이트들에서 이러한 문제가 발생하는 것을 보았습니다.

preconnect가 실제로 하는 일

preconnect 힌트는 브라우저에게 외부 서버에서 파일이 실제로 필요해지기 전에 연결(DNS + TCP + TLS)을 미리 열어두라고 지시합니다. 마침내 파일이 요청되면 연결이 이미 예열(warm)되어 있으므로 즉시 다운로드가 시작됩니다. web.dev에 따르면, 이는 중요한 출처에 대해 100ms에서 500ms를 절약할 수 있습니다.

주의할 점: Chrome은 10초 이내에 사용되지 않은 preconnect는 모두 닫습니다. 연결이 사용되지 않으면 TCP + TLS 비용만 헛되이 지불한 셈이 됩니다.

현대의 광고 네트워크가 작동하는 방식

여러분은 스크립트를 포함시키고, 해당 스크립트는 경매(흔히 Prebid.js와 같은 헤더 비딩을 통해 여러 디맨드 파트너와 함께)를 실행하며, 낙찰된 광고는 들어본 적도 없는 서버에서 리소스를 로드합니다. 이 체인은 5개 이상의 도메인 깊이까지 들어갈 수 있습니다. 이것이 중요한 이유는 HTML 파싱 시점에 알지 못하는 도메인에는 preconnect를 할 수 없기 때문입니다.

광고 네트워크에 preconnect를 하는 것이 성능을 저하시키는 경우

LCP가 최적화되지 않은 경우, 광고 네트워크에 preconnect를 하면 상황이 더 악화됩니다. 가장 중요한 리소스(LCP 이미지, 스타일시트, 폰트)가 아직 다운로드되지 않은 시점에서 초기 연결들이 대역폭을 놓고 경쟁하기 때문입니다.

다음의 실제 사례를 살펴보겠습니다. 이 클라이언트는 최적화되지 않은 LCP를 가지고 있었고 여러 광고 도메인에 preconnect를 하고 있었습니다. 제가 광고 preconnect들을 제거한 후, 불과 3개월 만에 양호한(good) 페이지 수가 180만 개에서 624만 개로 증가했습니다.

preconnect들이 LCP 이미지로부터 대역폭을 훔쳐가고 있었던 것입니다. 경쟁을 제거하면 브라우저는 초기 네트워크 시간을 실제로 중요한 작업에 사용할 수 있습니다.

광고 네트워크에 preconnect를 하는 것이 타당한 경우

LCP가 이미 빠르다면, 메인 광고 스크립트 출처에 preconnect를 해도 괜찮습니다. 체크리스트는 다음과 같습니다:

1. LCP 이미지가 HTML에 존재해야 합니다 (JavaScript에 의해 주입되거나 CSS에서 로드되지 않음)
2. LCP 이미지가 지연 로딩(lazy loaded)되지 않아야 합니다
3. LCP 이미지가 fetchpriority="high" 속성을 가져야 합니다
4. LCP 이미지를 브라우저의 프리로드 스캐너가 발견할 수 있어야 합니다

이 네 가지 조건이 모두 충족되면 브라우저는 preconnect와 관계없이 가장 높은 우선순위로 LCP 이미지를 가져옵니다. 추가적인 TCP + TLS 핸드셰이크의 적은 대역폭 비용은 LCP에 영향을 주지 않습니다. 그리고 더 빠른 광고는 더 많은 노출, 더 높은 조회 가능성 점수, 그리고 더 많은 수익을 의미합니다.

CoreDash에서 모니터링하는 사이트들에 따르면, 단일 광고 네트워크 출처에 대한 preconnect는 연결 시간을 불과 몇 밀리초 단축시켜 줍니다. LCP 이미지가 이미 제대로 우선순위가 지정되어 있다면 LCP에 영향을 줄 만큼 큰 차이는 아닙니다. 하지만 그 몇 밀리초가 광고 채우기 비율(ad fill rates)에는 중요할 수 있습니다.

극도로 주의하세요

이것이 찾을 수 있는 모든 광고 도메인에 preconnect를 해도 된다는 백지 수표는 아닙니다. 규칙은 다음과 같습니다:

1. 단일 출처에만 preconnect 하세요: 기본 광고 스크립트 도메인이어야 합니다. 헤더 비딩의 15개 디맨드 파트너 도메인에 preconnect를 하지 마세요. 어느 곳이 경매에서 이길지 알 수 없습니다.
2. 스크립트가 이미 발견 가능한 상태가 아닐 때만 preconnect 하세요. 일반적인 <script async src="https://adnetwork.ext/script.js"> 태그로 광고 스크립트를 로드하는 경우, 브라우저의 프리로드 스캐너가 이미 이를 찾아냅니다. 그 위에 추가하는 preconnect는 아무런 이점도 제공하지 않습니다.
3. 캐시된 스크립트는 preconnect를 무의미하게 만듭니다. 광고 스크립트가 이미 브라우저 캐시에 있는 경우(광고가 많은 사이트의 재방문자에게 흔히 발생함), preconnect된 TCP + TLS 핸드셰이크는 사용되지 않고 순전히 오버헤드가 됩니다.
4. LCP를 먼저 고치세요. 아직 LCP 임계값을 통과하지 못했다면 광고 preconnect를 추가하지 마세요. LCP 이미지를 프리로드하고, fetchpriority="high"를 설정하며, 지연 로딩되지 않았는지 확인하세요. 그런 다음 광고 preconnect를 다시 고려하세요.

LCP가 제대로 최적화되었는지 확신할 수 없다면, preconnect를 추가하기 전에 CoreDash 또는 CrUX에서 필드 데이터를 확인하세요.

여전히 힌트를 제공하고 싶다면 dns-prefetch를 대신 사용하세요

광고 서버에 대한 초기 연결 힌트를 제공하고 싶지만 preconnect의 전체 대역폭 비용은 부담스럽다면, 대신 dns-prefetch를 사용하세요. 이는 DNS(20~120ms)만 확인하고 TCP 및 TLS는 완전히 건너뛰며 대역폭을 놓고 경쟁하는 유휴 연결(idle connection)을 생성하지 않습니다.

<link rel="dns-prefetch" href="//securepubads.g.doubleclick.net">
<link rel="dns-prefetch" href="//pagead2.googlesyndication.com">

이것은 더 안전한 절충안입니다: 중요한 렌더링 기간 동안의 대역폭 경합 위험 없이 DNS 조회 시간을 단축할 수 있습니다.

어떤 광고 네트워크들을 테스트했을까요?

다음은 제가 지난 한 해 동안 테스트한 모든 preconnect들입니다. 여러분의 광고 네트워크가 이 목록에 없다고 해서 preconnect를 해야 한다는 뜻은 아닙니다. 단지 제가 여러분을 위해 테스트하지 않았다는 의미일 뿐입니다. Real User Monitoring으로 A/B 테스트를 설정하고 여러분의 사이트에 가장 효과적인 것을 테스트해 보세요.

<link rel="preconnect" href="//securepubads.g.doubleclick.net">
<link rel="preconnect" href="//www.google.com">
<link rel="preconnect" href="//adservice.google.com">
<link rel="preconnect" href="//tpc.googlesyndication.com">
<link rel="preconnect" href="//pagead2.googlesyndication.com">
<link rel="preconnect" href="//www.gstatic.com">
<link rel="preconnect" href="https://s0.2mdn.net">
<link rel="preconnect" href="https://googleads.g.doubleclick.net">
<link rel="preconnect" href="https://www.googleadservices.com">
<link rel="preconnect" href="https://dis.criteo.com">
<link rel="preconnect" href="https://c1.adform.net">
<link rel="preconnect" href="https://snap.licdn.com">
<link rel="preconnect" href="https://visitor.omnitagjs.com">
<link rel="preconnect" href="https://secure.adnxs.com">
<link rel="preconnect" href="https://cdn.brandmetrics.com">
<link rel="preconnect" href="https://p.adsymptotic.com">
<link rel="preconnect" href="https://bidder.criteo.com">
<link rel="preconnect" href="https://gum.criteo.com">
<link rel="preconnect" href="https://sslwidget.criteo.com">
<link rel="preconnect" href="https://static.criteo.net">

이를 뒷받침하는 수치들

2025년 웹 연감(Web Almanac)에 따르면, 22%의 페이지가 preconnect 힌트를 사용하며 모바일 출처의 62%만이 LCP를 통과합니다. 이는 웹의 상당 부분이 타사 출처에 preconnect를 하면서, 정작 그 preconnect로 인해 악화될 수 있는 바로 그 지표에서는 실패하고 있음을 의미합니다.

동일한 데이터에 따르면 현재 모바일 페이지의 17.3%가 LCP 이미지에 fetchpriority="high"를 사용하고 있습니다. 여러분이 이 17.3%에 속한다면, 여러분의 LCP 이미지가 우선순위 경쟁에서 승리하므로 단일 광고 preconnect는 문제를 일으키지 않을 것입니다. 그렇지 않다면 거기서부터 시작하세요.