Core Web Vitals 이상을 원인별로 분류하는 트리아지 가이드

Core Web Vitals 트리아지는 점수 하나를 낮추는 작업이 아니라 사용자가 겪는 지연을 원인별로 분류하는 작업입니다. 먼저 실제 사용자 필드 데이터에서 문제가 있는 URL과 기기를 찾고, 그 다음 실험실 재현으로 네트워크·메인 스레드·레이아웃 이동을 좁힙니다. Google은 현재 핵심 지표로 LCP, INP, CLS를 설명하며, 각 지표의 측정 의미와 권장 임계값은 공식 문서에서 확인할 수 있습니다.Web Vitals 기준

따라서 “LCP를 2.5초로 만들자”만 적은 티켓은 부족합니다. 어떤 URL·장치·배포 버전에서 어떤 자원이 병목이었고, 수정 뒤 어떤 측정값이 변해야 완료인지까지 기록해야 합니다. 필드와 실험실 결과가 다를 때는 어느 쪽을 버리지 말고 차이를 설명하는 것이 출발점입니다.

필드·실험실 증거를 같은 조건으로 정렬한다

LCP가 나쁘면 서버 응답, 렌더 차단 리소스, 큰 히어로 이미지, 클라이언트 렌더링을 후보로 둡니다. INP가 나쁘면 긴 자바스크립트 작업, 이벤트 핸들러, 입력 직후 레이아웃 작업을 봅니다. CLS는 이미지·광고·폰트가 자리를 예약하지 않았는지와 늦은 DOM 삽입을 확인합니다. 한 지표의 이름을 곧바로 한 원인으로 번역하지 않는 것이 트리아지의 첫 규칙입니다.

1. 필드: URL·국가·기기·브라우저·75백분위와 수집 기간

2. 실험실: 동일 네트워크 조건과 재현 영상·trace

3. 변경: 병목 자원, 수정 내용, 전후 측정과 롤백 기준

LCP·INP·CLS 결정 나무에서 한 원인을 선택한다

같은 URL에서 모바일과 데스크톱을 나누고, 캐시된 방문과 첫 방문을 구분합니다. 배포 전후의 코드·이미지·서드파티 목록을 함께 저장해야 결과를 비교할 수 있습니다. 여러 최적화를 한꺼번에 적용하면 점수는 좋아져도 무엇이 효과였는지, 장애가 생겼을 때 무엇을 되돌릴지 알 수 없습니다.

샘플: LCP 이상을 좁히는 기록

예시 입력은 모바일 필드에서 특정 랜딩 URL의 LCP가 나쁘고, 실험실 trace에서 hero.webp 요청이 늦은 상황입니다. 결정은 먼저 이미지 크기·포맷과 preload 필요성을 확인하고, 서버 응답과 이미지 요청 시간을 분리해 측정하는 것입니다. 중간 산출물은 URL·장치·LCP 분해값·변경 커밋·전후 결과 표이며, 기대 결과는 이미지 지연이 병목이라는 가설이 재현되고 수정 후 같은 조건에서 개선이 확인되는 것입니다.

표적 실험을 실행하고 영향 범위를 되돌린다

실패 사례는 실험실 점수가 좋아졌다는 이유로 광고나 개인화 스크립트를 바로 제거하는 것입니다. 실제 사용자 집단과 사업 기능의 영향을 확인하지 않아 다른 URL이나 전환 흐름을 망가뜨릴 수 있습니다. 복구는 변경을 작은 배포로 되돌리고, 영향을 받은 URL·장치·기능을 분리해 다시 측정하는 것입니다. 트래픽이 적은 페이지는 필드 데이터가 불안정할 수 있으므로 실험실 결과만으로 전체 사이트 품질을 단정하지 않습니다.

전후 측정과 롤백 기준으로 지표를 닫는다

완료 조건은 문제 URL과 사용자 조건이 고정되고, 원인 가설을 재현하는 trace 또는 네트워크 기록이 있으며, 한 가지 변경의 전후 측정과 롤백 기준이 남아 있는 상태입니다. 필드 지표는 충분한 수집 기간 뒤 다시 확인하고, 실험실 개선만으로 검증 완료라고 기록하지 않아야 트리아지 결과가 운영 가능한 증거가 됩니다.