OneWebDesk

Core Web Vitals(LCP·CLS·INP) 개선 체크리스트

LCP·CLS·INP가 무엇이고 무엇을 측정하는지, 점수를 올리는 실전 체크리스트.

Core Web Vitals는 구글이 검색 순위 신호로 사용하는 세 가지 실사용자 성능 지표입니다. 화면이 얼마나 빨리 채워지는지(LCP), 레이아웃이 얼마나 안 흔들리는지(CLS), 클릭·입력에 얼마나 빠르게 반응하는지(INP)를 측정합니다. 세 지표 모두 실험실(Lighthouse) 점수가 아니라 실제 방문자의 Chrome 데이터(CrUX)에서 75퍼센타일 값으로 평가된다는 점이 핵심입니다. 즉 가장 느린 사용자 4명 중 1명이 겪는 경험까지 좋아야 통과합니다.

이 가이드는 세 지표를 정의 → 기준값 → 실행 체크리스트 순서로 정리합니다. 각 항목은 코드를 거의 모르더라도 따라 할 수 있도록 우선순위가 높은 것부터 배치했습니다. 페이지 용량과 응답 속도부터 점검하고 싶다면 먼저 페이지 용량 분석 응답 시간 측정으로 현재 상태를 숫자로 확인하세요.

기준값 한눈에 보기

구글은 각 지표를 좋음 / 개선 필요 / 나쁨 세 구간으로 나눕니다. “좋음” 구간에 들어와야 검색에서 긍정 신호로 작동합니다.

지표측정 대상좋음개선 필요나쁨
LCP로딩(가장 큰 요소 표시)≤ 2.5초2.5–4.0초> 4.0초
CLS시각 안정성(레이아웃 이동)≤ 0.10.1–0.25> 0.25
INP반응성(상호작용 지연)≤ 200ms200–500ms> 500ms

LCP 개선 — 가장 큰 콘텐츠를 2.5초 안에

LCP(Largest Contentful Paint)는 뷰포트에서 가장 큰 콘텐츠 요소(대개 히어로 이미지나 큰 제목)가 화면에 그려지는 시점입니다. 느린 LCP의 원인은 대부분 느린 서버 응답(TTFB), 무거운 히어로 이미지, 렌더링을 막는 리소스 셋 중 하나입니다.

  • 서버 TTFB부터 줄이기. HTML 첫 바이트가 늦으면 그 뒤 모든 게 밀립니다. 캐싱·CDN·정적 생성(SSG)을 적용하고, 현재 값은 응답 시간 측정으로 확인하세요. TTFB는 0.8초 이하가 목표입니다.
  • 히어로 이미지 최적화. LCP 요소가 이미지라면 적절한 크기로 리사이즈하고 WebP/AVIF로 변환하세요. 어떤 포맷이 좋은지는 이미지 포맷 추천으로 판단할 수 있습니다.
  • 우선 로딩 지정. LCP 이미지에 fetchpriority="high"를 주고loading="lazy"는 절대 붙이지 마세요. 외부 도메인 리소스는<link rel="preconnect">로 연결을 미리 엽니다.
  • 렌더 차단 제거. 폰트와 CSS를 인라인/프리로드하고, 큰 JS는 지연 로드해 첫 화면 경로를 가볍게 만드세요. 전체 전송량은 페이지 용량 분석으로 추적합니다.

실전 예시: 어떤 블로그의 LCP가 4.3초(나쁨)였습니다. 히어로 JPG가 1.8MB였죠. 이미지를 1200px 폭으로 리사이즈하고 AVIF로 변환해 210KB로 줄인 뒤 fetchpriority="high"를 추가했더니 LCP가 2.1초(좋음)로 떨어졌습니다. 이미지 한 장 교체만으로 구간이 두 단계 올라간 사례입니다.

CLS 개선 — 화면이 흔들리지 않게

