Core Web Vitals | 속도 느린 사이트가 검색에서 밀리는 이유
이 글은 "최적화 프로 가이드" 시리즈의 세 번째 글입니다. 최적화 프로 가이드는 커머스 운영자와 마케터를 위해, 실무에서 바로 써먹을 수 있는 SEO·AEO 핵심 주제를 한 편씩 다루는 단편 시리즈입니다. 이번 편에서는 페이지 로딩 속도가 크롤링과 검색 순위에 어떻게 영향을 미치는지, 그리고 Google이 속도를 측정하는 기준인 Core Web Vitals의 개념을 다룹니다.
3초 안에 안 열리면, 고객은 떠난다
오프라인 매장에 들어갔는데 점원이 30초 동안 아무 반응이 없다면 어떨까요? 대부분 돌아서 나갈 겁니다. 온라인에서는 이 인내심이 훨씬 짧습니다.
모바일 사용자의 절반 이상은 페이지가 3초 안에 로딩되지 않으면 이탈합니다. 그리고 로딩 시간이 1초 길어질 때마다 전환율은 약 7%씩 감소한다는 연구 결과가 있습니다. 월 매출 1억 원인 쇼핑몰이라면, 1초 느려지는 것만으로 연간 약 8,400만 원의 매출 손실이 발생하는 셈입니다.
그런데 페이지 속도는 단순히 "고객 경험"에만 영향을 주는 게 아닙니다. Google은 속도를 두 가지 경로로 활용합니다:
1. 크롤링: 사이트가 느리면 Googlebot이 더 적은 페이지를 크롤링
2. 랭킹: Core Web Vitals라는 속도 지표를 검색 순위의 한 요소로 사용
속도가 크롤링에 미치는 영향
이 부분은 특히 상품 수가 많은 커머스 사이트에서 중요합니다.
Google은 서버에 과부하를 주지 않기 위해, 사이트마다 크롤 속도 제한(Crawl Rate Limit)을 설정합니다. 이때 기준이 되는 것이 서버 응답 속도, 구체적으로는 TTFB(Time to First Byte)입니다.
TTFB는 "브라우저가 서버에 요청을 보낸 시점부터 첫 번째 데이터를 받기 시작한 시점까지의 시간"입니다. 쉽게 말해, 서버가 얼마나 빨리 반응하느냐를 측정합니다.
Google은 이 관계를 공식 문서에서 명확히 밝히고 있습니다:
- 서버가 빠르게 응답하면 → 크롤 속도 상한이 올라감 → 더 많은 페이지를 크롤링
- 서버가 느리게 응답하거나 에러가 많으면 → 크롤 속도 상한이 내려감 → 크롤링 감소
실제 수치로 보면, TTFB가 200ms인 서버와 2초인 서버를 비교하면, Google은 빠른 서버에서 5~10배 더 많은 페이지를 같은 시간에 크롤링합니다.
상품이 100개인 소규모 쇼핑몰에서는 이 차이가 크게 느껴지지 않을 수 있습니다. Google 공식 문서에서도 "페이지 수가 수천 개 미만인 사이트는 크롤 예산을 걱정할 필요가 없다"고 말합니다.
하지만 상품이 1,000개 이상이고, 옵션별 URL이 별도로 생성되며, 리뷰 게시판과 QA 페이지까지 합치면 수만 페이지가 되는 중대형 쇼핑몰에서는 크롤 예산이 실질적인 병목이 됩니다. 서버가 느려서 Google이 하루에 500페이지만 크롤링한다면, 나머지 페이지는 인덱싱 대기 상태에 놓이게 됩니다.
Core Web Vitals: Google이 속도를 측정하는 3가지 기준
2021년부터 Google은 Core Web Vitals라는 세 가지 지표를 검색 순위의 공식 요소로 포함시켰습니다. 이 지표는 "사이트가 얼마나 빠른가"를 좀 더 세분화해서 측정합니다.
LCP (Largest Contentful Paint) — 로딩 속도
"화면에서 가장 큰 콘텐츠가 보이기까지 걸리는 시간"
사용자가 페이지에 접속했을 때, 메인 이미지나 큰 텍스트 블록이 화면에 나타나는 순간까지의 시간입니다. 쇼핑몰로 치면, 상품 대표 이미지가 보이기까지 걸리는 시간이라고 생각하면 됩니다.
- 좋음: 2.5초 이하
- 개선 필요: 2.5초 ~ 4.0초
- 나쁨: 4.0초 초과
INP (Interaction to Next Paint) — 반응 속도
"사용자가 클릭/탭/키 입력을 했을 때, 화면이 반응하기까지 걸리는 시간"
2024년부터 기존의 FID(First Input Delay)를 대체한 새로운 지표입니다. 쇼핑몰에서 "장바구니 담기" 버튼을 눌렀을 때 바로 반응하느냐, 아니면 1~2초 멈춘 후 반응하느냐의 차이입니다.
- 좋음: 200ms 이하
- 개선 필요: 200ms ~ 500ms
- 나쁨: 500ms 초과
CLS (Cumulative Layout Shift) — 시각적 안정성
"페이지가 로딩되는 동안 레이아웃이 얼마나 흔들리느냐"
페이지를 읽고 있는데, 갑자기 광고가 끼어들면서 텍스트가 아래로 밀려나거나, 버튼 위치가 바뀌는 경험을 해본 적 있을 겁니다. 이런 "시각적 흔들림"을 측정하는 지표입니다. 쇼핑몰에서 구매 버튼을 누르려는데 배너가 밀어내서 다른 곳을 클릭하게 만드는 상황이 대표적입니다.
- 좋음: 0.1 이하
- 개선 필요: 0.1 ~ 0.25
- 나쁨: 0.25 초과
Core Web Vitals는 순위에 얼마나 영향을 주나?
솔직하게 말하면, Core Web Vitals만으로 순위가 극적으로 바뀌지는 않습니다. Google도 "콘텐츠의 관련성과 유용성이 가장 중요한 요소"라고 반복해서 말하고 있습니다.
하지만 동일한 콘텐츠 품질을 가진 경쟁 페이지들 사이에서는 결정적인 차이를 만들어냅니다. 이를 "타이브레이커(tiebreaker)" 효과라고 부릅니다.
"여름 린넨 셔츠 추천"이라는 키워드로 비슷한 품질의 콘텐츠를 가진 쇼핑몰 5곳이 경쟁하고 있다면, Core Web Vitals 점수가 좋은 사이트가 미세하게 위로 올라갑니다. 그리고 이 미세한 차이가 1페이지와 2페이지의 차이를 만들 수 있습니다.
또한 속도의 간접 효과도 무시할 수 없습니다:
- 빠른 사이트 → 이탈률 감소 → 체류 시간 증가 → Google이 "유용한 페이지"로 판단
- 느린 사이트 → 이탈률 증가 → 클릭 후 즉시 뒤로가기 → Google이 "기대에 못 미치는 페이지"로 판단
즉, Core Web Vitals는 직접적인 랭킹 요소이면서, 동시에 사용자 행동 신호를 통해 간접적으로도 순위에 영향을 줍니다.
커머스 사이트에서 속도를 잡아먹는 주범들
커머스 사이트는 속도 면에서 불리한 구조적 요인을 여러 개 가지고 있습니다.
최적화되지 않은 상품 이미지
가장 흔한 원인입니다. 스마트폰으로 찍은 원본 이미지(3~5MB)를 그대로 올리면, 상품 한 페이지에 이미지만 10~20MB가 됩니다. LCP를 직접적으로 악화시킵니다.
대응: 이미지를 WebP 포맷으로 변환하고, 적절한 크기로 리사이징. 화면 밖 이미지는 지연 로딩(lazy loading) 적용.
과도한 외부 스크립트
채팅 위젯, 리타겟팅 픽셀, 팝업 플러그인, 리뷰 위젯, SNS 공유 버튼 등 각각은 작지만, 누적되면 수십 개의 외부 JavaScript를 불러오게 됩니다. 이것들이 렌더링을 차단하고 INP를 악화시킵니다.
대응: 실제로 전환에 기여하는 스크립트만 남기고, 나머지는 제거하거나 지연 로딩 처리.
배너와 팝업에 의한 레이아웃 밀림
메인 페이지나 상품 상세 페이지에서, 이미지가 늦게 로딩되면서 가격이나 구매 버튼이 밀려나는 현상입니다. CLS를 직접 악화시킵니다.
대응: 이미지와 광고 영역에 고정 크기(width, height)를 지정하여, 로딩 전후로 레이아웃이 변하지 않도록 설정.
느린 서버 호스팅
공유 호스팅을 사용하면 TTFB가 500ms~2초까지 느려질 수 있습니다. 트래픽이 몰리는 시간대에는 더 심해집니다.
대응: 캐싱(Redis, CDN) 적용, 또는 호스팅 업그레이드 검토. 카페24의 경우 기본 제공되는 CDN을 활용하면 개선 가능.
진단 방법: 내 사이트의 속도 확인하기
PageSpeed Insights
가장 쉬운 방법입니다. Google이 공식으로 제공하는 도구로, URL만 입력하면 Core Web Vitals 점수와 개선 제안을 바로 보여줍니다.
https://pagespeed.web.dev/여기서 확인할 때 중요한 구분이 있습니다:
- 필드 데이터 (Field Data): 실제 사용자들의 Chrome 브라우저에서 수집된 데이터. Google이 순위에 실제로 사용하는 데이터입니다.
- 랩 데이터 (Lab Data): 테스트 환경에서 시뮬레이션한 데이터. 문제를 진단하는 데 유용하지만, 실제 순위에 직접 반영되지는 않습니다.
컨설팅에서 클라이언트에게 속도 문제를 보여줄 때는, 필드 데이터를 기준으로 말하는 것이 정확합니다.
Google Search Console
Search Console의 "Core Web Vitals" 보고서에서, 사이트 전체 페이지 중 "좋음", "개선 필요", "나쁨"에 해당하는 페이지 수를 확인할 수 있습니다.
이 보고서의 장점은 특정 페이지가 아니라 사이트 전체를 한눈에 볼 수 있다는 것입니다. "나쁨"으로 분류된 URL 그룹을 클릭하면, 어떤 지표가 문제인지, 어떤 페이지들이 해당되는지 구체적으로 확인할 수 있습니다.
브라우저 개발자 도구 (Lighthouse)
크롬에서 F12 → Lighthouse 탭에서 "Performance" 카테고리를 선택하고 분석을 실행하면, LCP, INP, CLS 점수와 함께 구체적인 개선 항목(이미지 최적화, 미사용 JavaScript 제거 등)을 보여줍니다.
F12 → Lighthouse 탭 → "Performance" 체크 → "Analyze page load" 클릭카페24·고도몰 사이트에서의 속도 관리
카페24와 고도몰은 서버 인프라를 플랫폼이 관리하기 때문에, TTFB나 서버 설정을 직접 최적화하기 어렵습니다. 하지만 콘텐츠 수준에서 개선할 수 있는 요소는 충분히 있습니다.
이미지 최적화: 카페24의 경우, 상품 등록 시 이미지를 자동 리사이징하는 기능이 있습니다. 하지만 상세페이지에 직접 삽입한 이미지(에디터로 작성한 상세 이미지)는 자동 최적화 대상이 아닙니다. 이 부분은 직접 최적화해서 업로드해야 합니다.
외부 스크립트 정리: 카페24 앱스토어에서 설치한 앱 중, 실제로 사용하지 않는 앱이 있다면 제거하세요. 앱을 "사용 안 함"으로 바꾸더라도, 일부 앱은 스크립트가 계속 로딩되는 경우가 있습니다.
스킨 최적화: 무거운 디자인 스킨은 그 자체로 속도를 떨어뜨립니다. 스킨을 바꾸기 어렵다면, 최소한 사용하지 않는 CSS/JS 파일이 불필요하게 로딩되는지 확인하세요.
Core Web Vitals, 어디까지 신경 써야 하나?
실무적 관점에서 정리하면:
"나쁨"에서 "좋음"으로 개선하는 것은 효과가 크다. 이탈률이 눈에 띄게 줄어들고, 크롤링 효율이 올라가며, 경쟁 키워드에서 미세한 순위 이점을 얻습니다.
"좋음"에서 "완벽"으로 올리는 것은 효과가 미미하다. LCP 2.3초를 1.8초로 줄이는 것보다, 같은 시간을 콘텐츠 품질 개선이나 구조화 데이터 작업에 쓰는 것이 ROI가 높습니다.
컨설팅에서 클라이언트에게 제안할 때도 이 기준이 유용합니다. "100점을 목표로 합시다"가 아니라, "빨간색(나쁨)을 녹색(좋음)으로 바꾸는 것이 목표입니다"가 현실적이고 설득력 있는 메시지입니다.
! 체크리스트: 페이지 속도 진단 한눈에 보기
[기본 진단]
□ PageSpeed Insights에서 모바일 기준 점수가 50점 이상인가?
□ Core Web Vitals 3가지(LCP, INP, CLS)가 모두 "좋음" 범위인가?
□ Google Search Console의 Core Web Vitals 보고서에서 "나쁨" 페이지가 없는가?
[커머스 사이트 중점 확인]
□ 상품 대표 이미지 용량이 200KB 이하인가?
□ 상세페이지 이미지가 WebP 등 최적화 포맷으로 업로드되어 있는가?
□ 사용하지 않는 외부 앱/스크립트를 정리했는가?
□ 이미지와 배너에 width/height 속성이 지정되어 있는가?
□ 모바일에서 페이지 로딩 시 레이아웃 밀림이 없는가?
[크롤링 관점 (대규모 사이트)]
□ Search Console 크롤 통계에서 응답 시간이 안정적인가?
□ 서버 에러(5xx)가 반복적으로 발생하지 않는가?
□ 크롤 통계에서 크롤링된 페이지 수가 감소 추세가 아닌가?Core Web Vitals를 깊이 파고들면 프론트엔드 개발 영역까지 들어가지만, 커머스 운영자와 마케터는 "어떤 지표가 무슨 의미이고, 내 사이트가 어디에 해당하는지"를 파악하는 것만으로도 충분합니다. 진단 결과를 바탕으로 개발팀이나 외부 업체에 구체적인 개선 요청을 할 수 있게 되기 때문입니다.