Search Console Core Web Vitals 반영 지연｜28일 데이터·검증 상태 읽는 법

속도를 개선했는데 Search Console Core Web Vitals가 계속 ‘개선 필요’로 남으면 실패했다고 생각하기 쉽습니다. 하지만 이 보고서는 방금 실행한 테스트가 아니라 실제 Chrome 사용자의 최근 28일 경험을 집계합니다. 오늘 수정한 결과가 다음 날 전체 기간을 대체하지 않는 것이 정상입니다.

단순히 28일을 기다리는 것이 아닙니다. 모바일·데스크톱, URL 그룹, 75번째 백분위수, 가장 나쁜 지표와 수정 확인 상태를 구분해야 기다릴 상황과 추가 수정할 상황을 나눌 수 있습니다.

10초 요약

• Search Console은 최근 28일의 실제 사용자 데이터를 사용합니다.
• 28일 이동 구간은 매일 갱신되므로 수정 효과가 조금씩 반영됩니다.
• 개별 주소가 아니라 비슷한 경험을 가진 URL 그룹 상태를 봅니다.
• LCP·INP·CLS 중 가장 나쁜 지표가 그룹 상태를 결정합니다.
• 수정 확인은 재색인이 아니라 28일간 문제 재발을 관찰하는 절차입니다.

Search Console이 느리게 바뀌는 이유

Chrome UX Report(CrUX)의 28일 이동 평균은 매일 갱신되지만 항상 직전 28일의 데이터를 포함합니다. 예를 들어 8월 1일에 개선했다면 다음 날 보고서에는 개선 후 하루와 개선 전 27일이 함께 들어갑니다. 시간이 지나면서 오래된 느린 경험이 빠지고 새로운 경험이 쌓여야 변화가 선명해집니다. 따라서 ‘정확히 28일 동안 아무 변화가 없다가 한 번에 바뀐다’는 뜻은 아닙니다.

확인 항목	보고서의 판단 방식	운영자가 볼 것
데이터 기간	직전 28일의 이동 구간	하루 값보다 7일·28일 추세
기기	모바일과 데스크톱 분리	문제가 표시된 기기부터 점검
판정 단위	비슷한 경험의 URL 그룹	예시 URL과 같은 템플릿 전체
대표값	방문 경험의 75번째 백분위수	평균값이 아닌 p75 상태
전체 상태	가장 느린 LCP·INP·CLS 적용	초록색이 아닌 최악 지표

URL 그룹과 75번째 백분위수 읽기

Search Console은 유사한 경험의 페이지를 묶어 그룹 LCP·INP·CLS를 표시합니다. 예시 URL 한 개가 그룹 전체는 아닙니다. 같은 테마, 광고 슬롯과 이미지 구조를 공유한다면 한 글만 고쳐도 그룹 상태가 유지될 수 있습니다.

p75는 전체 방문의 75%가 해당 값 이하를 경험했다는 의미입니다. 좋은 기준은 LCP 2.5초 이하, INP 200ms 이하, CLS 0.1 이하입니다. LCP와 INP가 좋아도 CLS가 나쁘면 그룹은 ‘나쁨’으로 표시됩니다. 자세한 지표 의미는 LCP·INP·CLS 기준과 개선 방법에서 확인할 수 있습니다.

PageSpeed 점수와 다른 이유

데이터	무엇을 보여주나	사용 목적
Search Console 현장 데이터	URL 그룹의 최근 28일 실제 경험	사이트 영역의 장기 추세 확인
PSI 현장 데이터	URL 또는 출처의 최근 28일 CrUX	개별 주소·출처의 실제 경험 확인
PSI 실험실 데이터	Lighthouse의 한 번의 모의 측정	LCP 요소·긴 작업 등 원인 진단
브라우저 직접 측정	현재 기기와 네트워크의 실행 결과	수정 직후 기능과 지표 확인

PageSpeed Insights의 위쪽 ‘실제 사용자 경험’도 CrUX 기반 28일 데이터이고, 아래쪽 성능 점수는 Lighthouse 실험실 결과입니다. 초록색 90점은 현재 모의 조건에서의 결과일 뿐 현장 데이터 통과를 보장하지 않습니다. 반대로 실험실 점수가 한 번 낮아도 현장 데이터가 즉시 나빠지는 것은 아닙니다. 점수 변동은 PageSpeed 3회 측정 기록표로 중간값을 비교하세요.

28일을 낭비하지 않는 점검 순서

