Core Web Vitals 나쁨 해결: LCP·INP·CLS 원인별 진단 순서
점수 플러그인부터 설치하지 않고 URL 그룹, CrUX 데이터, PageSpeed Insights와 DevTools를 이용해 실제 사용자 성능 병목을 찾는 기술 성능 가이드입니다.
Search Console에서 Core Web Vitals가 ‘나쁨’으로 표시되면 캐시 플러그인을 추가하기 전에 어떤 지표와 URL 그룹이 실패했는지부터 확인해야 합니다. LCP, INP와 CLS는 서로 다른 사용자 경험을 측정하므로 하나의 최적화로 모두 해결되지 않습니다.
Core Web Vitals 보고서는 실제 Chrome 사용자 경험 데이터에 기반하며, 충분한 데이터가 있는 비슷한 URL을 그룹으로 묶습니다. PageSpeed Insights의 실험실 점수가 좋아도 필드 데이터가 바로 바뀌지 않을 수 있고, 반대로 특정 기기·국가·템플릿에서만 문제가 생길 수 있습니다.
현재 기준과 데이터 출처를 구분합니다
| 지표 | 좋음 기준 | 측정 대상 |
|---|---|---|
| LCP | 2.5초 이하 | 가장 큰 콘텐츠가 표시되는 속도 |
| INP | 200ms 이하 | 사용자 상호작용 응답성 |
| CLS | 0.1 이하 | 예상치 못한 레이아웃 이동 |
기준은 페이지 로드의 75번째 백분위에서 평가합니다. 운영 판단은 Search Console·CrUX 같은 필드 데이터로 하고, 원인 추적은 Lighthouse·DevTools 같은 실험실 도구를 사용합니다.
1단계: 실패한 URL 그룹을 분리합니다
- 모바일과 데스크톱 보고서를 따로 봅니다.
- 나쁨·개선 필요 그룹의 대표 URL과 문제 지표를 기록합니다.
- 같은 템플릿, 광고 구성, 이미지 패턴을 공유하는지 확인합니다.
- 홈·글·카테고리·상품처럼 페이지 유형별로 재현합니다.
대표 URL 하나만 고치고 끝내지 마세요. 그룹의 공통 템플릿이나 컴포넌트가 원인일 수 있습니다.
LCP가 나쁠 때
LCP 후보 요소가 이미지인지 텍스트 블록인지 확인합니다. PageSpeed Insights와 Chrome DevTools Performance 패널에서 TTFB, 리소스 로드 지연, 다운로드 시간과 렌더링 지연을 나눕니다.
- 서버 응답이 느리면 캐시·DB·원본 서버와 CDN을 확인합니다.
- 대표 이미지가 늦으면 적절한 크기·포맷·압축과 우선순위를 조정합니다.
- LCP 이미지를 lazy-load하지 않고 HTML에서 일찍 발견되게 합니다.
- 렌더 차단 CSS·폰트·JavaScript를 줄입니다.
- 클라이언트 렌더링으로 핵심 콘텐츠가 늦게 생성되는지 봅니다.
INP가 나쁠 때
INP는 실제 상호작용 중 가장 느린 응답에 가까운 지표입니다. 긴 JavaScript 작업, 과도한 이벤트 핸들러, 복잡한 DOM과 서드파티 스크립트가 주요 후보입니다.
- Long Task를 찾아 작업을 작은 단위로 나눕니다.
- 사용하지 않는 JavaScript와 중복 라이브러리를 제거합니다.
- 채팅·광고·분석 스크립트의 실행 시점을 늦춥니다.
- 입력 처리 후 화면 갱신까지의 렌더링 비용을 줄입니다.
- 느린 상호작용을 실제 기기에서 기록합니다.
CLS가 나쁠 때
- 이미지·영상·iframe에 크기 또는 aspect-ratio를 지정합니다.
- 광고와 임베드 영역에 사전 공간을 예약합니다.
- 기존 콘텐츠 위에 배너를 동적으로 삽입하지 않습니다.
- 폰트 교체로 줄바꿈이 크게 바뀌는지 확인합니다.
- 사용자 동작 없이 펼쳐지는 UI와 애니메이션을 점검합니다.
워드프레스에서 우선 확인할 항목
| 계층 | 점검 |
|---|---|
| 테마 | 페이지 빌더 DOM, 대표 이미지 출력, 폰트와 CSS |
| 플러그인 | 캐시·최적화 기능 중복, 슬라이더, 팝업, 관련 글 |
| 광고 | 지연 로딩, 빈 슬롯 크기, 자동 광고 위치 |
| 서버 | TTFB, 객체 캐시, PHP worker, DB 쿼리 |
| 외부 스크립트 | 분석, 채팅, 폰트, 태그 관리자 |
최적화 플러그인을 여러 개 겹쳐 쓰면 CSS·JavaScript 순서가 깨지거나 캐시 무효화가 복잡해질 수 있습니다. 스테이징에서 한 변경씩 적용하고 전후를 기록합니다.
수정 후 검증 절차
- 실험실 환경에서 문제 지표와 원인 이벤트가 개선됐는지 확인합니다.
- 실제 기기와 느린 네트워크에서 회귀를 점검합니다.
- 배포 후 RUM 또는 CrUX 추세를 관찰합니다.
- Search Console에서 수정 확인을 시작합니다.
- 다음 28일 동안 데이터가 충분히 갱신되는지 봅니다.
한 번의 Lighthouse 점수 100점을 목표로 하지 마세요. 대표 템플릿과 실제 사용자 분포에서 안정적으로 좋은 경험을 제공하는 것이 목적입니다.
우선순위 정하기
- 트래픽과 전환이 큰 템플릿
- 나쁨 URL 그룹에 공통된 컴포넌트
- 적은 변경으로 여러 페이지에 적용되는 원인
- 사용자 경험과 수익에 동시에 영향을 주는 병목
Core Web Vitals 개선은 플러그인 점수 경쟁이 아니라 실제 사용자 데이터에서 병목을 찾아 제거하는 작업입니다. 필드 데이터로 문제를 확인하고 실험실 도구로 원인을 찾은 뒤, 한 변경씩 배포해 검증하세요.