CLS(Cumulative Layout Shift)는 페이지가 로드되는 동안 요소가 예기치 않게 움직인 정도를 누적한 점수입니다. 버튼을 누르려는 순간 광고가 끼어들어 다른 곳을 누른 경험이 바로 CLS입니다. 점수가 아니라 사용자 짜증을 숫자로 만든 지표라고 보면 됩니다.

  1. 이미지·동영상에 치수 지정. width/height 속성이나 CSSaspect-ratio를 항상 지정해 브라우저가 자리를 미리 비워 두게 하세요. 이것 하나로 CLS의 절반이 해결되는 경우가 많습니다.
  2. 광고·임베드 공간 예약. 배너·iframe 자리에 최소 높이를 미리 잡아 두어 콘텐츠가 들어올 때 아래 내용이 밀리지 않게 합니다.
  3. 폰트 깜빡임 방지. font-display: swap과 함께 size-adjust로 폴백 폰트의 글자 크기를 맞춰 폰트 교체 시 줄바꿈이 흔들리지 않게 합니다. 핵심 폰트는 프리로드하세요.
  4. 기존 콘텐츠 위에 삽입 금지. 알림 바·쿠키 배너를 본문 위에 끼워 넣지 말고 화면 위/아래에 오버레이로 띄우거나 처음부터 공간을 확보하세요.

INP 개선 — 클릭에 즉시 반응하게

INP(Interaction to Next Paint)는 2024년 FID를 대체한 지표로, 페이지 수명 동안 모든 클릭·탭·키 입력 중 거의 최악에 해당하는 응답 지연을 측정합니다. 원인은 거의 항상 메인 스레드를 오래 점유하는 긴 작업(long task)입니다. JavaScript가 50ms 넘게 한 번에 실행되면 그 사이 입력이 막힙니다.

  • 긴 작업 쪼개기. 무거운 함수를 setTimeout·scheduler.yield()로 나눠 브라우저가 입력을 처리할 틈을 주세요. 한 번에 50ms를 넘기지 않는 것이 목표입니다.
  • JS 줄이고 나누기. 사용하지 않는 라이브러리를 제거하고 코드 스플리팅으로 첫 화면에 필요한 만큼만 보냅니다. 번들 크기는 페이지 용량 분석으로 확인하세요.
  • 무거운 계산은 워커로. 데이터 정렬·파싱 같은 작업은 Web Worker로 옮겨 메인 스레드를 입력 처리용으로 비워 둡니다.
  • 입력 핸들러 가볍게. 클릭 핸들러에서는 즉시 시각 피드백만 주고, 무거운 후속 작업은 다음 프레임으로 미뤄 화면이 먼저 갱신되게 합니다.

세 지표는 서로 얽혀 있습니다. 무거운 자원을 줄이면 LCP·INP가 함께 좋아지고, 자리를 미리 확보하면 CLS가 안정됩니다. 페이지 용량 응답 시간으로 기준선을 잡고, 이미지는 포맷 추천으로 정리하는 것이 가장 빠른 출발점입니다.

자주 묻는 질문

Core Web Vitals는 실험실 점수인가요, 실사용자 데이터인가요?
검색 순위에 쓰이는 값은 실사용자 데이터(CrUX)의 28일치 75퍼센타일입니다. Lighthouse 같은 실험실 점수는 디버깅에 유용하지만 순위 평가 자체는 실제 방문자 경험을 기준으로 합니다.
FID는 어떻게 됐나요?
FID(First Input Delay)는 2024년 3월에 INP로 공식 대체되었습니다. INP는 첫 입력만이 아니라 페이지 수명 전체의 상호작용 지연을 보기 때문에 더 엄격하고 현실적인 지표입니다.
세 지표 중 무엇부터 손대야 하나요?
보통 LCP가 가장 흔한 실패 구간이라 히어로 이미지와 서버 응답부터 보는 것이 효율적입니다. 이후 CLS(치수 지정), INP(긴 작업 분할) 순으로 잡으면 적은 노력으로 큰 개선을 얻을 수 있습니다.
이미지만 바꿔도 효과가 있나요?
네. 큰 히어로 이미지를 적절한 크기로 리사이즈하고 WebP/AVIF로 변환하면 LCP가 한두 구간 단위로 개선되는 경우가 많습니다. 동시에 width/height를 지정하면 CLS도 함께 좋아집니다.
통과하면 검색 순위가 바로 오르나요?
Core Web Vitals는 여러 순위 신호 중 하나이며 동점일 때 차이를 만드는 타이브레이커에 가깝습니다. 콘텐츠 품질이 우선이지만, 좋은 점수는 이탈률을 낮춰 간접적으로도 도움이 됩니다.

이 가이드와 함께 쓰면 좋은 도구