Core Web Vitals 완벽 정리, INP·LCP·CLS 실무 개선법

Core Web Vitals란 무엇인가

Core Web Vitals(코어 웹 바이탈)는 구글이 정의한 '사용자 경험 품질'을 수치로 나타낸 지표입니다. 사이트가 얼마나 빨리 보이는지, 클릭이나 입력에 얼마나 빠르게 반응하는지, 화면을 읽는 도중에 갑자기 밀리지 않는지를 측정합니다. 한마디로 '방문자가 페이지를 쓰면서 느끼는 답답함'을 객관적인 숫자로 바꾼 것이라고 보면 됩니다.

구글은 이 지표를 '페이지 경험(Page Experience)' 신호의 핵심으로 사용합니다. 다만 오해하면 안 되는 점은, 점수가 좋다고 해서 순위가 곧바로 오르는 것은 아니라는 것입니다. Core Web Vitals는 콘텐츠 수준이 비슷할 때 차이를 가르는 보조 신호에 가깝습니다. 본질은 여전히 콘텐츠의 품질과 검색 의도 충족입니다.

3대 지표와 합격선

Core Web Vitals는 로딩(LCP), 반응성(INP), 시각적 안정성(CLS) 세 가지로 구성됩니다. 각 지표에는 '좋음(good)' 기준이 있고, 실험실 점수가 아니라 실제 사용자 데이터(필드 데이터)의 75퍼센타일 값으로 평가합니다. 즉 방문자 4명 중 3명이 아래 기준을 통과해야 '좋음'으로 판정됩니다.

INP, 2024년 3월 FID를 대체한 지표

가장 중요한 변화는 INP입니다. INP(Interaction to Next Paint)는 2024년 3월에 기존의 FID(First Input Delay)를 정식으로 대체하며 Core Web Vitals에 편입됐습니다. 과거 자료나 오래된 블로그 글에서 'FID를 관리하라'는 내용을 봤다면, 이제는 INP 기준으로 다시 점검해야 합니다.

FID는 '첫 입력에 대한 지연 시간'만 쟀습니다. 사용자가 처음 클릭했을 때 브라우저가 반응을 시작하기까지의 시간만 본 것이죠. 반면 INP는 페이지에 머무는 동안 발생한 거의 모든 상호작용(클릭, 탭, 키 입력)을 추적해, 그중 가장 느렸던 반응 시간을 대표값으로 잡습니다. 입력 시작부터 화면에 변화가 그려지기까지 전체 과정을 측정하기 때문에 더 엄격하고 현실적인 지표입니다.

• 좋음(good): 200ms 이하 — 사용자가 거의 즉각적이라고 느끼는 수준입니다.
• 개선 필요: 200ms 초과 ~ 500ms 이하 — 미세한 끊김을 느낄 수 있습니다.
• 나쁨(poor): 500ms 초과 — 버튼을 눌렀는데 한 박자 늦게 반응하는 답답함이 발생합니다.

INP를 개선하는 실무 방법

INP가 나쁜 가장 흔한 원인은 무거운 자바스크립트입니다. 클릭 이벤트가 발생했을 때 메인 스레드가 오래 걸리는 작업으로 막혀 있으면, 브라우저가 화면을 다시 그리지 못해 반응이 늦어집니다. 따라서 INP 개선은 곧 '자바스크립트 부담 줄이기'에 가깝습니다.

• 긴 작업 쪼개기: 한 번에 50ms 넘게 메인 스레드를 점유하는 긴 작업(long task)을 작은 단위로 나눠 처리합니다.
• 불필요한 스크립트 제거: 안 쓰는 위젯, 채팅 플러그인, 광고 스크립트, 추적 태그가 입력 반응을 잡아먹는 주범인 경우가 많습니다.
• 서드파티 스크립트 지연 로딩: 당장 필요 없는 외부 스크립트는 페이지 상호작용이 끝난 뒤 불러오도록 미룹니다.
• 이벤트 핸들러 가볍게: 클릭 한 번에 무거운 계산이나 대규모 DOM 변경이 몰리지 않도록 작업을 분산합니다.

LCP, 주요 콘텐츠가 2.5초 안에 보여야 한다

LCP(Largest Contentful Paint)는 화면에서 가장 큰 콘텐츠 요소(보통 대표 이미지나 큰 제목 텍스트)가 보이기까지 걸리는 시간입니다. 방문자가 '이 페이지가 떴다'고 인식하는 순간과 거의 일치합니다. 좋음 기준은 2.5초 이하이며, 4초를 넘기면 나쁨으로 분류됩니다.

