성능 개선이 멈추는 이유는 늘 비슷합니다. 지표는 개발이 들고 있고, 예산은 프로덕트가 들고 있는데, 양쪽 다 "LCP 4.2초"를 비즈니스 언어로 번역하지 못합니다. 이 글은 그 간극을 겨냥합니다. 세 지표가 무엇을 뜻하는지, 점수가 나쁠 때 보통 무엇이 원인인지, 그리고 한 스프린트를 쓸 가치가 있는지 판단하는 방법입니다.
세 가지 지표
LCP(Largest Contentful Paint). 화면에서 가장 큰 요소(대개 Hero 이미지나 헤드라인)가 렌더링을 마칠 때까지의 시간. 사용자가 "페이지가 떴다"고 느끼는 순간입니다.
- 양호 2.5초 이하 · 개선 필요 2.5~4.0초 · 나쁨 4.0초 초과
INP(Interaction to Next Paint). 사용자 인터랙션에 화면이 시각적으로 반응하기까지의 시간을, 첫 클릭이 아니라 방문 전체에 걸쳐 측정합니다. 사용자가 "반응이 빠르다"고 느끼는 지점입니다. 첫 입력만 빠르고 이후엔 버벅이는 페이지를 실제보다 좋게 보이게 했던 FID를 대체했습니다.
- 양호 200ms 이하 · 개선 필요 200~500ms · 나쁨 500ms 초과
CLS(Cumulative Layout Shift). 로딩 중 콘텐츠가 예기치 않게 움직인 정도. 사용자가 "엉뚱한 걸 눌렀다"고 느끼는 지점입니다.
- 양호 0.1 이하 · 개선 필요 0.1~0.25 · 나쁨 0.25 초과
평가는 실제 사용자의 75 백분위수 기준입니다. 내 노트북에서 빠른 건 아무것도 증명하지 못합니다. 사용자의 4분의 1이 LTE 환경의 중급 안드로이드라면, 그 사람들이 숫자를 결정합니다.
Lab과 Field 데이터: 대부분의 논쟁을 끝내는 구분
Lab 데이터(Lighthouse, PageSpeed Insights의 Lab 영역)는 통제된 환경에서 한 페이지를 시뮬레이션한 1회 실행 결과입니다. 재현 가능하고 진단에 유용하며, 무엇을 고칠지 알려줍니다.
Field 데이터(Chrome UX Report, Search Console의 Core Web Vitals 보고서, 자체 RUM)는 최근 28일간 실제 사용자가 겪은 값입니다. 평가 기준이며 보고해야 할 숫자입니다.
개발은 "Lighthouse 95점"이라 하고 CS는 "느리다는 문의가 온다"고 할 때, 보통 양쪽 다 맞습니다. Lighthouse는 빠른 회선과 따뜻한 캐시에서 돌았고, 불만은 75 백분위에서 나옵니다. 이해관계자에게는 Field를 보고하고, 원인 추적에는 Lab을 쓰세요.
각 지표가 나빠지는 실제 원인
LCP가 느린 이유
- 서버 응답 지연(TTFB). 나머지 전부가 여기에 걸립니다. 600ms를 넘으면 이미지 작업보다 먼저 봐야 합니다.
- 최적화되지 않은 Hero 이미지 — 가장 흔한 원인입니다. 최신 포맷, 정확한 크기, 우선 로딩.
<head>의 렌더 차단 CSS와 폰트.- LCP 요소에 지연 로딩을 걸어 정작 측정 대상이 늦어지는 경우.
- 클라이언트 렌더링. Hero가 하이드레이션 이후에만 존재하면 LCP에 JavaScript 파이프라인 전체가 포함됩니다. JS 렌더링과 크롤링에서 같은 원인을 SEO 관점으로 다룹니다.
INP가 나쁜 이유
- 메인 스레드를 막는 긴 JavaScript 작업 — 보통 서드파티 태그, 애널리틱스, 채팅 위젯, A/B 테스트 스크립트입니다.
- 레이아웃 작업을 동기적으로 수행하는 무거운 이벤트 핸들러.
- 작은 상태 변경이 유발하는 대규모 React 리렌더.
- 그냥 서드파티 스크립트가 너무 많은 경우. 실제 로드 목록을 점검해 보세요. 아무도 존재 이유를 설명하지 못하는 태그가 최소 하나는 있습니다.
CLS가 나쁜 이유
- width/height 또는
aspect-ratio가 없는 이미지·iframe. - 공간을 예약하지 않은 자리에 삽입되는 광고·임베드.
- 웹폰트 교체로 인한 텍스트 리플로우.
- 로드 후 기존 콘텐츠 위에 삽입되는 배너, 쿠키 안내, 프로모션 바.
CLS는 셋 중 가장 고치기 싸고, 사용자에게 가장 잘 보이는 지표입니다.
백로그의 다른 일감과 비교한 우선순위
성능은 기능과 경쟁합니다. "순위 요소니까요"는 그 자체로는 약한 근거입니다. Core Web Vitals는 실재하지만 작은 신호입니다. 더 강한 근거는 다음입니다.
- 전환. 느린 페이지는 전환 이전에 세션을 잃습니다. 자사 데이터로 측정하세요. 애널리틱스를 LCP 구간별로 나눠 전환율을 비교하면 됩니다. 2배 차이는 흔하고, 이해관계자가 행동할 수 있는 숫자입니다.
- 크롤 효율. 응답이 빨라지면 크롤 속도 한계가 올라가고, 대규모 사이트에서는 이게 중요합니다(크롤 예산 최적화).
- 비용. 페이로드가 줄면 대역폭과 CDN 비용이 줄고, 이건 이미 누군가의 예산 항목입니다.
현실적인 순서는 이렇습니다.
- 1스프린트 — 측정. RUM을 심고, Search Console 보고서를 받고, 템플릿별(홈·카테고리·상세·결제)로 나눕니다. 사이트 평균이 아니라 가장 나쁜 템플릿을 고칩니다.
- 2스프린트 — CLS. 가장 저렴하고, 즉시 보이며, 회귀 위험이 낮습니다.
- 3스프린트 — 트래픽이 가장 많은 템플릿의 LCP. 보통 이미지 최적화 + TTFB입니다.
- 상시 — INP. 구조적 문제라 한 스프린트에 들어가지 않습니다. 끝내는 프로젝트가 아니라 지켜내는 예산으로 다루세요.
유지되는 예산 설정
작업 시작 전에 숫자를 합의하고 CI로 강제합니다.
| 지표 | 예산 | 강제 방식 |
|---|---|---|
| LCP (p75, Field) | 2.5초 이하 | 월간 리뷰 |
| INP (p75, Field) | 200ms 이하 | 월간 리뷰 |
| CLS (p75, Field) | 0.1 이하 | 월간 리뷰 |
| 초기 JS 번들 | gzip 200KB 이하 | CI 체크, 머지 차단 |
| Hero 이미지 | 150KB 이하 | 빌드 린트 |
| 서드파티 스크립트 | 5개 이하 | 분기 리뷰, 담당자 명시 |
성과를 지켜주는 건 CI 체크입니다. 이게 없으면 성능은 작은 추가 하나씩 되돌아가고, 18개월 뒤 같은 프로젝트를 다시 하게 됩니다.
자주 묻는 질문
Core Web Vitals가 순위에 얼마나 영향을 주나요?
확인된 신호이지만 가볍습니다. 비슷한 수준의 페이지 사이에서 타이브레이커로 작용할 뿐, 적합성을 대체하지 않습니다. 느린 페이지의 더 좋은 콘텐츠가 보통 이깁니다. 사용자와 전환을 위해 최적화하고, 순위 효과는 덤으로 보세요.
Lighthouse 점수와 Search Console이 다른 이유는요?
Lighthouse는 시뮬레이션 1회(Lab)이고, Search Console은 28일간 실제 사용자의 75 백분위(Field)입니다. 측정 대상이 다르므로 일치하지 않는 게 정상입니다. 평가는 Field를 믿으세요.
Lighthouse 100점이 목표인가요?
아닙니다. 점수는 1회 실행의 Lab 지표들을 가중 합산한 값입니다. 목표는 실제 사용자 기준 세 지표의 임계값 통과입니다. Field가 나쁜데 Lab만 100점이면 아무에게도 도움이 되지 않습니다.
수정 후 Field 데이터는 언제 갱신되나요?
Chrome UX Report는 28일 롤링 윈도우이므로 오늘 배포한 수정은 약 4주 뒤 온전히 반영됩니다. 변경이 실제로 적용됐는지는 RUM으로 즉시 확인하세요.
가장 빠른 단일 개선은 무엇인가요?
대개 Hero 이미지입니다. 정확한 크기, 최신 포맷, 우선순위 높은 즉시 로딩, preload 힌트. 이것만으로도 대부분의 사이트에서 LCP가 1초 이상 개선됩니다.