Core Web Vitals 평가 실패? LCP, INP, CLS를 하나씩 고치는 법

SEOgrinder 편집팀 · 게시일 2026년 11월 4일 · 읽는 시간 약 11분

핵심 답변: Core Web Vitals(코어 웹 바이탈) 평가에 실패했다는 것은 실제 방문자 기준으로 세 지표 중 하나 이상이 기준에 못 미친다는 뜻입니다. LCP(로딩)는 2.5초 이하, INP(반응성)는 200밀리초 이하, CLS(시각적 안정성)는 0.1 이하여야 하며, 각각 75번째 백분위수 기준입니다. 기준에 못 미치는 지표는 실험실 점수가 아니라 실제 방문자의 필드 데이터에서 찾고, 그 하나부터 고치세요. Google은 순위 시스템이 Core Web Vitals를 사용한다고 말하지만, 좋은 값이 상위 노출을 보장하지는 않습니다.

Core Web Vitals 평가 실패는 무슨 뜻인가요?

Core Web Vitals는 Google의 Web Vitals 이니셔티브 중 모든 웹 페이지에 적용되는 부분입니다. web.dev는 사용자 경험의 각 측면에 하나씩 해당하는 세 지표를 제시합니다.

지표	무엇을 측정하나	좋은 값
LCP, Largest Contentful Paint	로딩: 보이는 영역에서 가장 큰 이미지, 텍스트 블록, 동영상이 나타나는 시점	2.5초 이하
INP, Interaction to Next Paint	반응성: 클릭, 탭, 키 입력에 페이지가 눈에 띄게 반응하는 속도	200밀리초 이하
CLS, Cumulative Layout Shift	시각적 안정성: 페이지를 쓰는 동안 보이는 콘텐츠가 얼마나 튀는가	0.1 이하

값은 페이지 로드의 75번째 백분위수에서, 모바일과 데스크톱을 따로 판정합니다. 쉽게 말해 방문 4번 중 3번은 값이 좋아야 하고, 모바일과 데스크톱이 각자 별도의 판정을 받습니다. web.dev는 세 지표 모두 75번째 백분위수에서 목표를 충족하면 도구가 그 페이지를 통과로 보라고 안내합니다. 따라서 빨간 지표가 하나만 있어도 통과하지 못합니다.

경계값에는 사소한 차이가 있습니다. web.dev는 INP와 CLS에 대해 “이하”라고 쓰는 반면, Google의 검색 문서는 “less than 200 milliseconds”와 “less than 0.1”, 즉 “미만”이라고 씁니다. 기준선보다 확실히 낮게 목표를 잡으면 이 차이는 문제가 되지 않습니다.

알아 둘 변화가 하나 있습니다. web.dev의 발표에 따르면 2024년 3월에 INP가 First Input Delay(FID)를 대신해 Core Web Vitals가 되었습니다. 아직도 FID를 나열하는 가이드는 오래된 것입니다. 이 글에 나온 모든 문서는 2026년 11월 4일에 읽었고, web.dev의 개요는 2024년 10월 31일에 마지막으로 업데이트되었습니다.

Core Web Vitals는 Google 순위에 영향을 주나요?

Google에 따르면 그렇지만, 가중치는 밝히지 않습니다. Google의 페이지 경험 문서는 이렇게 말합니다. “Core Web Vitals are used by our ranking systems.” Google은 검색에서 성공하려면 좋은 값을 권장하고, 페이지 경험을 가늠하는 단일 신호는 없다고 덧붙입니다.

같은 문서는 한계도 똑같이 분명하게 적습니다. Search Console의 Core Web Vitals 보고서나 외부 도구에서 결과가 좋다고 해서 “doesn't guarantee that your pages will rank at the top of Google Search results”, 즉 페이지가 Google 검색 결과 맨 위에 오른다는 보장은 없습니다. 또한 SEO만을 위해 완벽한 점수를 쫓는 것은 시간을 쓰기에 최선이 아닐 수 있다고도 적혀 있습니다. 페이지 경험이 나쁘더라도 Google은 언제나 가장 관련성 높은 콘텐츠를 보여 주려 합니다.

