페이지 속도(Page Speed)는 사용자가 웹페이지를 요청한 순간부터 화면에 콘텐츠가 표시되고 클릭이나 입력에 반응할 수 있게 되기까지 걸리는 시간으로, 구글이 검색 순위와 PageSpeed Insights 점수에 반영하는 성능 지표다.
구글은 2018년 1월 “2018년 7월부터 페이지 속도가 모바일 검색의 순위 요소가 된다”고 발표했고, 그 전에는 데스크톱 검색에만 속도를 반영하고 있었다 (Google Search Central Blog, Using page speed in mobile search ranking). 지금은 코어 웹 바이탈 세 지표가 페이지 속도를 대표하는 공식 측정값이다.
사이트 속도와 혼용되지만 범위가 다르다. 사이트 속도는 사이트 전체 페이지의 속도를 묶어 본 것이고, 페이지 속도는 URL 하나의 로딩과 반응 시간이다.
구글 PageSpeed Insights에 URL을 넣으면 무료로 측정된다. 구글은 이 도구를 “모바일과 데스크톱 기기 모두에서 페이지의 사용자 경험을 보고하고, 페이지 개선 방법에 관한 제안사항을 제공”하는 도구로 설명한다 (Google for Developers, PageSpeed Insights 정보).
두 영역은 데이터 출처가 다르다. 위쪽은 크롬 사용자 경험 보고서(CrUX)에서 가져온 “이전 28일 동안의 수집 기간 동안 실제 사용자의” 경험이고, 아래쪽은 Lighthouse가 느린 4G와 중저가 안드로이드 기기를 에뮬레이션해 그 자리에서 한 번 측정한 실험실 데이터다.
| 구분 | 실제 사용자 데이터(필드) | 실험실 데이터(랩) |
|---|---|---|
| 출처 | CrUX, 크롬 사용자의 실제 방문 | Lighthouse 시뮬레이션 |
| 기간 | 최근 28일 누적 | 측정 시점 1회 |
| 구글 순위 반영 | 반영됨 (코어 웹 바이탈) | 반영 안 됨 |
| 용도 | 합격 여부 판정 | 원인 진단과 개선 항목 확인 |
| 한계 | 방문이 적은 페이지는 “데이터 없음” | 실행마다 값이 흔들림 |
실험실 점수는 0에서 100 사이이고 “90점 이상의 점수는 좋습니다. 50~89점은 개선이 필요한 점수이며 50점 미만은 좋지 않은 점수로 간주됩니다”가 구글의 기준이다 (Google for Developers, PageSpeed Insights 정보).
이 점수는 다섯 지표의 가중 합이다. Lighthouse 10 기준 가중치는 다음과 같다 (Chrome for Developers, Lighthouse performance scoring).
| 지표 | 가중치 | 측정하는 것 |
|---|---|---|
| Total Blocking Time (TBT) | 30% | 메인 스레드가 막혀 입력에 반응 못 한 시간 |
| Largest Contentful Paint (LCP) | 25% | 가장 큰 콘텐츠가 그려진 시점 |
| Cumulative Layout Shift (CLS) | 25% | 화면 요소가 밀리는 정도 |
| First Contentful Paint (FCP) | 10% | 첫 콘텐츠가 그려진 시점 |
| Speed Index | 10% | 화면이 채워지는 속도 |
GTmetrix, WebPageTest 같은 서드파티 도구도 같은 Lighthouse 엔진으로 실험실 점수를 내므로 결과가 비슷하다. 다만 실제 사용자 데이터는 크롬 사용자 데이터를 가진 구글 도구와 서치콘솔의 코어 웹 바이탈 보고서에서만 볼 수 있다.
구글이 순위에 쓰는 기준은 코어 웹 바이탈 세 지표이고, 세 개가 모두 “좋음”이어야 통과다. 구글은 코어 웹 바이탈을 “로드 성능, 상호작용, 페이지의 시각적 안정성에 관한 실제 사용자 경험을 측정하는 측정항목”으로 정의한다 (Google Search Central, Core Web Vitals 및 Google 검색결과 이해하기).
| 지표 | 측정 대상 | 좋음 | 개선 필요 | 나쁨 |
|---|---|---|---|---|
| LCP | 로드 성능 | 2.5초 이하 | 2.5~4초 | 4초 초과 |
| INP | 상호작용 반응 | 200밀리초 이하 | 200~500밀리초 | 500밀리초 초과 |
| CLS | 시각적 안정성 | 0.1 이하 | 0.1~0.25 | 0.25 초과 |
기준값은 평균이 아니라 75번째 백분위수에 적용된다. web.dev는 “모바일 및 데스크톱 기기별로 구분하여 페이지 로드 횟수의 75번째 백분위수를 측정 기준으로 삼는 것이 좋습니다”라고 안내한다 (web.dev, Web Vitals). 방문 100번 중 75번째로 느린 방문이 2.5초 안에 LCP를 끝내야 LCP 통과다.
반응성 지표는 2024년에 바뀌었다. INP(Interaction to Next Paint)가 2024년 3월 12일 코어 웹 바이탈에 정식 편입되면서 First Input Delay(FID)를 대체했다 (web.dev, Interaction to Next Paint becomes a Core Web Vital on March 12). 2024년 이전 자료가 FID를 기준으로 쓰여 있으면 지금 기준과 맞지 않는다.
순위와 매출 양쪽에 영향이 있다. 구글은 페이지 경험 문서에서 “Google 검색 순위 시스템에서는 Core Web Vitals가 사용됩니다”라고 명시한다 (Google Search Central, Google 검색결과의 페이지 경험 이해하기).
다만 비중은 제한적이다. 2018년 발표 당시 구글은 이 신호가 “사용자에게 가장 느린 경험을 제공하는 페이지에만 영향을 주고 적은 비율의 질의에만 영향을 준다”고 했고, “검색 질의의 의도가 여전히 매우 강한 신호이므로 느린 페이지도 훌륭하고 관련성 높은 콘텐츠가 있으면 상위에 오를 수 있다”고 덧붙였다 (Google Search Central Blog, Using page speed in mobile search ranking). 페이지 경험 문서는 “검색엔진 최적화만을 위해 Core Web Vitals에서 완벽한 점수를 얻으려고 하는 것은 시간 낭비일 수 있습니다”라고도 적었다.
매출 쪽 근거는 더 직접적이다. 딜로이트가 유럽과 미국의 소매, 여행, 명품, 리드 생성 브랜드의 모바일 사이트를 분석한 결과, 속도를 0.1초 개선하자 “소매 전환율은 8.4%, 평균 주문 금액은 9.2% 증가했고 여행 전환율은 10.1% 증가”했다 (Deloitte, Milliseconds Make Millions).
이탈 쪽은 BBC 사례가 자주 인용된다. BBC는 “사이트 로드에 1초가 더 걸릴 때마다 사용자 10%를 추가로 잃었다”고 밝혔고, 보다폰은 LCP를 31% 개선해 판매를 8% 늘렸다 (web.dev, Why does speed matter?).
문제는 통과하는 사이트가 절반도 안 된다는 점이다. HTTP Archive가 2024년에 집계한 결과 모바일에서 코어 웹 바이탈 세 지표를 모두 통과한 웹사이트는 43%, 데스크톱은 54%였다 (HTTP Archive, Web Almanac 2024 Performance). 같은 조사에서 모바일 LCP 통과율은 59%, 데스크톱은 74%로 기기 격차가 컸다.
세 가지는 층위가 다르다. 페이지 속도는 개념이고, 코어 웹 바이탈은 그 개념을 구글이 순위에 쓰기 위해 고른 세 지표이며, PageSpeed Insights 점수는 그 지표를 포함한 다섯 항목을 실험실에서 재서 합산한 숫자다.
| 구분 | 페이지 속도 | 코어 웹 바이탈 | PageSpeed 성능 점수 |
|---|---|---|---|
| 성격 | 개념 | 구글의 공식 측정 지표 3개 | Lighthouse 합산 점수 0~100 |
| 데이터 | 둘 다 | 실제 사용자(75번째 백분위수) | 실험실 1회 측정 |
| 순위 반영 | 간접 | 직접 | 반영 안 됨 |
| 포함 지표 | 로드, 반응, 안정성 전반 | LCP, INP, CLS | FCP, SI, LCP, TBT, CLS |
실무에서 흔한 혼동은 성능 점수 90점을 순위 조건으로 보는 것이다. 순위에 쓰이는 것은 실제 사용자 데이터의 코어 웹 바이탈이고, 성능 점수는 진단용이다. 반대로 점수가 60점이어도 실제 사용자 데이터가 세 지표 모두 “좋음”이면 구글 기준으로는 통과다.
LCP부터 본다. 다섯 지표 중 LCP는 순위 지표이면서 성능 점수 가중치도 25%라 효과가 가장 넓다. web.dev는 LCP 개선을 네 부분으로 나눠 순서를 정하라고 안내한다 (web.dev, 최대 콘텐츠 렌더링 시간 최적화).
fetchpriority="high"나 preload로 우선순위를 올린다.서치폴라리스 위키 페이지를 2026년 10월 4일 PageSpeed Insights 모바일로 측정한 결과가 이 순서의 예시다. /wiki/geo/ 페이지는 성능 62점, FCP 5.1초, LCP 7.1초, TBT 100밀리초, CLS 0이 나왔고, 가장 큰 개선 항목은 “렌더링 차단 요청 예상 절감 시간: 3,600밀리초”였다. 실제 사용자 데이터는 방문 표본이 부족해 “데이터 없음”이었다.
이 결과를 읽으면 병목이 이미지 용량이 아니라 3번 렌더링 차단에 있다. 이미지 압축부터 손대면 LCP가 거의 안 움직이는 이유다. 자세한 항목별 대응은 테크니컬 SEO 문서를 참고한다.
pagespeed.web.dev에서 URL을 입력하면 된다. 사이트 전체를 한 번에 보려면 서치콘솔의 코어 웹 바이탈 보고서를 열면 URL 묶음별로 좋음, 개선 필요, 나쁨이 나뉘어 있다 (Google Search Central, Core Web Vitals 및 Google 검색결과 이해하기).
실험실 점수라서 그렇다. 구글은 점수 변동의 흔한 원인으로 “A/B 테스트나 광고 변경, 인터넷 트래픽 경로 변화, 다른 기기에서의 테스트, 브라우저 확장 프로그램”을 꼽는다 (Chrome for Developers, Lighthouse performance scoring). 합격 판정은 28일 누적 실제 사용자 데이터로 보고, 점수는 추세로 본다.
PageSpeed Insights 결과의 “인사이트”에서 예상 절감 시간이 가장 큰 항목부터 한다. 위 자사 측정처럼 렌더링 차단 요청이 3,600밀리초면 이미지보다 CSS와 스크립트 로드 순서가 먼저다.
서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.