Core Web Vitals 진단｜LCP·INP·CLS 30분 개선 순서

Core Web Vitals는 페이지가 빨리 보이는지, 클릭에 제대로 반응하는지, 읽는 중 화면이 갑자기 움직이지 않는지를 실제 사용자 경험으로 측정합니다. PageSpeed 점수만 높이는 대신 LCP·INP·CLS 가운데 어느 지표가 어떤 URL 묶음에서 나쁜지 확인해야 수정 효과를 증명할 수 있습니다.

이 글은 기준값을 외우는 설명에서 끝나지 않고 현장 데이터 선택, 실험실 재현, 원인 한 가지 수정과 28일 추세 확인까지 이어지는 30분 진단 순서입니다.

10초 기준표

평가는 모바일과 데스크톱을 나눠 페이지 방문의 75번째 백분위로 판단합니다. 쉽게 말해 느린 일부 사용자까지 포함했을 때 방문 4회 중 적어도 3회가 좋은 기준 안에 들어오는지를 보는 방식입니다. CLS는 초가 아니라 단위가 없는 점수입니다.

현장 데이터와 실험실 결과를 섞지 않기

CrUX는 이전 28일을 매일 갱신하는 집계 자료라 오늘 수정한 결과가 즉시 바뀌지 않습니다. Search Console은 비슷한 경험의 URL을 묶으므로 예시 URL 하나가 빠르다고 그룹 전체가 해결된 것도 아닙니다. 반대로 Lighthouse 한 번의 나쁜 결과만으로 실제 사용자 전체가 실패했다고 단정할 수도 없습니다. 자세한 반영 방식은 Search Console 28일 데이터 읽는 법에서 확인하세요.

1단계: 문제 URL과 지표 하나 선택

1. Search Console에서 모바일과 데스크톱 중 실패한 쪽을 고릅니다.
2. 문제 그룹의 예시 URL과 같은 템플릿 URL을 2~3개 적습니다.
3. 세 지표를 동시에 고치지 말고 가장 나쁜 지표 하나를 선택합니다.
4. PageSpeed에서 URL 데이터인지 전체 출처 데이터인지 표시를 확인합니다.
5. 같은 URL을 같은 기기로 세 번 측정해 중간값과 반복 진단을 기록합니다.

점수가 흔들릴 때는 최고값이나 최저값을 사용하지 마세요. PageSpeed 세 번 측정과 중간값 진단 방식으로 일시적 서버 부하와 반복 병목을 분리합니다.

2단계: LCP를 네 구간으로 나누기

LCP가 나쁘면 먼저 실제 LCP 요소가 대표 이미지인지 제목·본문 블록인지 확인합니다. web.dev는 LCP 전체 시간을 TTFB, 리소스 발견 지연, 리소스 전송 시간, 요소 렌더 지연으로 나눠 볼 것을 안내합니다.

첫 화면 LCP 이미지는 지연 로딩 대상에서 제외하고, fetchpriority="high"는 실제 핵심 이미지 한두 개에만 검토합니다. 모든 이미지에 높은 우선순위를 주면 의미가 약해집니다. 파일 크기와 표시 크기는 워드프레스 이미지 최적화 5단계로 점검하세요.

3단계: INP는 실제 클릭을 재현

INP는 로드 점수가 아니라 사용자가 클릭·탭·키보드 입력을 한 뒤 다음 화면이 그려질 때까지의 반응성입니다. 메뉴 열기, 검색, 댓글 제출, 장바구니 버튼처럼 실제 사용이 많은 동작을 DevTools Performance에서 기록하세요.

• 입력 지연: 이전의 긴 JavaScript 작업이 클릭 처리를 막는지 확인합니다.
• 처리 시간: 이벤트 함수가 대량 DOM 변경·계산·동기 요청을 하는지 봅니다.
• 표시 지연: 처리 뒤 큰 레이아웃 계산과 렌더링이 이어지는지 확인합니다.