Google이 지표별 비중을 공개하지 않으므로 우리도 어떤 숫자도 말하지 않습니다. 우리의 해석이며 Google이 한 말이 아닙니다. 기준값은 방문자를 위한 품질 기준선으로 보고, 세 지표를 모두 ‘좋음’으로 만든 다음 시간을 다시 콘텐츠에 쓰세요. Google의 핵심 순위 시스템은 대체로 콘텐츠를 페이지 단위로 평가하므로, 홈페이지만이 아니라 중요한 페이지 유형마다 점검하세요.

실험실 데이터와 필드 데이터 중 무엇이 기준인가요?

평가는 필드 데이터, 즉 실제 방문에서 얻은 측정값을 바탕으로 합니다. Google의 Chrome User Experience Report(CrUX)가 실제 Chrome 사용자에게서 이 값을 모으고, PageSpeed Insights와 Search Console의 Core Web Vitals 보고서가 이를 보여 줍니다. web.dev에 따르면 CrUX 보고서는 28일 기간을 다룹니다.

실험실 데이터는 통제된 환경에서 페이지를 한 번 불러와 얻습니다. 기기 하나, 네트워크 하나, 위치 하나입니다. 원인을 찾고 배포 전에 수정을 테스트하기에 이상적이지만, LCP 가이드는 “lab tests alone may not be entirely representative”, 즉 실험실 테스트만으로는 완전히 대표적이지 않을 수 있다고 주의를 줍니다. 둘이 어긋나면 LCP 가이드는 실제 사용자 데이터에 먼저 집중하라고 말합니다. 둘이 다른 데에는 타당한 이유가 있습니다.

LCP 요소가 다를 수 있습니다. 실험실 실행은 늘 같은 요소를 찾습니다. 실제 방문자는 다른 화면 크기, 로그인 후 콘텐츠, A/B 테스트를 겪습니다.
INP에는 실제 사람이 필요합니다. Lighthouse를 비롯한 실험실 도구는 아무도 클릭하지 않은 채 페이지를 불러오므로 INP를 측정할 수 없습니다. Total Blocking Time(TBT)이 실험실에서 이를 대신하는 지표이며, TBT를 개선하면 INP도 좋아질 수 있습니다.
CLS는 로딩이 끝난 뒤에도 계속 집계됩니다. 실험실 실행은 대개 로딩 자체만 봅니다. 현장에서는 방문자가 스크롤하는 동안 나타나는 콘텐츠도 레이아웃을 밀어낼 수 있습니다.
캐시는 실제 방문자에게 유리합니다. 실험실 테스트는 보통 캐시가 빈 상태에서 시작하지만, 다시 방문한 사용자와 뒤로 가기/앞으로 가기 캐시(bfcache)는 페이지를 더 빨리 불러옵니다.

수치를 읽는 방법은 네 단계입니다.

PageSpeed Insights에서 내 주소를 실행합니다. “Discover what your real users are experiencing” 구역(영어 화면 기준 이름)에 필드 데이터가, “Diagnose performance issues” 구역에 실험실 실행 결과가 있습니다.
무엇을 보고 있는지 확인합니다. 모바일과 데스크톱, 그리고 단일 URL과 사이트 전체(origin)를 번갈아 봅니다. URL의 데이터가 너무 적으면 PageSpeed Insights는 대신 origin 데이터를 보여 줍니다.
75번째 백분위수에서 기준선을 넘은 지표를 찾습니다. 그것이 기준에 못 미치는 지표입니다. 트래픽이 너무 적으면 필드 데이터가 없습니다. 그럴 때는 실험실 값을 쓰고, web.dev의 작은 web-vitals 라이브러리로 내 방문자를 직접 측정하세요.
그 지표의 실험실 진단을 열어 원인을 확인하고, 그 한 가지부터 고칩니다.

LCP 개선: 가장 큰 요소가 너무 늦게 나타날 때

