코어 웹 바이탈 Core Web Vitals

코어 웹 바이탈(Core Web Vitals)은 구글이 실제 사용자의 페이지 경험을 측정하기 위해 정의한 세 가지 핵심 성능 지표(LCP·INP·CLS)입니다. 로딩 속도, 상호작용 반응성, 시각적 안정성을 각각 수치로 나타내며, 구글 랭킹 시스템이 사용하는 페이지 경험 신호입니다. 판정 기준은 랩 테스트 점수가 아니라 실사용자 데이터(CrUX)의 75번째 백분위수입니다.

테크니컬 2026. 7. 11 업데이트 By 박혜정

세 가지 지표와 기준값

코어 웹 바이탈은 구글이 실사용자의 페이지 경험을 로딩·반응성·안정성 세 축으로 수치로 나타낸 지표입니다. 로딩 성능은 LCP, 상호작용 반응성은 INP, 시각적 안정성은 CLS가 맡습니다. INP는 2024년 3월 12일부터 기존 FID(First Input Delay)를 대신해 정식 지표가 되었고, FID는 같은 날 서치 콘솔에서 빠졌습니다 web.dev 공지.

지표	측정 대상	좋음 기준
LCP (Largest Contentful Paint)	화면에서 가장 큰 콘텐츠(주로 히어로 이미지·헤드라인)가 그려지는 시간	2.5초 이하
INP (Interaction to Next Paint)	클릭·탭·키 입력 후 다음 화면 갱신까지의 지연	200ms 이하
CLS (Cumulative Layout Shift)	로딩 중 레이아웃이 예고 없이 밀려나는 정도	0.1 이하

판정 기준은 랩 점수가 아니라 실사용자 데이터입니다. web.dev는 "모바일과 데스크톱 기기로 구분한 페이지 로드의 75번째 백분위수를 측정하는 것이 좋은 기준"이라고 안내합니다 web.dev. 즉 방문의 75% 이상이 세 지표 모두에서 기준값 안에 들어와야 '좋음' 판정이며, 모바일과 데스크톱은 따로 평가됩니다.

검색 순위와의 관계 - 공식과 실측이 갈리는 지점

코어 웹 바이탈이 순위를 얼마나 좌우하는지는 구글 공식 문서와 업계 실측이 가장 크게 갈리는 대목입니다. 결론부터 보면, 순위 신호인 것은 맞지만 콘텐츠 관련성을 이기지는 못합니다.

구글 공식 입장	페이지 경험은 랭킹 시스템이 참고하는 신호이지만, 콘텐츠 관련성이 우선이며 엇비슷한 상황을 가르는 타이브레이커 성격에 가깝습니다. Google 공식
전문가 실측 결과	520만 페이지 규모의 데이터를 다룬 Ahrefs 조사에서, 저자는 순위 업데이트 시점과 다른 변경들이 겹쳐 코어 웹 바이탈과 순위의 상관을 결론지을 방법이 없다고 밝혔습니다(2022). Ahrefs 실측

차이가 나는 이유는 측정하는 대상이 다르기 때문입니다. 구글은 '신호로 쓴다'는 정책을 말하고, 실측은 '실제 순위 변동에서 그 신호가 잘 드러나지 않는다'를 관찰합니다. 구글 자신도 페이지 경험 문서에서 "SEO 만을 이유로 완벽한 점수를 노리는 것은 시간을 가장 잘 쓰는 방법이 아닐 수 있다"고 적었습니다 Google 공식. 실무에선 이 지표만 손봐 순위 급등을 기대하기보다, SEO 전체 그림 안에서 기본기로 다루는 편이 두 입장 모두에 들어맞습니다.

순위 밖의 효용 - 속도와 전환율