Lighthouse의 TBT는 INP와 같은 값이 아니라 실험실에서 메인 스레드 차단 가능성을 찾는 보조 신호입니다. 사용하지 않는 코드와 긴 작업은 JS 번들 Coverage 진단으로 줄이되 로그인·검색·결제 기능을 반드시 다시 시험합니다.

4단계: CLS는 로드 이후까지 관찰

CLS는 초기 화면만 아니라 페이지 수명 동안 발생한 예상하지 못한 이동을 반영합니다. 글을 아래로 스크롤하고 광고가 갱신될 때, 메뉴나 아코디언을 열 때, 웹폰트가 교체될 때까지 Performance 패널의 Layout Shifts를 확인하세요.

• 이미지·동영상에 width와 height 또는 비율을 지정합니다.
• 광고·임베드·추천글 영역은 예상 크기의 최소 공간을 확보합니다.
• 본문 위에 늦게 삽입되는 배너와 공지 위치를 바꿉니다.
• 대체 글꼴과 웹폰트의 글자 폭 차이와 줄바꿈을 확인합니다.
• 위치 애니메이션은 가능한 경우 top·left보다 transform을 사용합니다.

광고 공간을 무조건 크게 고정하면 빈 영역이 늘 수 있습니다. 실제 광고 크기 분포를 확인해 최소 높이를 정하고 모바일·데스크톱을 따로 테스트하세요. 폰트 문제는 웹폰트 WOFF2·preload·CLS 점검으로 이어서 확인할 수 있습니다.

30분 수정·검증 기록표

1. 0~5분: 기기·URL 그룹·나쁜 지표·75번째 백분위 값을 기록합니다.
2. 5~10분: 같은 URL을 세 번 측정하고 요소와 중간값을 적습니다.
3. 10~20분: 이미지 한 장, 스크립트 하나, 광고 슬롯 하나처럼 원인 하나만 수정합니다.
4. 20~25분: 로그인·메뉴·검색·폼·광고와 모바일 화면을 확인합니다.
5. 25~30분: 같은 조건으로 재측정하고 배포 시각과 원복 방법을 남깁니다.

실험실 결과는 수정 직후 비교할 수 있지만 현장 데이터는 새 방문이 28일 창에 누적되어야 합니다. Search Console 검증을 시작한 뒤에도 수정일, 배포 버전과 지표 추세를 함께 기록해야 개선과 자연 변동을 구분할 수 있습니다.

TIP

세 지표를 한 번에 고치려 하지 마세요. ‘모바일 글 상세의 LCP 이미지 요청이 늦다’처럼 기기·템플릿·지표·원인을 한 문장으로 적으면 플러그인을 무작정 켜고 끄는 일을 줄일 수 있습니다.

자주 묻는 질문

Core Web Vitals가 좋으면 검색 상위가 보장되나요?

아닙니다. Google은 관련성·유용성과 여러 페이지 경험 신호를 함께 봅니다. 좋은 수치는 사용자가 콘텐츠를 편하게 이용하도록 만드는 기준이지 순위를 보장하는 점수가 아닙니다.

PageSpeed에 현장 데이터가 없으면 어떻게 하나요?

해당 URL이나 출처의 CrUX 표본이 부족할 수 있습니다. Lighthouse와 DevTools로 재현 가능한 문제를 수정하고, 가능하면 자체 RUM을 수집하며 Search Console의 URL 그룹 추세를 확인하세요.

공식 자료

• Google Search Central Core Web Vitals 안내
• web.dev LCP 구간별 최적화
• web.dev INP 개선 방법
• web.dev CLS 원인과 개선

마무리

Core Web Vitals 개선은 점수 100점을 만드는 작업이 아닙니다. 현장 데이터에서 나쁜 URL 그룹과 지표 하나를 선택하고 실험실에서 요소를 재현한 뒤 한 가지씩 수정하세요. 기능 검증과 원복 방법을 남기고 28일 추세를 확인하면 실제 사용자 경험이 좋아졌는지 판단할 수 있습니다.