LCP는 보이는 영역에서 가장 큰 이미지, 텍스트 블록, 동영상이 렌더링되는 시점을 보고합니다. web.dev의 LCP 가이드는 이 시간을 합쳐서 LCP가 되는 네 부분으로 나눕니다. 서버 응답(TTFB), 브라우저가 LCP 리소스를 불러오기 시작하기까지의 지연, 그 리소스를 불러오는 데 걸리는 시간, 요소가 렌더링되기까지의 지연입니다. 무엇이든 바꾸기 전에 가장 큰 부분부터 찾으세요. 한 부분을 줄이면 시간이 다른 부분으로 옮겨 갈 뿐일 수 있기 때문입니다. 스크립트가 로드될 때까지 요소가 숨겨져 있다면 이미지를 더 압축해도 도움이 되지 않습니다.

Chrome 팀의 가장 효과적인 해결책 목록에는 다음 항목이 들어 있습니다.

LCP 이미지를 쉽게 찾을 수 있게 하고 우선순위를 주세요. JavaScript가 필요한 data-src가 아니라, src나 srcset을 쓴 일반 <img>를 쓰세요. 브라우저에서만 페이지를 조립하기보다 서버 측 렌더링을 선호하세요. 이 이미지 하나에는 fetchpriority="high"를 추가하고 loading="lazy"를 제거하세요.
서버 응답을 줄이세요. 콘텐츠를 방문자와 가까운 곳에서 제공하고 캐시하세요. 보통은 CDN을 씁니다.

같은 태그 하나가 LCP를 해결하고, 크기 지정을 통해 CLS도 해결합니다.

<!-- 메인 이미지: HTML 안에, 높은 우선순위, lazy 아님, 크기 지정 -->
<img src="/img/hero.webp" width="1200" height="630" alt="간단한 설명" fetchpriority="high">

<!-- 페이지 아래쪽 이미지: 여기에는 lazy loading이 괜찮습니다 -->
<img src="/img/team.webp" width="600" height="400" alt="간단한 설명" loading="lazy">

INP 개선: 페이지가 너무 느리게 반응할 때

INP는 방문 중의 모든 클릭, 탭, 키 입력을 관찰하고 대략 가장 느린 것을 보고합니다(상호작용이 아주 많은 페이지에서는 이상치를 제외합니다). 마우스를 올리는 것과 스크롤은 포함되지 않습니다. INP 가이드에 따르면 모든 상호작용은 세 부분으로 이루어집니다. 입력 지연, 이벤트 핸들러가 실행되는 시간, 다음 프레임이 표시되기까지의 지연입니다. 흔한 원인은 JavaScript가 메인 스레드를 붙잡고 있는 것입니다. Chrome 팀이 꼽는 주요 해결책은 다음과 같습니다.

긴 작업을 쪼개세요. 50밀리초를 넘는 작업은 메인 스레드를 막습니다. 제어권을 자주 돌려주세요. 브라우저가 지원하면 scheduler.yield(), 예전 방식으로는 setTimeout을 씁니다.
JavaScript를 덜 보내세요. Chrome DevTools의 커버리지 도구로 쓰이지 않는 코드를 찾고, 처음에는 필요 없는 코드는 분할하고, 태그 관리자에서 오래된 태그를 정리하세요.
큰 렌더링 업데이트를 피하세요. DOM을 작게 유지하고, 강제 레이아웃을 피하고, 화면 밖 콘텐츠에는 CSS containment를 쓰세요.

CLS 개선: 레이아웃이 튈 때

CLS에는 단위가 없습니다. 보이는 콘텐츠가 얼마나 움직였는지와 얼마나 멀리 움직였는지를 합친 값입니다. 현장에서는 방문 전체에 걸쳐 집계하지만, 사용자 상호작용 후 500밀리초 이내에 일어난 이동은 제외합니다. web.dev의 CLS 가이드는 흔한 원인을 나열합니다. 크기가 없는 이미지, 광고, 크기가 없는 임베드와 iframe, 동적으로 삽입되는 콘텐츠, 웹 폰트입니다. 도움이 되는 방법은 다음과 같습니다.

