Lighthouse vs field data: 수정한 내용이 효과가 있는지 확인하기

Lighthouse에서는 해결되었다고 나오는데 왜 Search Console은 여전히 빨간색일까요?

Lighthouse는 시뮬레이션된 모바일 기기 1대에서 페이지를 한 번 로드하고, 그 1회 로드에 대한 LCP와 CLS를 보고합니다. 반면 Core Web Vitals는 field data입니다. 빠르거나 느린 스마트폰과 네트워크 환경, 비어 있거나 채워진 캐시, 모든 클릭까지 포함해 실제 Chrome 사용자가 방문한 28일 치 데이터 중 75번째 백분위수(p75)를 반영합니다. 따라서 오늘 문제를 수정해 Lighthouse를 통과하더라도 Search Console에 나타나기까지는 4주가 걸릴 수 있습니다. Lighthouse를 세 번 실행해 중간값을 비교한 다음, field data의 추이를 지켜보세요.

수정 전후를 비교하려면 Lighthouse를 어떻게 실행해야 할까요?

수정 전과 후에 동일한 방식으로 Lighthouse를 실행하세요:

1. 캐시를 비우세요. 변경 후에는 캐싱 플러그인과 CDN의 캐시를 비우세요. 그렇지 않으면 Lighthouse가 이전 페이지를 테스트합니다.
2. 도구는 하나만 정해 일관되게 사용하세요. 코드를 직접 보지 않는다면 PageSpeed Insights의 모바일 탭을 씁니다. 개발자라면 시크릿 창을 열고 Chrome DevTools의 Lighthouse 패널에서 기기를 모바일로 설정해 테스트하세요. 브라우저 확장 프로그램이 페이지에 자체 스크립트를 추가하기 때문입니다.
3. 경고가 발생한 URL을 테스트하세요. 상품 템플릿을 수정했다면 실제 상품 페이지를 테스트합니다.
4. 세 번 실행하고 중간 결과를 확인하세요.
5. 경고와 해당 지표를 먼저 확인하세요. 문제가 해결되면 경고 항목이 Passed audits로 이동하고, 관련 지표(LCP, CLS, Total Blocking Time) 수치가 내려갑니다. 점수는 가장 마지막에 확인하세요.

아무것도 바꾸지 않았는데 왜 점수가 달라질까요?

실행할 때마다 로드는 한 번씩 일어나며, 완전히 같은 로드는 없습니다. 서버 응답 속도가 달라질 수 있고, 네트워크 환경도 변하며, 광고나 쿠키 동의 배너, A/B 테스트 내용이 매번 다를 수 있습니다. 실제로 테스트해 본 한 페이지에서는 첫 텍스트나 이미지(FCP)가 실행에 따라 1.5초나 차이 나게 나타났고, 다른 페이지에서는 코드를 전혀 바꾸지 않았는데도 점수가 96점 또는 80점으로 나왔습니다. 따라서 수정 후 점수가 몇 점 올랐다는 사실만으로는 파악할 수 있는 내용이 거의 없습니다. 세 번 실행해 중간값을 비교해야 합니다.

동일한 URL(www.bbc.com)에서 2분 동안 연속 6회 실행한 결과 각각 38, 44, 41, 73, 60, 53점을 기록했습니다. Lighthouse 13.5.0, 모바일, PageSpeed Insights와 동일한 시뮬레이션 쓰로틀링 환경.

DevTools에서 트레이스 기록하기

Chrome에서 페이지를 열고 DevTools를 실행한 뒤 Performance 패널로 이동하세요. 캡처 설정(톱니바퀴 아이콘)에서 Network를 Slow 4G로, CPU를 4x slowdown으로 설정합니다. 모바일 환경에서 Lighthouse가 시뮬레이션하는 조건과 유사합니다. 그런 다음 Record를 클릭하고 페이지를 새로고침하세요. 사이드바의 Insights 탭에는 Lighthouse와 동일한 인사이트가 나열되며, 원인이 되는 요청과 요소도 각각 함께 표시됩니다. 트레이스를 기록하기 전에도 패널에는 현재 로드의 LCP, CLS, INP가 실시간으로 표시됩니다(INP는 페이지를 클릭하면 나타납니다). Field metrics 아래의 Set up을 클릭하면 동일한 URL에 대한 실제 방문자의 CrUX 수치가 그 옆에 나란히 표시됩니다.

Lighthouse와 Search Console의 측정 결과가 서로 다른 이유는 무엇일까요?

