Core Web Vitals: 성능이 검색 노출에 미치는 실제 영향

프론트엔드 개발자가 알아야 할 SEO/GEO 다섯 번째 이야기, 우리가 가장 잘 아는 영역에서 SEO를 챙기는 방법

shushushu

2026년 06월 25일 · 0 분 소요

들어가며

이 시리즈를 쓰면서 "프론트엔드 개발자가 SEO를 왜 챙겨야 하는가"를 다양한 각도에서 다뤄왔어요. robots.txt 설정부터 헤딩 구조, 구조화 데이터까지. 근데 솔직히 말하면, 이번 편이 프론트엔드 개발자에게는 가장 자연스러운 주제일 거예요.

웹 성능 최적화.

이미지 최적화하고, 번들 사이즈 줄이고, 레이아웃 시프트 잡고 — 이미 하고 있는 일이잖아요. 근데 이 작업이 Lighthouse 점수를 올리는 것 이상으로, 검색 노출과 사용자 경험에 실질적인 영향을 미치고 있다는 걸 아는 것과 모르는 것은 다르거든요.

이번 편에서는 Core Web Vitals가 검색 노출에 실제로 어떤 영향을 미치는지, 그리고 4편에서 다뤘던 Google의 AI 가이드와 어떻게 연결되는지를 정리해볼게요.

Core Web Vitals — 세 가지 지표

Core Web Vitals는 Google이 사용자 경험을 측정하기 위해 정의한 세 가지 핵심 지표예요. 2024년 3월에 FID(First Input Delay)가 INP(Interaction to Next Paint)로 교체되면서 현재 구성은 이래요.

LCP (Largest Contentful Paint) — 로딩 속도

페이지에서 가장 큰 콘텐츠 요소(주로 히어로 이미지, 비디오, 큰 텍스트 블록)가 화면에 렌더링되기까지 걸리는 시간이에요.

Good: 2.5초 이하
Needs Improvement: 2.5초 ~ 4초
Poor: 4초 초과

2025 Web Almanac 기준으로 모바일 페이지의 62%만 Good 등급을 달성하고 있어서, 세 지표 중 가장 통과하기 어려운 항목이에요.

INP (Interaction to Next Paint) — 응답성

사용자의 인터랙션(클릭, 탭, 키보드 입력)에 페이지가 시각적으로 반응하기까지 걸리는 시간이에요. 이전의 FID가 첫 번째 인터랙션만 측정했다면, INP는 페이지 전체 라이프사이클 동안의 모든 인터랙션을 측정하고 그중 가장 느린 것을 보고해요.

Good: 200ms 이하
Needs Improvement: 200ms ~ 500ms
Poor: 500ms 초과

2025 Web Almanac 기준 모바일 페이지의 약 77%가 Good 등급을 달성하고 있어요. FID 시절에 문제없던 사이트가 INP에서는 실패하는 경우가 꽤 있어요. 첫 클릭은 빠른데 필터 패널이나 폼 제출이 800ms씩 걸리는 사이트가 전형적인 사례예요.

CLS (Cumulative Layout Shift) — 시각적 안정성

페이지 로딩 중에 콘텐츠가 예상치 못하게 밀려나는 정도를 수치화한 거예요.

Good: 0.1 이하
Needs Improvement: 0.1 ~ 0.25
Poor: 0.25 초과

세 지표 중 통과율이 가장 높아요 (모바일 페이지의 81%). 하지만 광고, 쿠키 배너, 웹폰트 로딩 같은 요소 때문에 의외의 곳에서 문제가 생기기도 해요.

CWV는 검색 순위에 얼마나 영향을 미치는가

보조 평가 신호로서의 CWV

이 부분을 정확히 이해하는 게 중요해요. Core Web Vitals는 Google의 랭킹 요소 중 하나이지만, 콘텐츠 관련성이나 백링크 같은 핵심 요소를 대체하지는 않아요. Google도 페이지 경험 신호가 콘텐츠 관련성을 대체하지 않는다고 설명하면서, 경쟁력이 비슷한 페이지 사이에서 추가적인 평가 요소로 작동할 수 있다고 말해요.

