느린 사이트가 검색에서 밀리는 진짜 조건

"속도 점수를 90점으로 올리면 검색 순위가 올라간다"는 말을 자주 봅니다. 구글 문서를 찾아 읽어 보니 조건이 붙어 있었습니다. 그리고 그 조건 때문에, 방문이 적은 사이트는 속도를 잡아도 순위가 움직이지 않습니다.

한 줄로 먼저

코어 웹 바이탈은 순위에 쓰입니다. 다만 실제 방문자에게서 모은 데이터로 계산하고, 방문이 적으면 그 데이터가 아예 만들어지지 않습니다. 없으면 작용할 신호도 없습니다. 그리고 점수는 그 데이터가 아닙니다.

구글이 실제로 적어 둔 문장

먼저 오해를 하나 걷어야 합니다. "페이지 경험"이라는 점수가 따로 있다고 생각하는 분이 많습니다.

단일 신호는 없습니다. 우리의 핵심 순위 시스템은 전반적인 페이지 경험에 부합하는 여러 가지 신호를 봅니다.
— Google 검색 센터, 페이지 경험 이해하기

그다음이 더 의외입니다. 페이지 경험으로 묶여 이야기되는 것들 중에서 순위에 직접 쓰이는 것은 코어 웹 바이탈뿐이라고 적어 두었습니다.

코어 웹 바이탈은 우리 순위 시스템이 사용합니다. … 코어 웹 바이탈 외의 다른 페이지 경험 요소는 검색 순위를 직접 올려 주지 않습니다.
— Google 검색 센터, 페이지 경험 이해하기

항목	순위에 직접 쓰이나
코어 웹 바이탈(LCP · INP · CLS)	쓰인다
HTTPS	아니다
모바일에서 잘 보이는지	아니다
본문을 가리는 전면 광고	아니다

안 해도 된다는 뜻이 아닙니다. 사람이 떠나면 결국 순위도 따라 내려갑니다. 다만 "HTTPS로 바꿨으니 순위가 오를 것"이라는 기대는 문서에 근거가 없습니다.

세 가지 지표와 기준선

지표	무엇을 재나	좋음	개선 필요	나쁨
LCP	가장 큰 것이 그려질 때까지 — 로딩	2.5초 이하	4초 이하	4초 초과
INP	눌렀을 때 화면이 반응할 때까지 — 반응성	200ms 이하	500ms 이하	500ms 초과
CLS	보는 중에 화면이 밀리는 정도 — 안정성	0.1 이하	0.25 이하	0.25 초과

전에 있던 FID는 2024년에 INP로 교체됐습니다. 아직 FID를 설명하는 글이 많은데 그 지표는 없어졌습니다.

진짜 조건 ① 평균이 아니라 75번째 백분위수

대부분의 사용자에게 권장 목표를 달성하고 있는지 확인하려면 페이지 로드의 75번째 백분위수를 측정하는 것이 좋은 기준이며, 모바일과 데스크톱을 나누어 봅니다.
— web.dev, Web Vitals

평균이 아닙니다. 느린 쪽 4분의 1을 잘라낸 자리가 기준입니다. 내 컴퓨터에서 빠른 것은 아무 의미가 없습니다. 그리고 모바일과 데스크톱이 따로 계산되니, 한쪽만 좋아도 통과가 아닙니다.

진짜 조건 ② 내가 잰 숫자가 아니라 남들이 겪은 숫자

서치콘솔의 코어 웹 바이탈 보고서는 내 사이트를 대신 측정해 주는 것이 아닙니다. 크롬 사용자 경험 보고서(CrUX)에 쌓인 실제 방문 기록을 가져옵니다.

항목	내용
출처	CrUX — 실제 방문자의 측정값(필드 데이터)
기간	최근 28일
단위	비슷한 페이지끼리 묶음으로 판정. 묶음 상태가 그 안의 모든 주소에 적용된다
데이터가 모자라면	그 주소는 보고서에서 빠진다

여기서 중요한 것은 마지막 줄입니다.

URL 그룹에 최소한의 보고 데이터가 없으면 그 URL은 보고서에서 제외됩니다.
— Search Console 도움말, 코어 웹 바이탈 보고서

진짜 조건 ③ 방문이 적으면 데이터 자체가 없습니다

CrUX에 들어가려면 자격이 있습니다. 두 가지입니다.

조건	뜻
공개적으로 발견 가능	200으로 열리고 `noindex`가 없고 크롤러가 들어올 수 있어야 한다
충분히 인기 있음	최소한의 방문자 수를 넘겨야 한다. 기준치는 공개하지 않는다

인기 기준을 충족하지 못하는 페이지와 출처는 CrUX 데이터셋에 포함되지 않습니다.
— Chrome 개발자 문서, CrUX 방법론

그래서 이렇게 됩니다. 방문이 적은 사이트는 CrUX에 없고, CrUX에 없으면 코어 웹 바이탈 값이 없고, 값이 없으면 그 신호는 순위에서 작용할 것이 없습니다.