순위 비중이 크지 않아도 이 지표를 진지하게 다루는 더 확실한 근거는 전환율입니다. 구글이 의뢰하고 딜로이트·55가 수행한 「Milliseconds Make Millions」 연구는 유럽·미국 37개 브랜드 사이트의 3천만 건 이상 세션을 분석했습니다. 모바일 속도가 0.1초 개선되자 리테일 전환율이 8.4% 늘고 리테일 구매액도 9.2% 증가했습니다(2020) Deloitte 실측. 순위가 같아도 느린 사이트는 유입 이후 구간에서 방문자를 잃는다는 뜻입니다.

랩 데이터 vs 필드 데이터 - 점수의 착시

PageSpeed Insights 화면은 사실 두 개의 리포트입니다. 구글 문서에 따르면 상단 '실제 사용자 환경 평가'는 CrUX(Chrome User Experience Report)가 지난 28일 동안 모은 필드 데이터이고, 하단 0~100점 성능 점수는 Lighthouse가 시뮬레이션한 랩 데이터입니다 PageSpeed 문서. 두 값은 측정 조건이 달라 서로 어긋날 수 있습니다.

특히 INP는 랩 테스트로 온전히 잡히지 않습니다. web.dev는 "일부 랩 도구는 상호작용 없이 페이지 로딩만 관찰하므로 INP를 보고하지 못한다"고 설명합니다 web.dev. 사이트 전체의 필드 데이터 통과 상황은 구글 서치 콘솔의 코어 웹 바이탈 보고서에서 확인하며, 이 데이터 역시 CrUX에서 오고 모바일/데스크톱이 따로 표시됩니다 GSC 고객센터.

실무 체크포인트

아래 항목은 각각 web.dev의 지표별 공식 최적화 가이드를 바탕으로 합니다.

LCP - web.dev는 "LCP 이미지는 절대 lazy loading 하지 말라"고 명시하며, LCP 요소로 예상되는 이미지에 fetchpriority="high" 를 지정하고 렌더링을 차단하는 CSS/JS를 줄이라고 권고합니다 web.dev.
CLS - 이미지·비디오에 width/height(또는 CSS aspect-ratio)로 공간을 미리 확보하고, 늦게 로드되는 광고·임베드에는 min-height 로 자리를 예약하라는 것이 web.dev 권고입니다 web.dev.
INP - web.dev는 "이벤트 콜백에서는 가능한 한 적은 일을 하라"며 긴 작업을 잘게 나누고 다음 프레임의 시각 업데이트에 필요한 로직만 먼저 실행하도록 권고합니다 web.dev.

<!-- LCP 이미지: 크기 선언(CLS) + 우선 로딩(LCP) - web.dev 권고 -->
<img src="hero.webp" width="1200" height="800"
     fetchpriority="high" decoding="async" alt="메인 비주얼">

<!-- 핵심 웹폰트 조기 로드: 폰트 교체로 인한 레이아웃 이동 완화 -->
<link rel="preload" href="/fonts/pretendard-sub.woff2"
      as="font" type="font/woff2" crossorigin>

자주 하는 실수

Lighthouse 점수만 보고 "통과"로 판단 - 판정에 쓰이는 것은 CrUX 필드 데이터입니다. 이 데이터는 지난 28일 수집 기간을 반영하므로, 개선을 배포해도 수치는 천천히 움직입니다 PageSpeed 문서.
최적화 플러그인이 LCP 이미지까지 lazy loading 처리 - web.dev는 LCP 이미지의 lazy loading이 "항상 불필요한 리소스 로드 지연을 만들어 LCP에 부정적"이라고 명시합니다. 첫 화면 이미지는 반드시 제외해야 합니다 web.dev.
데스크톱만 측정 - web.dev와 서치 콘솔 문서 모두 모바일과 데스크톱을 따로 나눠 평가한다고 안내합니다. 한쪽만 통과해서는 전체 통과가 아닙니다.
성능 지표를 노출 문제와 혼동 - 페이지가 검색에 아예 나오지 않는 문제라면 크롤링과 색인 영역에서 원인을 찾아야 합니다.