1. 문제가 표시된 기기를 선택합니다. 모바일과 데스크톱은 별도 상태이므로 방문 비중과 문제 등급을 함께 봅니다.
2. ‘나쁨’을 먼저 엽니다. 영향을 받는 URL 수가 많거나 중요한 페이지 그룹을 우선합니다.
3. 예시 URL과 그룹 구성원을 확인합니다. 상단 주소 하나만 보지 말고 같은 템플릿·광고·이미지·스크립트를 공유하는 페이지를 찾습니다.
4. 실험실 테스트로 원인을 재현합니다. 같은 기기 유형으로 세 번 측정하고 LCP 요소, 긴 작업, 레이아웃 이동을 기록합니다.
5. 공통 원인 하나만 수정합니다. 대표 이미지 크기, 광고 공간, 웹폰트, JS 실행 중 영향 범위가 큰 항목부터 바꿉니다.
6. 수정한 기능을 직접 검증합니다. 메뉴·검색·폼·광고·로그인과 모바일 레이아웃이 정상인지 확인합니다.
7. 기록 후 관찰합니다. 수정일과 항목을 남기고 검증 기간에 관련 설정을 계속 바꾸지 않습니다.

증상별 다음 행동

현재 상태	가능한 이유	다음 행동
실험실은 개선됐지만 그룹은 그대로	이전 28일 데이터와 다른 그룹 URL	그룹 구성원 확인 후 추세 관찰
모바일만 개선 필요	느린 기기·네트워크·모바일 광고	모바일 조건으로 원인 재현
PSI에 URL 현장 데이터 없음	해당 URL의 표본 부족	출처 데이터 여부 확인, 실험실 진단 병행
보고서 전체가 데이터 없음	새 속성 또는 CrUX 표본 부족	색인과 트래픽을 확인하며 개별 URL 측정
갑자기 여러 그룹이 악화	경계값, 트래픽·기기 구성, 공통 자원 변화	변경 기록과 서버·이미지 지연 비교

LCP가 대표 이미지 때문에 느리다면 형식 변환만 반복하지 말고 표시 크기, 원본 크기, preload와 지연 로딩 여부를 확인하세요. 워드프레스 이미지 최적화 점검 순서를 이용하면 그룹에 공통으로 적용된 이미지 문제를 확인할 수 있습니다.

수정 결과 확인은 무엇을 할까?

문제를 해당 URL들에서 수정했다고 판단되면 상세 화면에서 추적을 시작할 수 있습니다. 공식 안내에 따르면 이 동작은 재색인이나 즉시 속도 테스트를 실행하지 않습니다. Search Console이 28일 동안 CrUX 데이터에서 같은 문제가 나타나는지 관찰하는 절차입니다. 기간 중 어느 URL에서든 문제가 확인되면 전체 확인이 실패할 수 있지만, 개별 URL 평가는 기간 끝까지 계속됩니다.

• 시작됨: 확인을 시작했고 아직 남은 문제가 발견되지 않은 상태입니다.
• 양호: 지금까지 검사한 문제 사례가 해결된 상태입니다.
• 통과: 확인 대상이 모두 통과한 상태입니다.
• 실패: 하나 이상의 URL에서 같은 문제가 계속 발견된 상태입니다.
• 해당 없음: 확인을 시작하지 않았지만 Google이 문제가 사라진 것을 확인한 상태입니다.

실패하면 예시 URL과 그룹 구성원을 다시 열고 같은 광고 위치, 이미지, 폰트와 스크립트가 남아 있는지 확인하세요. 원인을 고치지 않은 채 ‘새 확인’을 반복해도 현장 데이터는 바뀌지 않습니다.

TIP

“속도 플러그인 변경”처럼 넓게 적지 말고 “본문 첫 이미지 320KB→78KB, 모바일 LCP 세 번의 중간값 3.4초→2.2초”처럼 기록하세요. 수정일, 대상 URL 그룹, 기기, 변경 항목, 실험실 중간값을 한 줄에 남기면 28일 뒤 어떤 조치가 효과가 있었는지 판단하기 쉽습니다.

자주 묻는 질문

개선 후 반드시 28일을 모두 기다려야 하나요?

보고서는 매일 갱신되는 28일 이동 구간이므로 중간에도 추세가 달라질 수 있습니다. 다만 수정 전 데이터가 구간에서 빠지고 충분한 새 사용자 경험이 쌓여야 최종 상태를 판단할 수 있습니다.

데이터 없음은 색인 오류인가요?

반드시 그렇지는 않습니다. 새 속성이거나 선택한 기기 유형의 CrUX 표본이 부족할 수 있습니다. Core Web Vitals 보고서에는 색인된 URL만 나올 수 있지만 모든 색인 URL이 반드시 표시되는 것은 아닙니다.

공식 자료

• Google Search Console Core Web Vitals 보고서
• Chrome UX Report 도구별 데이터 방식
• Google PageSpeed Insights 현장·실험실 데이터 안내
• Google Search의 Core Web Vitals 안내

마무리

Search Console Core Web Vitals 반영이 늦을 때는 하루의 PageSpeed 점수와 28일 현장 데이터를 구분해야 합니다. 문제가 표시된 기기와 URL 그룹의 최악 지표를 찾고, 공통 원인 하나를 수정한 뒤 같은 조건으로 기록하세요. 실제 사용자 경험이 좋아져야 보고서도 안정적으로 바뀝니다.