LCP가 느린 원인은 대부분 명확합니다. 용량이 큰 대표 이미지, 느린 서버 응답, 그리고 화면 위쪽 콘텐츠를 막아서는 렌더링 차단 리소스(CSS·자바스크립트)입니다. 이 세 가지만 정리해도 LCP가 눈에 띄게 좋아지는 경우가 많습니다.

• 대표 이미지 최적화: 화면 상단의 큰 이미지를 WebP 등 차세대 포맷으로 압축하고, 표시 크기에 맞는 해상도로 줄입니다.
• 이미지 미리 불러오기: 가장 큰 요소가 이미지라면 preload로 우선순위를 높여 빨리 가져옵니다.
• 서버 응답 시간 단축: 캐싱과 CDN을 활용해 첫 바이트 도착 시간(TTFB)을 줄입니다.
• 렌더링 차단 제거: 화면 위쪽에 꼭 필요하지 않은 CSS·JS는 지연 로딩하거나 분리합니다.

CLS, 화면이 갑자기 밀리지 않게

CLS(Cumulative Layout Shift)는 페이지를 읽는 도중 요소가 예고 없이 위치를 바꾸는 '레이아웃 밀림'의 정도를 점수로 나타냅니다. 글을 읽으려는데 광고나 이미지가 뒤늦게 로딩되며 본문을 아래로 밀어버리고, 그 바람에 엉뚱한 버튼을 누르게 되는 경험을 한 번쯤 해보셨을 겁니다. 그 답답함이 바로 CLS입니다. 좋음 기준은 0.1 이하입니다.

• 이미지·동영상 크기 지정: width와 height(또는 aspect-ratio)를 미리 지정해 브라우저가 자리를 먼저 잡게 합니다.
• 광고·임베드 공간 확보: 광고나 외부 위젯이 들어갈 영역을 미리 비워두어 나중에 본문을 밀지 않게 합니다.
• 웹폰트 깜빡임 방지: 폰트 교체 시 글자 크기가 바뀌며 레이아웃이 튀지 않도록 폰트 로딩 전략을 설정합니다.
• 동적 삽입 주의: 기존 콘텐츠 위쪽에 배너나 알림을 뒤늦게 끼워 넣는 패턴을 피합니다.

지금 내 사이트 점수를 확인하는 방법

Core Web Vitals는 추측이 아니라 측정이 먼저입니다. 어떤 지표가, 어느 페이지에서, 어떤 원인으로 떨어지는지 확인한 뒤 개선해야 헛수고를 줄일 수 있습니다. 아래 도구들을 함께 쓰면 됩니다.

검색 순위와의 관계, 오해하기 쉬운 부분

가장 자주 받는 질문이 "Core Web Vitals 점수를 만점으로 만들면 순위가 오르나요?"입니다. 결론부터 말하면, 점수는 랭킹 신호 중 하나가 맞지만 그 비중은 제한적입니다. 구글도 공식 문서에서 '여러 신호 중 하나일 뿐이며 콘텐츠 관련성이 우선'이라는 취지로 안내하고 있습니다. 점수만으로 순위 상승이 보장되는 것은 아닙니다.

현실적으로 이해하면 이렇습니다. 콘텐츠가 부실한 페이지는 속도가 아무리 빨라도 상위에 오르기 어렵습니다. 반대로 좋은 콘텐츠 여러 개가 검색 결과에서 비슷하게 경쟁할 때, 사용자 경험이 더 매끄러운 페이지가 상대적으로 유리할 수 있습니다. 그래서 우선순위는 항상 '콘텐츠 먼저, 그다음 기술적 다듬기'입니다.

우선순위를 정리하면

1. 1먼저 콘텐츠 자체가 검색 의도를 충실히 채우는지 점검합니다. 이것이 가장 큰 영향을 줍니다.
2. 2Search Console 코어 웹 바이탈 보고서로 '나쁨' URL이 몰린 페이지 유형을 찾습니다.
3. 3세 지표 중 가장 점수가 낮은 항목부터 손댑니다. 보통 이미지(LCP)와 자바스크립트(INP) 개선이 효율이 좋습니다.
4. 4수정 후에는 필드 데이터가 갱신될 때까지 수 주가 걸릴 수 있으니, 실험실 점수로 방향을 확인하며 기다립니다.
5. 5색인이 누락된 글이 있다면 경험 점수와 별개로 색인 상태를 먼저 점검합니다.

Core Web Vitals는 한 번 만점을 받고 끝나는 작업이 아니라, 사이트가 커지고 스크립트가 늘어날수록 다시 나빠질 수 있는 지표입니다. 분기마다 한 번씩 점검하는 정도로도 충분하니, 부담 없이 꾸준히 관리하는 것을 권합니다.