코어 웹 바이탈(LCP·INP·CLS) 뜻과 기준값, 항목별 개선 방법
코어 웹 바이탈(Core Web Vitals)은 구글이 “사용자가 체감하는 페이지 품질”을 재기 위해 정한 세 가지 지표, LCP·INP·CLS를 말합니다. 이 가이드는 PageSpeed Insights 결과표에서 LCP·INP·CLS가 무엇을 뜻하는지, 어느 값이면 통과인지, 점수가 나쁠 때 어디부터 봐야 하는지를 지표별로 정리합니다. 측정 도구 사용법과 일반적인 속도 개선 절차는 기존 가이드에서 다뤘으므로, 여기서는 세 지표 자체에 집중합니다.
ℹ️ 참고
PageSpeed Insights 화면을 처음 본다면 웹사이트 속도 측정 방법 가이드 (PageSpeed Insights 활용법)를, 서버·캐시·코드 정리 같은 전체 개선 순서는 웹사이트 속도 개선방법 5단계 가이드를 먼저 보세요.
코어 웹 바이탈이란? LCP·INP·CLS 한 줄 정의
코어 웹 바이탈은 로딩 속도(LCP), 반응성(INP), 시각적 안정성(CLS) 세 가지로 페이지 경험을 측정하는 구글의 지표 묶음입니다. 각각 “보여지는가”, “누르면 반응하는가”, “화면이 안 흔들리는가”를 잽니다.
- LCP (Largest Contentful Paint, 최대 콘텐츠 렌더링 시간): 화면에 보이는 가장 큰 이미지나 글 덩어리가 그려지기까지 걸린 시간입니다. 방문자가 “페이지가 떴다”고 느끼는 시점에 가깝습니다.
- INP (Interaction to Next Paint, 다음 페인트까지의 상호작용): 클릭·탭·키 입력을 한 뒤 화면이 바뀌기까지 걸린 시간입니다. 방문 중 일어난 상호작용 가운데 가장 느린 축에 속하는 값으로 대표합니다.
- CLS (Cumulative Layout Shift, 누적 레이아웃 이동): 페이지가 뜨는 동안 요소가 예고 없이 밀리는 정도입니다. 버튼을 누르려는 순간 배너가 끼어들어 다른 곳을 누르게 되는 현상이 대표적입니다.
구글은 코어 웹 바이탈이 핵심 순위 시스템이 보상하려는 방향과 일치한다고 설명합니다. 다만 순위는 콘텐츠 관련성이 먼저이고, 지표가 좋다고 상위 노출이 보장되지는 않습니다. 검색 순위 전반의 요소는 구글 SEO 최적화 핵심 전략, 상위 노출을 위한 실전 가이드를 참고하세요.
코어 웹 바이탈 기준값: 좋음·개선 필요·나쁨
web.dev 공식 기준(2026-10-01 확인)으로 LCP 2.5초 이하, INP 200밀리초 이하, CLS 0.1 이하면 “좋음”입니다.
| 지표 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|
| LCP (로딩) | 2.5초 이하 | 2.5초 초과 ~ 4.0초 이하 | 4.0초 초과 |
| INP (반응성) | 200ms 이하 | 200ms 초과 ~ 500ms 이하 | 500ms 초과 |
| CLS (안정성) | 0.1 이하 | 0.1 초과 ~ 0.25 이하 | 0.25 초과 |
“75번째 백분위수”로 판정합니다
기준값은 평균이 아니라 방문의 75%가 이 값보다 좋아야 한다는 뜻입니다. 방문자 100명 중 75번째로 느린 사람의 경험이 기준 안에 들어와야 통과입니다. 또 모바일과 데스크톱을 따로 판정하므로, PC에서 통과해도 모바일에서 실패할 수 있습니다. 세 지표가 모두 “좋음”이어야 해당 페이지가 코어 웹 바이탈 평가를 통과한 것으로 봅니다.
📌 용어 설명: 75번째 백분위수
값을 좋은 순서로 줄 세웠을 때 75% 지점에 있는 값입니다. 일부 느린 기기·느린 통신 환경까지 어느 정도 포함해서 보겠다는 뜻이라, 사무실 PC에서 빠르게 보이는 것만으로는 통과를 장담할 수 없습니다.
INP는 2024년 3월 12일 FID를 대체했습니다
예전에는 반응성 지표로 FID(First Input Delay, 최초 입력 지연)를 썼습니다. FID는 첫 번째 상호작용의 “대기 시간”만 쟀기 때문에, 첫 클릭 이후 느려지는 페이지를 잡아내지 못했습니다. 구글은 2024년 3월 12일 INP를 코어 웹 바이탈로 정식 전환했고, 서치콘솔은 그날 FID를 바로 뺐습니다. 오래된 글이나 보고서에 FID 100ms 기준이 나온다면 지금은 쓰지 않는 기준입니다.
측정 도구: 필드 데이터와 실험실 데이터의 차이
코어 웹 바이탈 판정은 실제 방문자 데이터(필드 데이터)로 합니다. PageSpeed Insights 상단의 “실제 사용자 환경” 영역과 서치콘솔 Core Web Vitals 보고서가 이 데이터를 씁니다. 둘 다 크롬 사용자 경험 보고서(CrUX)를 원천으로 최근 28일 값을 보여 줍니다.
| 구분 | 필드 데이터 | 실험실 데이터 |
|---|---|---|
| 어디서 | PageSpeed Insights 상단, 서치콘솔 보고서 | PageSpeed Insights 하단 진단(Lighthouse), 크롬 개발자 도구 |
| 무엇을 | 실제 크롬 사용자들의 최근 28일 경험 | 정해진 기기·통신 조건에서 한 번 불러온 결과 |
| INP 측정 | 가능 | 불가(클릭이 없어서). 대신 TBT(총 차단 시간)를 참고 |
| 쓰임 | 통과 여부 판정 | 원인 찾기, 수정 직후 확인 |
⚠️ 주의
방문자가 적은 페이지나 막 오픈한 사이트는 필드 데이터가 부족해 “데이터 없음”이 나오거나 사이트 전체(원본) 값으로 대신 표시됩니다. 이때는 실험실 데이터로 원인을 고치고, 방문이 쌓인 뒤 필드 데이터로 확인합니다. 또 수정 효과가 필드 데이터에 다 반영되려면 28일이 걸립니다. 고친 다음 날 점수가 그대로라고 실패한 것이 아닙니다.
서치콘솔 Core Web Vitals 보고서 보는 법
서치콘솔 왼쪽 메뉴의 실험 > 코어 웹 바이탈 보고서는 모바일과 데스크톱을 나눠, 비슷한 페이지를 묶어 “느린 URL·개선이 필요한 URL·빠른 URL”로 보여 줍니다. 묶음의 상태는 세 지표 중 가장 나쁜 값으로 정해집니다. 문제를 고친 뒤 해당 문제 화면에서 추적 시작을 누르면 28일 동안 모니터링해 해결 여부를 알려 줍니다. 서치콘솔 메뉴 전반은 구글 서치콘솔 사용법 핵심 기능별 가이드에 정리돼 있습니다.
LCP 개선: 원인은 네 구간 중 어디에 있나
LCP가 느릴 때는 “이미지를 줄이자”부터 하지 말고, 시간이 어느 구간에서 새는지 먼저 봅니다. web.dev는 LCP를 네 구간으로 나눕니다.
| 구간 | 뜻 | 권장 비중 | 흔한 원인 |
|---|---|---|---|
| 첫 바이트까지의 시간(TTFB) | 서버가 HTML을 보내기 시작할 때까지 | 약 40% | 느린 호스팅, 캐시 없음, 리디렉션 여러 번 |
| 리소스 로드 지연 | HTML을 받은 뒤 LCP 이미지 요청을 시작할 때까지 | 10% 미만 | 이미지가 CSS 배경·자바스크립트 슬라이더 안에 있어 늦게 발견됨 |
| 리소스 로드 시간 | LCP 이미지를 내려받는 시간 | 약 40% | 이미지 용량 과다, 구형 포맷 |
| 요소 렌더링 지연 | 다 받은 뒤 화면에 그려질 때까지 | 10% 미만 | 렌더링을 막는 CSS·JS, 긴 스크립트 작업 |
PageSpeed Insights 하단 진단에서 “LCP 요소”를 열면 어떤 요소가 LCP인지, 구간별 시간이 얼마인지 볼 수 있습니다.
기업 홈페이지에서 자주 보는 LCP 문제
- 메인 슬라이더 첫 이미지에 지연 로딩(lazy) 적용: 첫 화면 이미지는
loading="lazy"를 빼고fetchpriority="high"를 붙입니다. - 히어로 이미지를 CSS 배경으로 넣음: 브라우저가 CSS를 다 읽은 뒤에야 이미지를 발견합니다. HTML의
<img>로 넣거나 preload로 미리 알려 줍니다. - 첫 화면을 자바스크립트로 그림: 스크립트가 실행돼야 이미지가 생기면 로드 지연이 커집니다. 첫 화면은 서버에서 HTML로 내려주는 편이 유리합니다.
- 원본 크기 이미지: 4000px 사진을 그대로 올리면 로드 시간이 길어집니다. 포맷·크기 조정은 이미지 최적화 방법 총정리: 웹사이트 속도를 높이는 핵심을 참고하세요.
INP 개선: 클릭했는데 멈칫하는 이유
INP는 상호작용 한 번을 세 단계로 나눠 봅니다. 입력 지연(브라우저가 다른 일 때문에 클릭을 바로 처리하지 못함), 처리 시간(클릭에 연결된 코드 실행), 표시 지연(결과를 화면에 그림)입니다. 세 단계의 합이 INP입니다.
흔한 원인과 개선
- 외부 스크립트 과다: 채팅 상담, 여러 개의 광고 픽셀·분석 태그가 페이지를 불러오는 동안 메인 스레드를 붙잡아 클릭 반응을 늦춥니다. 쓰지 않는 태그를 정리하고, 꼭 필요한 것도 페이지가 뜬 뒤에 불러오게 합니다.
- 긴 작업(Long Task): 클릭 한 번에 많은 계산을 몰아서 하면 화면 갱신이 늦어집니다. 화면에 보여야 할 변화만 먼저 처리하고 나머지는 나눠 실행합니다.
- 큰 DOM: 제품 목록 수백 개, 숨겨 둔 메가메뉴 같은 요소가 너무 많으면 그리는 비용이 커집니다. 목록은 페이지 나누기나 “더 보기”로 나눕니다.
- 무거운 메뉴·필터 동작: 모바일 햄버거 메뉴, 제품 필터를 누를 때 느리다면 그 동작의 스크립트가 원인입니다. 크롬 개발자 도구 성능 탭에서 해당 클릭을 기록해 보면 오래 걸리는 작업이 보입니다.
💡 실무 팁
INP는 실험실 측정에서 직접 나오지 않습니다. PageSpeed Insights 하단의 TBT(총 차단 시간)가 크다면 INP도 나쁠 가능성이 높으니, 필드 데이터가 쌓이기 전에는 TBT를 대신 보고 줄여 두세요.
CLS 개선: 화면이 밀리는 다섯 가지 원인
CLS는 방문자가 의도하지 않은 레이아웃 이동만 셉니다. 사용자가 버튼을 누른 뒤 500밀리초 안에 일어난 이동(예: “더 보기”를 눌러 목록이 펼쳐짐)은 점수에서 빠집니다.
- 크기 없는 이미지:
<img>에width·height를 적거나 CSSaspect-ratio로 자리를 미리 잡습니다. 가장 흔하고 가장 쉽게 고치는 원인입니다. - 광고·지도·동영상 임베드: 늦게 뜨는 iframe은
min-height나 비율로 공간을 먼저 확보합니다. - 나중에 끼어드는 콘텐츠: 쿠키 동의 배너, 상단 공지 띠, 팝업이 페이지 위쪽을 밀어 내리면 점수가 크게 나빠집니다. 화면 위에 겹쳐 띄우거나 처음부터 자리를 비워 둡니다.
- 웹폰트 교체: 기본 글꼴로 보였다가 웹폰트로 바뀌며 줄 길이가 달라지면 아래 내용이 밀립니다. 글꼴 파일을 미리 불러오고, 대체 글꼴 크기를 웹폰트와 비슷하게 맞춥니다.
- 위치를 바꾸는 애니메이션:
top·left로 움직이는 애니메이션 대신transform을 씁니다.
자주 묻는 질문
LCP 뜻이 뭔가요?
LCP(Largest Contentful Paint)는 화면에 보이는 가장 큰 이미지나 텍스트 덩어리가 그려지기까지 걸린 시간입니다. 2.5초 이하면 “좋음”입니다.
PageSpeed Insights 성능 점수가 90점이 아니면 코어 웹 바이탈 실패인가요?
아닙니다. 성능 점수는 실험실 데이터로 계산한 점수이고, 코어 웹 바이탈 통과 여부는 상단의 실제 사용자 데이터로 판정합니다. 점수가 70점대여도 필드 데이터 세 지표가 모두 좋음이면 통과입니다.
고쳤는데 서치콘솔에 반영이 안 됩니다.
서치콘솔 보고서는 최근 28일 실제 방문 데이터를 쓰기 때문에 수정 효과가 다 반영되기까지 시간이 걸립니다. 수정 결과 확인(추적 시작)을 누르고 28일을 기다리세요.
FID 기준은 이제 신경 쓰지 않아도 되나요?
네. 2024년 3월 12일부터 반응성 지표는 INP입니다. 다만 INP를 줄이는 방법(긴 스크립트 작업 줄이기, 외부 스크립트 정리)은 FID 개선에도 그대로 도움이 됐던 방법입니다.
웹닷은 첫 화면 이미지 우선순위, 이미지 크기 지정, 외부 스크립트 로딩 순서를 빌드 단계에서 함께 처리하고, 오픈 전에 모바일 기준으로 세 지표를 확인합니다.
정리
- 코어 웹 바이탈은 LCP(로딩)·INP(반응성)·CLS(안정성) 세 지표이며, 좋음 기준은 2.5초·200ms·0.1입니다.
- 판정은 실제 방문의 75번째 백분위수로, 모바일과 데스크톱을 따로 합니다.
- INP는 2024년 3월 12일 FID를 대체했습니다. FID 기준이 나오는 자료는 예전 자료입니다.
- LCP는 네 구간 중 어디서 시간이 새는지, INP는 외부 스크립트와 긴 작업, CLS는 크기 없는 이미지와 늦게 끼어드는 배너부터 확인합니다.
- 통과 여부는 필드 데이터(PageSpeed Insights 상단·서치콘솔)로, 원인 찾기는 실험실 데이터로 하고, 반영까지 28일을 기다립니다.