측정·순위 · 공식 문서
페이지스피드 인사이트 점수가 서치 콘솔과 다른 이유
PageSpeed Insights 의 0~100 점수는 기기 하나를 흉내 낸 실험실 결과이고, 서치 콘솔은 지난 28일 실제 사용자 데이터를 URL 그룹으로 묶은 결과라서 숫자가 다릅니다. 무엇부터 고칠지는 실제 사용자 데이터로 정하고, 실험실 점수는 원인을 찾고 고친 효과를 바로 볼 때 씁니다.
PageSpeed Insights 모바일 점수는 낮은데 서치 콘솔은 「빠름」으로 나오는 경우가 있습니다. 둘 중 하나가 틀린 것이 아니라, 재는 대상과 방식이 다릅니다.
구글도 두 도구의 숫자가 다를 수 있다고 적었습니다. 이 편은 다른 이유와 어느 숫자를 믿을지를 다룹니다.
발견 01
두 도구의 숫자가 다른 이유는 10가지이고, 첫째는 실험실과 실제 사용자의 차이입니다
Note that the information in PageSpeed Insights might vary from the information in the Core Web Values report.
PageSpeed Insights 의 정보는 Core Web Vitals 보고서의 정보와 다를 수 있다.
| 이유 | PageSpeed Insights | 서치 콘솔 Core Web Vitals 보고서 | 공식 문서 원문 |
|---|---|---|---|
| 재는 방식 | 위쪽은 실제 사용자 데이터, 0~100 점수는 실험실(Lighthouse) 시뮬레이션 | 실제 사용자 데이터만 | The field data is a historical report about how a particular URL has performed, and represents anonymized performance data from users in the real-world on a variety of devices and network conditions. The lab data is based on a simulated load of a page on a single device and fixed set of network conditions. As a result, the values may differ.실제 사용자 데이터는 여러 기기와 네트워크의 실제 사용자에게서 모은 그 URL 의 과거 성능 기록이다. 실험실 데이터는 기기 하나와 고정된 네트워크 조건에서 페이지 로딩을 흉내 낸 것이다. 그래서 값이 다를 수 있다. |
| 재는 단위 | URL 하나 | 비슷한 페이지를 묶은 URL 그룹 | Core Web Vitals combines data and status into URL groups; PageSpeed Insights generally shows data for individual URLs (unless the URL doesn't have enough information by itself). The statistics for a specific URL in PageSpeed Insights might not match the group results in Core Web Vitals, because an individual URL might be an outlier in its group.Core Web Vitals 보고서는 데이터와 상태를 URL 그룹으로 묶고, PageSpeed Insights 는 대체로 URL 하나의 데이터를 보여 준다. URL 하나가 그룹 안에서 튀는 값일 수 있어 둘이 맞지 않을 수 있다. |
| URL 매개변수 | 매개변수를 떼고 기본 URL 에 합침 | 매개변수가 다르면 다른 페이지 | Core Web Vitals URLs include URL parameters when distinguishing the page; PageSpeed Insights strips all parameter data from the URL, and then assigns all results to the bare URL.Core Web Vitals 보고서는 URL 매개변수까지 넣어 페이지를 구분하고, PageSpeed Insights 는 매개변수를 모두 떼고 기본 URL 에 결과를 붙인다. |
| 데이터가 모자랄 때 | 사이트 전체(출처) 데이터로 대체 | 더 넓은 출처 그룹을 만들어 보여 줌 | When this happens, PSI will fall back to origin-level granularity, which encompasses all user experiences on all pages of the website. If a URL group doesn't have enough information to display in the report, Search Console creates a higher-level origin group that should contain enough URLs and data to show in the report.데이터가 모자라면 PageSpeed Insights 는 사이트 모든 페이지를 아우르는 출처 단위로 대체한다. 서치 콘솔은 URL 그룹 정보가 모자라면 더 넓은 출처 그룹을 만들어 보여 준다. |
| 실리는 URL | 입력한 어떤 공개 URL 이든 | 색인된 URL 중 데이터가 충분한 그룹만 | Only indexed URLs can appear in this report. If a URL group does not have a minimum amount of reporting data for both LCP and CLS, the URL is omitted from the report.색인된 URL 만 이 보고서에 나온다. LCP 와 CLS 데이터가 최소량에 못 미치는 URL 그룹은 보고서에서 빠진다. |
| 상태를 정하는 법 | 지표마다 따로 보여 줌 | 그룹에서 가장 나쁜 지표가 그룹 상태 | Once a URL group has a threshold amount of data for both LCP and CLS, the URL group's status is its most poorly performing metric.URL 그룹에 LCP·CLS 데이터가 기준량만큼 쌓이면, 그 그룹의 상태는 가장 성능이 나쁜 지표의 상태가 된다. |
| 기기 조건 | 모바일은 중급 기기와 모바일 네트워크를 흉내 냄 | 모바일·데스크톱 그룹에 상태를 따로 붙임 | Currently, Lighthouse simulates the page load conditions of a mid-tier device (Moto G4) device on a mobile network for mobile, and an emulated-desktop with a wired connection for desktop. The labels Poor, Need improvement, and Good are applied to a URL group for that specific device type.Lighthouse 는 모바일에서 중급 기기(Moto G4)와 모바일 네트워크를, 데스크톱에서 유선 연결의 데스크톱을 흉내 낸다. 느림·개선이 필요함·빠름 라벨은 기기 유형별로 URL 그룹에 붙는다. |
| 실행마다의 흔들림 | 실험실 점수는 돌릴 때마다 달라질 수 있음 | 없음 | Variability in performance measurement is introduced via a number of channels with different levels of impact. Several common sources of metric variability are local network availability, client hardware availability, and client resource contention.성능 측정값은 여러 경로로 흔들린다. 흔한 원인은 네트워크 상태, 기기 성능, 기기 자원 경합이다. |
| 방문자 지역 | 실험실은 구글 데이터센터 한 곳(북미·유럽·아시아 중)에서 실행 | 모든 지역의 요청을 합침 | Remember that data is combined for all requests from all locations.데이터는 모든 지역의 모든 요청을 합친 것이다. |
| 캐시와 스크롤 | 실험실은 빈 캐시로 첫 화면 로딩만 봄 | 재방문 캐시와 스크롤 중 밀림까지 포함 | Lab tests typically load a page with a cold cache, but when real users visit that page they may already have some of its resources cached. CLS measured in the lab only considers layout shifts that occur above the fold and during load, but this is only a subset of what CLS actually measures.실험실은 대개 빈 캐시로 페이지를 열지만, 실제 사용자는 일부 리소스를 이미 캐시에 갖고 있을 수 있다. 실험실 CLS 는 로딩 중 첫 화면의 밀림만 봐서 실제 CLS 의 일부일 뿐이다. |
| PageSpeed Insights 의 두 데이터 | 원문 |
|---|---|
| 한 페이지에 둘 다 | PSI provides both lab and field data about a page.PSI 는 한 페이지에 대해 실험실 데이터와 실제 사용자 데이터를 함께 보여 준다. |
| 실제 사용자 데이터 기간 | PSI reports real users' First Contentful Paint (FCP), Interaction to Next Paint (INP), Largest Contentful Paint (LCP), and Cumulative Layout Shift (CLS) experiences over the previous 28-day collection period.PSI 는 지난 28일 수집 기간 동안 실제 사용자가 겪은 FCP·INP·LCP·CLS 를 보여 준다. |
| 실험실 진단 | PSI uses Lighthouse to analyze the given URL in a simulated environment for the Performance, Accessibility, Best Practices, and SEO categories.PSI 는 Lighthouse 로 입력한 URL 을 모의 환경에서 분석해 성능·접근성·권장사항·SEO 카테고리를 본다. |
| 실험실 점수 구간 | A score of 90 or above is considered good. 50 to 89 is a score that needs improvement, and below 50 is considered poor.90점 이상은 좋음, 50~89점은 개선 필요, 50점 미만은 나쁨으로 본다. |
| 점수와 실제 경험 | Any green score (90+) is considered good, but note that having good lab data does not necessarily mean real-user experiences will also be good.녹색 점수(90점 이상)는 좋음으로 보지만, 실험실 데이터가 좋다고 실제 사용자 경험도 반드시 좋은 것은 아니다. |
발견 02
무엇부터 고칠지는 실제 사용자 데이터로 정하고, 실험실 점수는 원인 찾기에 씁니다
| 질문 | 볼 숫자 | 원문 |
|---|---|---|
| 코어 웹 바이탈이 재려는 것은 | 실제 사용자 데이터 | Core Web Vitals is a set of metrics that measure real-world user experience for loading performance, interactivity, and visual stability of the page.코어 웹 바이탈은 페이지의 로딩 성능, 상호작용, 시각적 안정성에 대한 실제 사용자 경험을 재는 지표 묶음이다. |
| 무엇부터 고칠까 | 실제 사용자 데이터(PageSpeed Insights 위쪽, 서치 콘솔) | As a general rule, if you have both field data and lab data for a given page, field data is what you should use to prioritize your efforts.한 페이지에 실제 사용자 데이터와 실험실 데이터가 둘 다 있으면, 작업 우선순위는 실제 사용자 데이터로 정한다. |
| 사이트 전체에 어떤 문제가 있나 | 서치 콘솔 Core Web Vitals 보고서 | The report is not designed find the status of a specific URL, but rather to see your site's performance as a whole, and troubleshoot issues affecting multiple pages on your site.이 보고서는 특정 URL 의 상태를 찾는 용도가 아니라, 사이트 전체 성능을 보고 여러 페이지에 걸친 문제를 고치는 용도다. |
| 고친 게 효과가 있나(바로) | PageSpeed Insights 실험실 결과 | Lab data is useful for debugging issues, as it is collected in a controlled environment. However, it may not capture real-world bottlenecks.실험실 데이터는 통제된 환경에서 수집되므로 문제를 찾는 데 유용하지만, 실제 환경의 병목은 잡지 못할 수 있다. |
| 실제 데이터는 좋은데 실험실 점수가 낮다 | 느린 기기·네트워크 사용자를 위한 개선 여지 | Lab data can sometimes help identify opportunities to expand your site's reach and make it more accessible to users with slower networks or lower-end devices.실험실 데이터는 느린 네트워크나 저사양 기기 사용자에게 사이트를 넓힐 기회를 찾는 데 도움이 될 때가 있다. |
실제 사용자 데이터가 아예 안 나오는 페이지도 있습니다. 크롬 사용자 데이터는 공개되고 색인 가능한 URL 에 표본이 충분해야 쌓입니다(원문: Chrome User Experience Report aggregates real-world speed data from opted-in users and requires that a URL must be public (crawlable and indexable) and have sufficient number of distinct samples that provide a representative, anonymized view of performance of the URL or origin.)
이때는 실험실 진단을 개선 단서로만 쓰고, 합격 여부는 데이터가 쌓인 뒤 서치 콘솔에서 봅니다.
발견 03
모바일 점수가 데스크톱보다 낮게 나오는 것은 실험실이 느린 기기와 네트워크를 흉내 내기 때문입니다
| 모바일·데스크톱 차이 | 원문 |
|---|---|
| 실험실 조건 | Currently, Lighthouse simulates the page load conditions of a mid-tier device (Moto G4) device on a mobile network for mobile, and an emulated-desktop with a wired connection for desktop.현재 Lighthouse 는 모바일은 모바일 네트워크의 중급 기기(Moto G4), 데스크톱은 유선 연결의 가상 데스크톱 조건으로 페이지 로드를 흉내 낸다. |
| 가장 큰 요소가 바뀜 | A lab test might identify a block of text as the LCP element because it's emulating a Moto G4 phone which has a relatively small viewport and your page's hero image is initially rendered off-screen.실험실은 화면이 작은 Moto G4 를 흉내 내서, 대표 이미지가 첫 화면 밖에 있으면 글 덩어리를 LCP 요소로 잡을 수 있다. |
| 실험실과 실제의 거리 | The particulars of any given lab test may or may not accurately represent the 75th percentile of field data for a given page or site.실험실 테스트 하나의 조건은 그 페이지나 사이트 실제 데이터의 75번째 백분위수를 정확히 대표할 수도, 못 할 수도 있다. |
| 서치 콘솔의 기기 구분 | The labels Poor, Need improvement, and Good are applied to a URL group for that specific device type.느림·개선이 필요함·빠름 라벨은 기기 유형별로 URL 그룹에 붙는다. |
모바일 점수가 낮다고 모바일 방문자가 모두 느끼는 것은 아닙니다. 실제 방문자의 기기가 실험실보다 좋으면 실제 사용자 데이터는 「빠름」일 수 있습니다.
반대로 방문자 대부분이 휴대전화로 들어오는 사이트라면 모바일 실제 사용자 데이터를 먼저 봅니다.
발견 04
web.dev 는 자기 페이지에서 실험실 LCP 3.0초, 실제 사용자 LCP 1.8초를 함께 보였습니다
| web.dev 페이지의 LCP | 원문 |
|---|---|
| 실제 사용자 중 좋음 | 88% of visits saw an LCP of 2.5 seconds or less (good).방문의 88%가 LCP 2.5초 이하(좋음)였다. |
| 실제 사용자 중 개선 필요 | 8% of visits saw an LCP between 2.5 and 4 seconds (needs improvement).방문의 8%가 LCP 2.5~4초(개선 필요)였다. |
| 실제 사용자 중 나쁨 | 4% of visits saw an LCP greater than 4 seconds (poor).방문의 4%가 LCP 4초 초과(나쁨)였다. |
| 실제 사용자 75번째 백분위수 | At the 75th percentile, LCP was 1.8 seconds:75번째 백분위수에서 LCP 는 1.8초였다. |
| 같은 페이지의 실험실 값 | Lab data from the same page shows an LCP value of 3.0 second.같은 페이지의 실험실 데이터는 LCP 3.0초였다. |
발견 05
B2B·B2C·B2G 사이트는 숫자가 갈릴 때 먼저 볼 이유가 다릅니다
예시 ① 해외 바이어가 많은 B2B 기업 사이트
서치 콘솔이 「개선 필요」인데 국내 사무실에서 PageSpeed Insights 는 좋게 나옵니다. 서치 콘솔은 모든 지역의 방문을 합치므로 먼 지역 방문자의 느린 경험이 섞입니다.
이미지와 파일을 방문자 가까이서 내려주는지부터 확인합니다.
예시 ② 필터 URL 이 많은 B2C 쇼핑몰
상품 목록 URL 에 정렬·필터 매개변수가 붙습니다. PageSpeed Insights 는 매개변수를 떼고 보고, 서치 콘솔은 매개변수별로 나눠 봅니다.
서치 콘솔에서 「느림」인 예시 URL 을 그대로 PageSpeed Insights 에 넣어도 같은 데이터가 안 나올 수 있으니, 그룹의 예시 URL 목록으로 판단합니다.
예시 ③ 방문자가 적은 공공기관 소속 기관 누리집(B2G)
페이지별 방문 표본이 모자라 PageSpeed Insights 는 사이트 전체 데이터를, 서치 콘솔은 출처 그룹을 보여 줍니다.
이때 숫자는 페이지 하나가 아니라 사이트 전체의 평균적인 경험입니다. 개선 대상은 실험실 진단으로 찾습니다.
그럼 숫자가 다를 때 어떤 순서로 확인하나요?
- PageSpeed Insights 결과에서 위쪽 실제 사용자 데이터와 아래쪽 실험실 점수를 나눠 봅니다. 서치 콘솔과 견줄 것은 위쪽입니다.
- 위쪽 데이터가 「이 URL」인지 「출처(사이트 전체)」인지 확인합니다.
- 서치 콘솔 보고서에서 모바일·데스크톱 중 어느 쪽인지, 어떤 URL 그룹의 어떤 지표가 가장 나쁜지 봅니다.
- 그룹의 예시 URL 을 PageSpeed Insights 에 넣되, 매개변수가 떨어진다는 점을 감안합니다.
- 위 10가지 이유 가운데 해당하는 것을 고르고, 고칠 순서는 실제 사용자 데이터로 정합니다.
- 고친 직후는 실험실로 확인하고, 합격은 서치 콘솔 「추적 시작」의 28일 확인으로 봅니다. 순서는 「페이지 속도 측정」 편에 자세히 적었습니다.
조사 방법
- Google for Developers 「About PageSpeed Insights」 (문서 수정일 2024-10-21) · 최종 확인일 2026-10-25 · https://developers.google.com/speed/docs/insights/v5/about
- Search Console Help 「Core Web Vitals report」 · 최종 확인일 2026-10-25 · https://support.google.com/webmasters/answer/9205520
- web.dev (Google Chrome) 「Why lab and field data can be different (and what to do about it)」 (문서 수정일 2022-07-18) · 최종 확인일 2026-10-25 · https://web.dev/articles/lab-and-field-data-differences
- Google Search Central 「Understanding Core Web Vitals and Google search results」 (문서 수정일 2025-12-10) · 최종 확인일 2026-10-25 · https://developers.google.com/search/docs/appearance/core-web-vitals
- 이유 10가지는 위 문서들이 두 데이터의 차이로 적은 문장을 항목별로 묶은 것입니다. 묶는 방식은 편집 판단입니다.
- 「방문자 지역」 줄의 PageSpeed Insights 쪽 설명은 「About PageSpeed Insights」 FAQ 의 데이터센터 실행 안내를 줄인 것입니다.
- 예시 ①②③은 이해를 돕기 위해 만든 가상 상황이며, 실제 기업·기관의 사례가 아닙니다. pv-4 의 숫자는 web.dev 문서가 든 공식 공개 사례입니다.
- 원문은 영어판(hl=en)이고, 상태·버튼 이름(빠름·개선이 필요함·느림·추적 시작)은 서치 콘솔 도움말 한국어판(hl=ko) 표기를 따랐습니다.