공간을 미리 확보하세요. 이미지와 동영상에 width와 height를 주거나 CSS aspect-ratio 속성을 쓰세요. 크기를 알 수 없는 콘텐츠에는 기본값 0보다 적당한 min-height가 낫습니다.
transform으로 애니메이션하세요. top, left, margin을 애니메이션하면 레이아웃이 밀립니다. 미끄러지듯 들어오는 쿠키 배너가 대표적인 경우입니다.
뒤로 가기/앞으로 가기 캐시가 작동하게 하세요. 이 캐시는 완전히 렌더링된 페이지를 복원합니다. 흔한 방해 요인은 no-store 캐시 지시어와 unload 이벤트 리스너입니다.
웹 폰트를 관리하세요. font-display: optional, size-adjust로 맞춘 대체 글꼴, 중요한 글꼴의 사전 로드(preload)는 모두 글꼴 때문에 생기는 이동을 줄여 줍니다.

SEOgrinder는 Core Web Vitals를 어떻게 점검하나요?

SEOgrinder는 우리의 도구이며, 우리가 만듭니다. SEOgrinder에 공개 주소를 입력하면 속도 수치는 Google PageSpeed Insights에서 가져오며, 모바일과 데스크톱을 모두 봅니다. 「Core Web Vitals」 카드는 LCP와 CLS를 Lighthouse 실험실 실행에서, INP를 실제 방문자에게서 보여 주고, 별도의 칸에는 최근 28일의 실제 사용자 데이터가 나옵니다. Google이 그 페이지에 대한 데이터를 충분히 갖고 있지 않으면 리포트는 추측하지 않고 그 사실을 알려 줍니다. 「모바일에서 실제 방문자는 콘텐츠가 뜰 때까지 … 기다립니다」 같은 할 일은 지표, 값, 해결책을 밝혀 줍니다. LCP에 반영되는 느린 서버 응답은 별도의 할 일로 나옵니다.

한계도 있습니다. SEOgrinder는 Google의 수치를 읽을 뿐 내가 직접 하는 실제 사용자 모니터링을 대체하지 않습니다. 순위는 측정하지 않습니다. 속도 측정에 대한 Google의 일일 할당량이 소진되면 리포트에는 그 부분이 빠집니다.

자주 하는 실수

실험실 점수만 믿는 것. 실험실 점수는 INP를 측정할 수 없고, 방문자가 겪는 것과 다르게 보일 수 있습니다. 실제 방문자의 값부터 시작하세요.
기기 하나만 확인하는 것. 모바일과 데스크톱은 따로 평가됩니다.
메인 이미지를 lazy loading하는 것. LCP 이미지에 loading="lazy"를 쓰면 지연이 늘어납니다.
이미지 크기를 빼먹는 것. width와 height가 없으면 브라우저가 공간을 확보할 수 없습니다.
LCP의 엉뚱한 부분을 고치는 것. 이미지는 네 부분으로 나눈 결과에서 로딩 시간이 문제로 드러난 뒤에 압축하세요.
결과가 바로 나오기를 기대하는 것. 필드 데이터는 28일을 다루므로 서서히 바뀝니다. 수정 직후에는 실험실 실행을, 이후 몇 주 동안은 실제 방문자의 수치를 확인하세요.

자주 묻는 질문

Core Web Vitals에서 좋은 점수는 얼마인가요?

하나의 점수는 없습니다. 75번째 백분위수에서 LCP가 2.5초 이하, INP가 200밀리초 이하, CLS가 0.1 이하이면 페이지가 통과합니다. Lighthouse에서 보았을 수 있는 0에서 100 사이의 숫자는 실험실 수치이며 다른 것입니다.

PageSpeed Insights에 내 사이트의 실제 사용자 데이터가 나오지 않는 이유는 무엇인가요?

대개는 방문이 너무 적어서 CrUX가 보고할 수 없기 때문입니다. 이럴 때 web.dev는 실제 방문자를 직접 측정하는 방법을 추가하라고 제안합니다. 그때까지는 실험실 값을 기준으로 작업하세요.

완벽한 점수가 필요한가요?

아니요. 목표는 통과입니다. Google도 SEO만을 위해 완벽한 점수를 쫓는 것은 시간을 쓰기에 최선이 아닐 수 있다고 말합니다.

다음 단계

가장 중요한 페이지를 SEOgrinder로 검사하고, 「Core Web Vitals」 카드를 열어 실제 방문자의 값부터 보세요. 기준에 못 미치는 지표 하나를 고친 다음 다시 확인을 누르고 실험실 값을 읽으세요. 더 넓은 그림은 SEO 체크리스트에서 볼 수 있습니다.