작은 사이트에서 속도를 아무리 잡아도 순위가 안 움직이는 이유가 이것입니다. 잘못한 것이 아니라, 아직 그 신호가 켜지지 않은 것입니다.

그럼 PageSpeed Insights 90점은 뭔가

그 점수는 실험실 측정입니다. 그 자리에서 한 번 열어 보고 계산한 값입니다. 순위에 쓰이는 필드 데이터와는 다른 것이라서 어긋나는 것이 정상입니다.

특히 INP는 실험실에서 제대로 잡히지 않습니다. 사람이 실제로 눌러야 재지기 때문입니다.

INP는 일부 실험실 도구에서 측정할 수 있지만, 그 값은 측정 중에 어떤 상호작용을 했는지에 따라 달라집니다. … 웹사이트의 INP를 측정하는 가장 좋은 방법은 현장의 실제 사용자로부터 모으는 것입니다.
— web.dev, INP

필드 데이터가 없을 때는 TBT(총 차단 시간)를 대신 볼 만하다고 적혀 있지만, 문서도 "INP를 대체하는 것은 아니다"라고 못 박아 두었습니다.

	실험실(점수)	필드(순위에 쓰임)
누가 재나	도구가 한 번 열어 본다	실제 방문자
언제	지금	최근 28일
INP	제대로 안 잡힌다	잡힌다
방문이 없으면	그래도 점수는 나온다	아무것도 없다

방문이 없는 사이트에서도 점수는 90점이 나옵니다. 그 90점은 순위와 아무 관계가 없습니다.

그래서 무엇부터 하나

방문이 적은 사이트라면 — 글이 먼저입니다

순서를 바꿀 이유가 없습니다. 방문이 없으면 속도 신호도 없습니다. 속도를 잡는 일은 순위를 올리기 위해서가 아니라, 들어온 사람이 안 떠나게 하는 일입니다. 그것만으로도 충분한 이유지만, 기대하는 곳을 옮겨 두는 편이 낫습니다.

그래도 지금 잡을 값어치가 있는 것 — CLS

세 지표 중에서 가장 싸게 잡히는 것이 CLS입니다. 원인이 대개 몇 가지로 정해져 있습니다.

이미지에 크기를 적는다 — width · height가 없으면 그림이 내려온 순간 아래 글이 밀린다
광고 자리를 미리 비워 둔다 — 높이를 정해 두지 않으면 광고가 뜰 때 본문이 통째로 내려간다
글꼴이 바뀔 때 밀리지 않게 한다 — font-display: swap과 비슷한 크기의 대체 글꼴

LCP는 대개 첫 화면의 큰 그림 하나가 범인입니다. 그것만 줄이고 포맷을 바꿔도 많이 내려갑니다.

정리하면

"페이지 경험 점수"는 없습니다 — 단일 신호가 없다고 구글이 적어 두었습니다
순위에 직접 쓰이는 것은 코어 웹 바이탈뿐입니다 — HTTPS · 모바일 · 전면광고는 직접 올려 주지 않습니다
LCP 2.5초 · INP 200ms · CLS 0.1, 기준은 75번째 백분위수, 모바일과 데스크톱을 따로 봅니다
FID는 2024년에 INP로 바뀌었습니다
방문이 적으면 CrUX에 없고, 없으면 이 신호는 작용하지 않습니다
점수는 순위가 아닙니다 — 실험실 값과 필드 값은 다른 것을 잽니다
그래도 CLS는 잡아 두세요 — 가장 싸고, 사람이 가장 먼저 느낍니다

이어서 읽기

근거

Google 검색 센터 — 페이지 경험 이해하기 — "단일 신호는 없다" · 코어 웹 바이탈은 순위 시스템이 사용 · 그 외 페이지 경험 요소는 순위를 직접 올려 주지 않는다 (2026-09-22 갱신)
Google 검색 센터 — 코어 웹 바이탈과 검색결과 — LCP 2.5초 · INP 200ms · CLS 0.1
web.dev — Web Vitals — 75번째 백분위수, 모바일 · 데스크톱 분리 · INP가 2024년에 FID를 대체
web.dev — INP — 실험실 측정의 한계 · 현장 데이터 권장 · TBT는 대체가 아닌 대용
Search Console 도움말 — 코어 웹 바이탈 보고서 — CrUX 출처 · 최근 28일 · 묶음 단위 판정 · 데이터 부족 시 제외 · 좋음/개선 필요/나쁨 경계(LCP 2.5 · 4초, INP 200 · 500ms, CLS 0.1 · 0.25)
Chrome 개발자 문서 — CrUX 방법론 — 공개적으로 발견 가능 · 충분히 인기 있음, 기준 미달 시 데이터셋 제외

2026년 9월 29일에 구글 검색 센터 · web.dev · Search Console 도움말 · Chrome 개발자 문서 원문으로 확인했습니다. 지표와 기준은 해마다 바뀝니다 — FID가 그렇게 사라졌습니다. 작업 전에 한 번 더 보세요.