Core Web Vitals, 어디서부터 손대야 하나?
결론부터 말하면, 점수가 아니라 CrUX의 75백분위 수치(LCP 2.5초, INP 200ms, CLS 0.1 이하가 Good)를 먼저 확인하고, 그중 가장 나쁜 지표 하나를 기준으로 원인을 분해한 뒤 한 번에 하나씩 배포해야 회귀 여부를 판단할 수 있다. 판교에서 사내 SaaS 대시보드를 돌리면서 배운 건, "전체적으로 다 느리다"는 진단은 실무에서 아무 쓸모가 없다는 점이었다. 지표마다 범인이 다르고, 고치는 순서를 잘못 잡으면 번들만 쪼개놓고 체감 속도는 그대로인 상황이 반복된다.
- 평가 기준은 Lighthouse 단일 실행 점수가 아니라 CrUX 28일 집계의 75백분위다 (출처)
- 2025년 7월 기준 모바일 LCP Good 비율은 62%에 그친다. 모바일을 기본 예산 대상으로 삼아야 하는 이유다 (출처)
- INP는 로드 시점 한 번이 아니라 방문 중 가장 느린 상호작용을 반영한다
- 번들 예산은 총량보다 초기 경로 전송량으로 쪼개는 편이 실용적이다
- 개선은 한 번에 하나씩 배포하고, 같은 URL·기기군·지역·기간으로 비교해야 회귀를 구분할 수 있다
이 글에서 다루는 실무 판단의 축은 "무엇을 먼저 고치느냐"다. LCP가 나쁜지, INP가 나쁜지, CLS가 나쁜지에 따라 첫 번째로 들여다봐야 할 코드가 완전히 달라진다. 내가 자주 본 실수는 Lighthouse 리포트에 뜨는 모든 항목을 동시에 손대려다가, 다음 배포에서 어떤 변경이 실제 개선을 만들었는지 영영 못 밝혀내는 경우였다.
LCP가 나쁘면 이미지부터 손대도 될까?
맞다, 다만 무작정 lazy-load를 걸면 역효과가 난다. LCP 후보인 hero 이미지는 발견과 다운로드가 늦어지지 않도록 preload 또는 fetch priority를 검토하고, 화면 아래쪽 이미지만 지연 로드하는 게 원칙이다. 여기에 반응형 이미지, WebP·AVIF, 적절한 해상도, 명시적 width·height를 같이 적용해야 전송량과 CLS를 동시에 관리할 수 있다. 서버 응답시간과 렌더 차단 CSS·폰트·스크립트도 LCP 분해 과정에서 빠지지 않고 확인해야 할 항목이다. 2025년 7월 측정에서 모바일 LCP는 Good 62%, Need Improvement 25%, Poor 13%였고 데스크톱은 74%/18%/7%였다 (출처). 이 분포는 모바일이 구조적으로 더 불리하다는 걸 보여주므로, 데스크톱에서만 측정하고 안심하면 실제 사용자 75백분위와 괴리가 생긴다.
INP가 나쁘면 코드 스플리팅부터 해야 할까?
초기 JavaScript가 크거나 INP가 나쁘면 라우트·기능 단위 동적 import가 1차 후보지만, 쪼개는 것 자체가 목적이 되면 안 된다. 2025년 공개된 분석에서는 동적 import 적용으로 초기 번들이 52% 감소하고, 일부 사례에서 TTI가 47% 줄었다고 보고한다 (출처). 다만 이 수치는 특정 구현과 네트워크 조건에 의존하는 사례값이지 일반 보장값이 아니다. 실무에서 자주 놓치는 부분은, 청크를 너무 잘게 쪼개면 요청 수와 네트워크 오버헤드가 늘고, 공통 의존성이 중복되면 전체 전송량이 오히려 커진다는 점이다. 또 INP는 페이지 방문 중 발생한 클릭·탭·키보드 상호작용을 관찰해 이상치를 제외한 가장 느린 값을 반영하므로, 초기 로드 최적화만으로는 부족하다. 메뉴 열기, 검색, 필터, 장바구니, 모달처럼 실제 핵심 플로우를 별도로 측정하고 메인 스레드의 긴 작업을 줄이는 작업이 같이 따라와야 한다 (출처).
CLS는 렌더 차단 자원 제거보다 레이아웃 고정이 먼저일까?
CLS가 나쁘면 이미지·광고·임베드의 고정 크기, 폰트 교체 공간, 지연 삽입 컴포넌트부터 고치는 게 먼저다. 렌더 차단 자원 제거는 '삭제'보다 '중요도 분리'로 접근해야 한다. 첫 화면에 필요한 CSS는 인라인 또는 우선 제공하고 나머지는 지연 로드하며, 비핵심 JavaScript는 defer·async 또는 사용자 상호작용 시점 로드로 분리한다. 단, 실행 순서 의존성이 있는 스크립트에 async를 무분별하게 적용하면 오히려 초기화 순서가 깨지는 버그가 생긴다. 폰트는 실제 사용 문자 집합으로 서브셋화하고, 교체 시 레이아웃이 흔들리지 않는지 확인해야 한다. 2025년 측정에서 모바일 CLS Good 비율은 81%로 LCP보다 양호해 보이지만, 여전히 Poor 집단이 존재하므로 평균만 보고 배포를 끝내면 안 된다 (출처).
번들 예산은 총량 300KB 같은 숫자로 관리해도 될까?
총량 하나로 관리하기보다 초기 경로 예산으로 쪼개는 편이 실용적이다. 2025년 공개된 분석은 평균 JavaScript 자산이 2017년 218KB에서 2023년 약 500KB로 늘었고, 엔터프라이즈 애플리케이션은 전체 JavaScript가 2MB를 넘는 경우도 있다고 보고한다 (출처). 이 수치는 동일 조건 실험이 아니라 문헌·사례를 종합한 값이라, 우리 프로젝트에 그대로 적용하면 안 된다. 대신 gzip·Brotli 전송량과 압축 해제 후 파싱량을 분리해서 기록해야 한다. "초기 번들 300KB"라는 문장은 압축 전인지 전송 후인지에 따라 의미가 완전히 달라지고, 프레임워크·번들러 버전, Node.js 버전, 빌드 모드, 모바일 CPU 에뮬레이션, 네트워크 프로필, 캐시 상태, 반복 횟수, 중앙값과 75백분위·최악값을 같이 남겨야 다음 배포와 비교가 가능해진다.
이 판단은 어떤 측정 조건에서 믿을 수 있나?
근거는 공식 기준값과 실측 분포, 두 가지로 나눠 봐야 한다. 공식 기준은 LCP 2.5초, INP 200ms, CLS 0.1이며 CrUX 28일 집계로 평가된다 (출처). 실측 분포는 HTTP Archive의 2025년 7월 측정치다.
| 기기 | LCP Good | Need Improvement | Poor |
|---|---|---|---|
| 모바일 | 62% | 25% | 13% |
| 데스크톱 | 74% | 18% | 7% |
같은 측정에서 모바일 INP Good은 77%, CLS Good은 81%였다 (출처). 한편 2026년 공개된 한 사례는 Laravel·Vue SaaS 대시보드에서 LCP 4.1초→1.9초, INP 320ms→120ms, CLS 0.18→0.03으로 개선하고 데모 예약이 22% 늘었다고 보고했다 (출처). 이 사례는 사이트명·트래픽 규모·대조군 여부가 확인되지 않은 보고라, 비즈니스 지표까지 이어진 인과관계로 단정하지 않는 편이 안전하다. 참고 사례로만 쓰고, 우리 프로젝트의 전후 비교는 직접 같은 조건에서 다시 재야 한다.
이 선택에서 자주 놓치는 함정은?
가장 흔한 함정은 Lighthouse 단일 실행 점수와 Search Console 실사용 데이터를 같은 숫자로 취급하는 것이다. 둘은 측정 방식이 다르므로 개선 전후를 같은 URL·기기군·지역·기간으로 비교하지 않으면 "배포했는데 수치가 안 바뀌었다"는 잘못된 결론에 도달한다 (출처). 또 Search Console은 28일 창을 사용하므로 즉시 회귀 감지용이 아니라 장기 확인용으로 써야 한다. CI 예산과 운영 RUM은 분리해서 운영하는 게 맞다. CI에서는 초기 JS·CSS·이미지 전송량과 주요 청크 크기를 반복 측정으로 검사하고, 기준선 대비 일정 비율을 초과하면 실패시키는 식으로 자동화하는 반면, 운영에서는 web-vitals 기반 RUM이나 CrUX로 실제 기기·지역별 75백분위 변화를 감시해야 한다. 서드파티 태그, 광고, A/B 테스트, 새 폰트처럼 배포 후 슬쩍 추가되는 자원은 변경 로그 없이는 원인 추적이 사실상 불가능하다. 마지막으로, 코드 스플리팅을 과도하게 적용해 청크가 지나치게 작아지면 요청 수가 늘고 공통 의존성이 중복되어 전체 전송량이 다시 커지는 함정도 반복해서 봤다.
그래서 실무에서는 무엇을 먼저 고르나?
선택 축을 정리하면 이렇다.
- LCP가 Poor면 hero 이미지 우선순위, 서버 응답시간, 렌더 차단 CSS·폰트부터 본다
- INP가 Poor면 라우트·기능 단위 코드 스플리팅과 메인 스레드 긴 작업 축소, 그리고 실제 핵심 플로우 측정을 더한다
- CLS가 Poor면 이미지·광고·임베드 고정 크기와 폰트 교체 공간부터 고친다
- 초기 JS 전송량이 크면 총량이 아니라 초기 경로 예산으로 쪼개 관리한다
- 모든 개선은 한 번에 하나씩 배포하고, 같은 조건에서 CI 예산과 운영 RUM으로 따로 회귀를 확인한다
2026년 기준으로도 이 순서는 달라지지 않는다. 다만 핵심 사용자 여정에는 공식 기준값(LCP 2.5초, INP 200ms, CLS 0.1)보다 더 엄격한 내부 예산을 별도로 두는 게, 측정과 개선을 연결하는 데 실질적으로 도움이 됐다.
핵심 정리
- Core Web Vitals는 Lighthouse 점수가 아니라 CrUX 28일 집계의 75백분위로 평가된다
- 2025년 7월 기준 모바일 LCP Good 비율은 62%로, 모바일을 기본 예산 대상으로 삼아야 한다
- LCP·INP·CLS는 원인이 다르므로 가장 나쁜 지표부터 분해하고 한 번에 하나씩 배포한다
- 번들 예산은 총량보다 초기 경로 전송량으로, gzip/Brotli 전·후를 구분해 기록한다
- CI 예산(배포 전 자동 검사)과 운영 RUM(배포 후 실사용자 감시)은 분리해서 운영한다