점수보다 분포를 먼저 읽습니다
Core Web Vitals의 ‘좋음’ 기준은 LCP 2.5초 이하, INP 200밀리초 이하, CLS 0.1 이하이며 일반적으로 75번째 백분위수로 평가합니다. 평균값만 보면 느린 기기와 네트워크에서 반복되는 실패를 감출 수 있습니다.
표본이 적은 URL은 페이지 단위 수치보다 같은 템플릿의 URL 그룹을 먼저 봅니다. 그다음 랜딩, 상세, 결제처럼 사용자 가치와 가까운 흐름을 분리하면 작은 개선이 어디서 큰 효과를 내는지 보입니다.
LCP는 하나의 시간값이 아니라 전달 경로입니다
LCP 요소가 늦게 발견되면 이미지 압축만으로는 충분하지 않습니다. 서버 응답, HTML에서의 리소스 발견, 우선순위, 전송 시간, 렌더링 지연을 나눠 보고 가장 긴 구간을 고칩니다.
대표 이미지는 초기 HTML에서 찾을 수 있게 하고 실제 표시 크기에 맞는 후보를 제공합니다. 중요한 이미지에 무분별한 지연 로딩을 적용하거나 클라이언트 렌더링 뒤에야 URL을 만드는 패턴은 피합니다.
- TTFB가 길면 캐시·서버·리다이렉트를 먼저 확인
- 발견 지연이면 HTML·preload·fetch priority 확인
- 렌더링 지연이면 CSS·폰트·메인 스레드 확인
INP는 가장 느린 상호작용의 공통 원인을 찾습니다
INP는 클릭 하나의 속도가 아니라 방문 중 상호작용 응답성을 요약합니다. 느린 입력을 재현할 때 이벤트 처리 시간뿐 아니라 다음 프레임이 실제로 그려질 때까지 살펴야 합니다.
긴 자바스크립트 작업을 쪼개고 입력 직후 꼭 필요한 상태만 갱신합니다. 서드파티 스크립트, 대규모 DOM 변경, 동기식 레이아웃 측정이 같은 구간에 모이지 않게 설계합니다.
CLS는 공간 예약 규칙으로 예방합니다
이미지와 임베드에는 크기 또는 aspect-ratio를 지정하고, 늦게 들어오는 배너는 빈 공간을 미리 확보합니다. 폰트 교체가 줄바꿈을 바꾸면 메트릭이 크게 흔들릴 수 있으므로 대체 폰트의 폭도 맞춥니다.
실험 배너나 개인화 모듈처럼 조건부 UI는 기존 콘텐츠 위에 삽입하지 않습니다. 오버레이 또는 예약된 슬롯을 사용하고, 사용자의 입력으로 일어난 예측 가능한 이동과 자동 이동을 구분합니다.
한 번에 한 템플릿씩 검증합니다
변경 전 기준선, 배포 SHA, 대상 URL 그룹, 예상 효과를 기록합니다. 실험 기간에는 같은 지표에 영향을 주는 다른 변경을 묶지 않아야 결과를 설명할 수 있습니다.
실험실 데이터는 회귀를 빠르게 찾는 데, 실제 사용자 데이터는 성공 여부를 판단하는 데 사용합니다. 두 데이터가 다르면 어느 하나를 버리기보다 기기·지역·캐시·상호작용 조건의 차이를 조사합니다.
배포 전 체크리스트
- ✓ 75번째 백분위수의 실제 사용자 데이터와 표본 크기를 확인했는가?
- ✓ 가장 중요한 사용자 흐름과 URL 템플릿을 분리했는가?
- ✓ LCP를 발견·전송·렌더링 구간으로 나눴는가?
- ✓ 느린 INP 상호작용의 긴 작업과 렌더링 지연을 기록했는가?
- ✓ 이미지·임베드·조건부 UI의 공간을 예약했는가?
자주 묻는 질문
Lighthouse 점수가 좋아지면 Core Web Vitals도 통과하나요?
아닙니다. Lighthouse는 통제된 실험실 측정이고 Core Web Vitals 평가는 실제 사용자 분포를 사용합니다. 회귀 탐지와 원인 분석에는 Lighthouse를, 결과 판단에는 필드 데이터를 함께 쓰세요.
세 지표 중 항상 LCP가 우선인가요?
아닙니다. 실패 비율, 사용자 가치, 개선 가능성으로 정합니다. 결제 입력의 심각한 INP 문제는 조금 느린 콘텐츠 페이지의 LCP보다 먼저 고칠 가치가 있습니다.