업계에서도 CWV를 순위를 결정하는 핵심 요소라기보다는, 비슷한 품질의 페이지 사이에서 우열을 가르는 보조 신호로 보는 견해가 많아요. 흔히 쓰는 "타이브레이커(tiebreaker)" 비유가 이 역할을 잘 보여줘요 — 비슷한 품질의 콘텐츠가 경쟁할 때, 성능이 좋은 페이지가 우위를 가져가는 거예요. (단, "타이브레이커"는 Google 공식 용어가 아니라 SEO 업계에서 흔히 쓰는 비유라는 점은 알아두세요.)

콘텐츠 관련성 + 권위성 (1순위)
    └── 비슷한 품질의 페이지들이 경쟁
        └── CWV가 타이브레이커로 작동
            └── 성능이 좋은 페이지가 우위

하지만 무시할 수 있는 수준은 아니에요

"보조 신호면 대수롭지 않은 거 아니야?"라고 생각할 수 있는데, 실제 비즈니스 임팩트를 보면 이야기가 달라요.

Vodafone은 LCP를 31% 개선한 뒤 판매가 8% 증가했다고 보고했어요(web.dev 케이스 스터디). Pinterest도 성능 개선 이후 검색 트래픽 증가를 보고한 바 있고요. 좀 더 일반적인 수치로는, 페이지 로드 시간이 1초에서 3초로 늘어나면 이탈 확률이 약 32% 증가한다는 Google의 분석이 잘 알려져 있어요.

특히 경쟁이 치열한 키워드에서는 CWV가 실질적인 차이를 만들어요. 같은 주제로 비슷한 품질의 콘텐츠를 가진 10개 사이트가 경쟁한다면, CWV를 통과한 사이트가 유리한 위치를 가져가거든요.

프론트엔드 개발자를 위한 CWV 최적화 포인트

이미 알고 있는 내용이 많겠지만, SEO 맥락에서 우선순위를 다시 정리해볼게요.

LCP 개선 — 가장 임팩트가 큰 항목

LCP는 SEO와 비즈니스 매트릭 모두에서 가장 직접적인 영향을 미치는 지표예요.

최적화에 들어가기 전에, LCP가 어디서 시간을 잡아먹는지부터 분해해보면 진단이 쉬워져요. LCP는 크게 네 구간으로 나뉘어요.

TTFB — 서버가 첫 바이트를 응답하기까지의 시간
리소스 로드 지연(Resource Load Delay) — LCP 리소스를 발견해서 요청을 시작하기까지 걸린 시간
리소스 로드 시간(Resource Load Time) — LCP 리소스를 실제로 내려받는 데 걸린 시간
요소 렌더 지연(Element Render Delay) — 다 받아놓고도 화면에 그려지기까지 걸린 시간

내 LCP의 병목이 이 중 어디인지 알면(Chrome DevTools Performance 패널에서 구간별로 확인 가능), 아래 조치 중 무엇을 우선할지 정할 수 있어요. 예를 들어 로드 지연이 크면 프리로드·fetchpriority가, TTFB가 크면 서버·CDN 쪽이 답이에요.

LCP 이미지에는 lazy loading을 걸지 마세요. 히어로 이미지처럼 뷰포트에 바로 보이는 요소에 loading="lazy"를 걸면 오히려 LCP가 느려져요. LCP 요소는 fetchpriority="high"로 우선 로딩해야 해요.

<!-- LCP 이미지 — lazy loading 사용 금지 -->
<img
  src="/hero.webp"
  alt="히어로 이미지"
  fetchpriority="high"
  width="1200"
  height="600"
/>

<!-- 스크롤 아래 이미지 — lazy loading 적용 -->
<img
  src="/below-fold.webp"
  alt="하단 이미지"
  loading="lazy"
  width="800"
  height="400"
/>