Lighthouse가 제공하는 데이터는 lab data입니다. 캐시가 비어 있는 상태에서 느린 4G 네트워크와 시뮬레이션된 중급 스마트폰 환경으로 페이지를 딱 한 번 로드합니다. 로드가 끝난 직후 측정을 멈추므로 스크롤을 내리거나 탭을 하거나 두 번째 페이지로 이동하지 않습니다. 따라서 그 1회의 로드에 대한 LCP와 CLS만 얻을 수 있으며, 클릭하는 방문자가 필요한 INP는 측정되지 않습니다.

field data는 실제 방문자를 대상으로 Chrome이 직접 측정한 데이터입니다. 빠르거나 느린 스마트폰, 좋거나 나쁜 네트워크, 캐시가 비어 있는 첫 방문부터 모든 리소스가 캐시된 열 번째 방문, 스크롤과 탭, 페이지 간 이동까지 전부 포함됩니다. Google은 사용 통계 공유에 동의한 Android 및 데스크톱 Chrome 사용자를 통해 이 데이터를 Chrome UX Report(CrUX)로 수집합니다. Core Web Vitals는 지난 28일간의 이러한 실제 방문을 바탕으로 각 지표의 75번째 백분위수(p75)를 집계한 값입니다. 즉, 전체 방문 4건 중 3건은 최소한 이 수치만큼 양호했다는 뜻입니다.

Google은 field data를 기준으로 검색 순위를 매깁니다. Lighthouse는 페이지가 왜 느린지, 수정한 내용이 효과가 있는지 파악하기 위한 도구입니다. 두 도구의 결과가 일치하지 않는다면 서로 다른 로드를 측정했기 때문입니다. Lighthouse 점수는 녹색(좋음)인데 field data가 불량하다면 시뮬레이션보다 성능이 낮은 기기를 사용하거나, 클릭 반응(INP)이 느리거나, 방문자가 스크롤할 때 콘텐츠 레이아웃이 밀리는 경우가 많습니다. 반대로 점수는 빨간색(나쁨)인데 field data가 양호하다면 실제 방문자의 기기와 네트워크 환경이 Lighthouse의 느린 4G 환경보다 훨씬 빠르고, 이미 브라우저 캐시에 파일이 저장된 상태로 재방문하기 때문인 경우가 많습니다.

2026년 10월 26일 www.bbc.com 모바일의 PageSpeed Insights 보고서입니다. 실제 방문자 데이터는 LCP 1.2초로 Core Web Vitals 세 개 지표를 모두 통과한 반면, 동일한 보고서의 Lighthouse 실행 결과는 37점, LCP 9.5초를 기록했습니다.

PageSpeed Insights는 방문 수가 충분한 경우 테스트한 URL의 field data를 보여주고, 방문 수가 부족하면 Origin(출처) 항목에 사이트 전체 데이터를 표시합니다. Search Console은 유사한 URL을 그룹으로 묶은 뒤, 해당 그룹에서 가장 나쁜 지표를 기준으로 상태를 평가합니다.

실제 방문자가 경험한 수치는 어디서 확인할 수 있을까요?

Google이 활용하는 field data인 CrUX는 4가지 무료 도구에서 확인할 수 있습니다:

• PageSpeed Insights: 상단 '실제 사용자가 겪고 있는 문제 확인하기' 섹션에서 특정 URL 또는 출처(origin)에 대한 최근 28일간의 LCP, INP, CLS(p75 기준)를 제공합니다.
• Search Console: 모바일 및 데스크톱용 Core Web Vitals 보고서에서 사이트 전체 중 성능이 미흡한 유사 URL 그룹을 보여줍니다.
• CrUX History report: 사이트 또는 특정 URL에 대한 데이터를 주 단위 막대로 표시하여 변화 추세를 보여줍니다.
• DevTools: Performance 패널에서 직접 측정한 로드 결과 옆에 동일한 수치를 나란히 표시해 줍니다(최초 1회 설정).

Chrome 방문 수가 너무 적은 사이트는 CrUX 데이터가 집계되지 않습니다. PageSpeed Insights 상단 섹션에 "데이터 없음(No Data)"으로 표시됩니다. CoreDash는 이러한 방문까지 모두 측정합니다.

CoreDash: 어떤 페이지, 어떤 요소인가

Google의 field data인 CrUX는 URL 또는 사이트당 단 하나의 p75 값만 제공합니다. 필자가 개발한 RUM 도구인 CoreDash는 페이지에 스크립트를 삽입해 모든 방문을 측정하고, 각 LCP, INP, CLS를 유발한 요소를 명확히 짚어냅니다. 페이지, 기기, 요소별로 필터링할 수 있으며, 코드를 변경한 뒤 다음 방문부터 시계열 차트에 변화가 즉시 반영됩니다. 전후 비교를 위해 코드를 수정하기 전에 스크립트를 먼저 추가하세요.