이미지 포맷은 WebP 또는 AVIF로. 같은 품질에서 JPEG 대비 25~50% 용량을 줄일 수 있어요. Next.js를 쓰고 있다면 next/image 컴포넌트가 자동으로 WebP 변환을 해주고요.

크리티컬 리소스를 프리로드하세요. LCP 이미지, 중요한 폰트, 크리티컬 CSS는 <link rel="preload">로 브라우저에게 우선순위를 알려줘야 해요.

TTFB(서버 응답 시간)를 800ms 이내로. 서버가 느리면 아무리 프론트를 최적화해도 LCP가 안 나와요. CDN 활용, 서버 사이드 캐싱, Brotli 압축이 기본이에요.

INP 개선 — 가장 잡기 어려운 항목

INP는 FID보다 훨씬 엄격해서, 이전에 문제없던 사이트도 실패할 수 있어요.

긴 JavaScript 태스크를 분할하세요. 50ms 이상의 Long Task는 메인 스레드를 차단해서 INP를 악화시켜요. setTimeout, requestIdleCallback, 또는 scheduler.postTask API로 태스크를 분할할 수 있어요.

서드파티 스크립트를 점검하세요. 채팅 위젯, 개인화 엔진, 태그 매니저 같은 서드파티 스크립트가 INP의 주범인 경우가 많아요. 페이지 초기 로드 이후에 로딩하도록 지연시키는 것만으로도 크게 개선되는 경우가 있어요.

DOM 크기를 줄이세요. 과도하게 큰 DOM은 렌더링과 인터랙션 성능 모두에 영향을 줄 수 있어요. Lighthouse도 DOM 크기를 점검 대상으로 보고, 총 노드 약 1,500개·최대 깊이 32레벨·부모 노드당 자식 60개를 경고 기준으로 삼아요. (Google의 공식 랭킹 권장사항이 아니라 Lighthouse 감사 기준이라는 점은 참고하세요.)

bfcache(뒤로/앞으로 가기 캐시)를 깨뜨리지 마세요. 사용자가 뒤로/앞으로 가기를 누를 때 페이지를 통째로 메모리에서 복원해주는 캐시예요. 이게 작동하면 재방문 내비게이션이 사실상 즉시 이뤄져 사용자 체감 성능이 크게 향상돼요. 그런데 unload 이벤트 핸들러나 Cache-Control: no-store 같은 설정이 있으면 bfcache가 비활성화돼요. unload 대신 pagehide/pageshow를 쓰고, DevTools의 Application 패널에서 bfcache 적격 여부를 점검하세요.

CLS 개선 — 가장 기본적이지만 놓치기 쉬운 항목

이미지와 비디오에 width/height를 명시하세요. 이게 CLS 개선의 가장 임팩트 있는 단일 조치예요. 크기가 지정되지 않은 이미지가 로딩되면서 아래 콘텐츠를 밀어내는 게 CLS의 가장 흔한 원인이에요.

<!-- CLS 유발 — 크기 미지정 -->
<img src="/product.webp" alt="상품 이미지" />

<!-- CLS 방지 — 크기 명시 -->
<img src="/product.webp" alt="상품 이미지" width="400" height="300" />

웹폰트 로딩 전략을 세우세요. 폰트가 교체되면서 텍스트가 리플로우되는 것도 CLS의 원인이에요. font-display: swap 또는 font-display: optional을 설정하고, 가능하면 폰트를 셀프 호스팅해서 로딩 시간을 줄이세요.

동적으로 삽입되는 요소에 공간을 예약하세요. 광고 슬롯, 쿠키 배너, 알림 바 같은 요소가 로딩 후 삽입되면 레이아웃이 밀려요. CSS로 미리 공간을 잡아두면 예방할 수 있어요.

측정은 필드 데이터로

CWV 최적화에서 자주 놓치는 포인트가 하나 있어요. Google은 Lighthouse 같은 lab 데이터가 아니라, 실제 사용자의 필드 데이터(CrUX)로 CWV를 평가해요.

개발 환경의 고성능 맥북에서 Lighthouse 점수가 100점이어도, 실제 사용자들의 3G 네트워크 + 저가 안드로이드 폰에서 측정된 필드 데이터가 나쁘면 Google은 그걸 기준으로 봐요. 75번째 백분위수(p75)가 기준이라서, 전체 방문의 75%가 Good 기준을 충족해야 해요.

측정 도구

Google Search Console — "환경" > "Core Web Vitals" 탭에서 필드 데이터 기반 상태를 확인할 수 있어요. Google이 실제로 사용하는 데이터예요.
PageSpeed Insights — 필드 데이터(CrUX)와 lab 데이터를 모두 보여줘요. 개선 포인트 진단에 유용해요.
Chrome DevTools — Performance 패널 — 페이지를 사용하면서 LCP·INP·CLS를 실시간으로 보고, LCP 구간 분해와 INP를 유발한 인터랙션까지 추적할 수 있어요. (기존 Web Vitals 확장 프로그램은 2025년 1월 지원이 종료되고 기능이 DevTools로 통합됐어요.)

SEO 관점에서의 판단은 항상 Search Console의 필드 데이터를 기준으로 하세요.

CWV와 AI 검색의 관계

4편에서 다뤘던 Google의 AI 가이드에서도 이 부분을 짚고 있어요.

> "사이트에 방문한 사용자에게 좋은 페이지 경험(good page experience)을 제공하세요. 여기에는 모든 디바이스에서 사이트가 잘 표시되고, 지연 시간이 적으며, 메인 콘텐츠를 다른 요소들과 쉽게 구분할 수 있는 것이 포함됩니다."

Google의 AI 기능(AI Overviews, AI Mode)은 기존 검색 인덱스를 기반으로 작동해요. 즉, 검색 인덱스에서 높은 평가를 받는 페이지가 AI 응답에서도 인용될 가능성이 높아요. CWV가 직접적으로 AI 인용을 결정하지는 않지만, SEO 품질의 일부로서 간접적으로 영향을 미치는 구조예요.

이건 이 시리즈의 핵심 메시지와 같아요 — GEO는 SEO의 확장이에요. SEO의 기본기(CWV 포함)가 탄탄해야 AI 검색에서도 가능성이 생겨요.

실제로 GEONIQ 리포트에서 다양한 업종의 사이트를 분석할 때도, 성능 지표가 좋지 않은 페이지는 콘텐츠 품질과 무관하게 전반적인 평가가 낮아지는 경향이 관찰되기도 했어요. 성능은 단순한 속도 이슈가 아니라, 페이지의 전반적인 관리 품질을 나타내는 간접 신호로 작동하는 거예요.

정리 — CWV 최적화 우선순위

지표	기준	통과율 (모바일)	최우선 조치
LCP	≤ 2.5초	62%	LCP 이미지 fetchpriority="high", WebP/AVIF, 프리로드, TTFB 800ms 이내
INP	≤ 200ms	77%	Long Task 분할, 서드파티 스크립트 지연 로딩, DOM 크기 축소
CLS	≤ 0.1	81%	이미지/비디오 width·height 명시, font-display 설정, 동적 요소 공간 예약

마치며

CWV 최적화는 프론트엔드 개발자가 가장 잘 할 수 있는 SEO 작업이에요. 이미 하고 있는 성능 최적화가 곧 검색 노출의 기반이 되고, 그 기반이 AI 검색에서의 가능성으로 이어져요.

다만 한 가지 명심할 건, CWV만으로 검색 순위가 크게 오르지는 않는다는 거예요. SEO 업계에서는 흔히 "타이브레이커"에 비유하기도 해요 — 콘텐츠 품질과 기술적 SEO가 갖춰진 상태에서 CWV가 경쟁에서의 우위를 만들어주는 거예요. 순서가 중요해요.

다음 편에서는 이 시리즈의 마지막 주제를 다뤄볼 예정이에요. AI 크롤러 시대의 접근 제어 — GPTBot, ClaudeBot, PerplexityBot을 어떻게 다룰 것인가, 그리고 Google이 말하는 "Agentic Experiences"까지 포함해서 시리즈를 마무리할게요.