CoreDash, acme-pagespeed.com, 모바일, 페이지별 p75: 다른 페이지의 CLS는 모두 0이지만 한 페이지만 0.92를 기록했습니다.

수정한 내용이 Search Console에 반영되기까지 얼마나 걸릴까요?

PageSpeed Insights와 Search Console은 최근 28일간의 데이터를 보여주며, 이 집계 기간(윈도우)은 매일 하루씩 이동합니다. PageSpeed Insights의 데이터는 약 이틀 전 기준이고, Search Console은 그보다 며칠 더 늦습니다. 문제를 수정한 지 2주가 지나도 집계 기간의 절반은 여전히 수정 전 방문 데이터입니다. 4주가 지나야 비로소 수정 후의 방문 데이터만 채워집니다. 상세한 타임라인은 일별로 살펴보는 28일 윈도우에서 확인할 수 있습니다.

2026년 10월 26일 Search Console 모바일 Core Web Vitals 보고서: 10월 21일에 마지막으로 업데이트됨.

CrUX History report는 동일한 28일 집계 기간을 주 단위로 보여줍니다. 각 막대는 직전 28일간의 데이터를 다루므로, 수정 효과가 온전히 반영되려면 약 4개의 막대가 지나야 합니다.

ado-goldkante.de의 스마트폰 LCP CrUX History report: 주별 양호, 개선 필요, 불량 로드 비율. 8월 중순 수정 후 양호 비율이 막대 4개에 걸쳐 59%에서 76%, 83%, 90%, 93%로 상승했고, p75 LCP는 3.6초에서 1.5초로 개선되었습니다.

수정 사항이 배포되면 Search Console의 Core Web Vitals 보고서에서 해당 문제를 열고 Start Tracking(또는 Validate fix)을 클릭하세요. 그러면 Search Console이 동일한 field data를 바탕으로 해당 문제가 발생한 모든 URL에 대해 자체 28일 검증을 시작합니다. 진행되는 동안 상태는 Started로 표시되며, 지금까지 확인된 모든 URL에 문제가 없으면 Looking good으로 바뀝니다. 28일 동안 문제가 발생한 URL이 없으면 Passed로 끝나고, 여전히 문제가 남아 있는 URL이 하나라도 있으면 Failed로 끝납니다. 이 경우 해당 문제를 수정한 뒤 Start new validation을 클릭하세요.

수정한 내용이 실제 방문자에게 효과가 있었는지 어떻게 확인할 수 있을까요?

확인 속도가 가장 빠른 순서대로 점검하세요:

1. 수정 사항이 배포되었는지 확인하세요. 페이지 소스를 보거나 DevTools의 Network 패널에서 파일이나 헤더를 찾습니다. 여전히 이전 버전이 보인다면 캐싱 플러그인이나 CDN이 이전 페이지를 제공하고 있는 것입니다.
2. Lighthouse 통과를 확인하세요. 모바일 환경에서 세 번 실행해 중간값을 확인합니다(위 내용 참고). 경고 항목이 Passed audits로 이동해야 합니다.
3. 실제 방문자에게 반영되었는지 확인하세요. CoreDash에서 다음 방문부터 바로 확인합니다. 수정한 페이지나 템플릿으로 필터링하고 기기를 모바일로 설정한 뒤, 일별 지표와 원인이 되는 요소를 추적하세요.
4. CrUX가 뒤따라 반영됩니다. PageSpeed Insights의 field data와 CrUX History report의 막대가 조금씩 움직입니다. 완전한 효과는 4주 후에 나타납니다(4주가 걸리는 이유).
5. Search Console에서 확인을 마칩니다. Core Web Vitals 보고서에서 해당 문제의 Start Tracking을 클릭하고 Passed 상태가 될 때까지 기다리세요.

Lighthouse는 통과했고 4주가 지났는데도 field data가 전혀 움직이지 않습니까? 그렇다면 Lighthouse에서는 재현되지 않는 느린 방문 때문입니다. 저가형 스마트폰, 느린 클릭 반응, 페이지 중간으로 스크롤할 때 일어나는 레이아웃 이동 등이 여기에 해당합니다. Core Web Vitals power hour에서는 페이지 그룹별로 field data를 함께 살펴보며, 어떤 페이지의 어떤 요소가 p75 수치의 발목을 잡고 있는지 정확히 찾아냅니다.