웹사이트를 운영하다 보면 한 번쯤 이런 경험을 하게 됩니다. 열심히 글도 쓰고 키워드도 챙겼는데, 구글 검색 결과에서 내 사이트는 여전히 2페이지, 3페이지를 맴돕니다. 콘텐츠 퀄리티 문제일 수도 있지만, 의외로 사이트 속도와 사용성 때문인 경우가 꽤 많습니다.
구글은 2021년부터 Core Web Vitals(코어 웹 바이탈) 이라는 지표를 검색 순위 결정에 공식 반영하고 있습니다. 쉽게 말하면 "이 사이트, 사람들이 쓰기에 얼마나 쾌적한가?"를 점수로 매겨서 순위에 반영하는 겁니다.
이 글에서는 Core Web Vitals가 정확히 무엇인지, 어떻게 측정하는지, 그리고 실제로 개선하려면 뭘 해야 하는지 알아봅니다. 개발자가 아니어도 충분히 이해할 수 있도록 최대한 풀어서 씁니다.
Core Web Vitals, 세 가지만 기억하면 됩니다
구글이 정의한 Core Web Vitals는 세 가지 지표로 구성되어 있습니다. 각각 로딩 속도, 시각적 안정성, 반응 속도를 측정합니다.
LCP — 얼마나 빨리 '메인 내용'이 뜨나요?
LCP(Largest Contentful Paint) 는 페이지에서 가장 큰 이미지나 텍스트 블록이 화면에 완전히 표시되기까지 걸리는 시간입니다. 쉽게 말해 "메인 콘텐츠가 뜨는 속도"입니다.
- 좋음: 2.5초 이내
- 개선 필요: 2.5초 ~ 4.0초
- 나쁨: 4.0초 이상
블로그라면 썸네일 이미지나 제목 텍스트가, 쇼핑몰이라면 상품 이미지가 LCP 요소가 됩니다. 사용자 입장에서 생각해보면 당연합니다 — 아무것도 안 뜨는 하얀 화면을 4초씩 보고 있을 사람은 없으니까요.
CLS — 글 읽다가 버튼이 갑자기 튀어나온 경험 있으신가요?
CLS(Cumulative Layout Shift) 는 페이지 로딩 중에 요소들이 얼마나 예기치 않게 이동하는지 측정합니다.
- 좋음: 0.1 이하
- 개선 필요: 0.1 ~ 0.25
- 나쁨: 0.25 이상
사례를 들면 이해가 빠릅니다. 기사를 읽다가 광고가 갑자기 끼어들면서 읽던 위치가 확 내려간 경험, 버튼을 누르려는 순간 위에 이미지가 로드되면서 다른 버튼을 누른 경험 — 이게 전부 CLS가 높은 사이트에서 일어나는 일입니다.
INP — 버튼 눌렀는데 반응이 느린가요?
INP(Interaction to Next Paint) 는 사용자가 클릭, 탭, 키보드 입력 등을 했을 때 화면이 반응하기까지 걸리는 시간입니다. 2024년 3월부터 기존의 FID(First Input Delay) 지표를 대체했습니다.
- 좋음: 200ms 이내
- 개선 필요: 200ms ~ 500ms
- 나쁨: 500ms 이상
버튼을 눌렀는데 뭔가 반응은 했는데 화면이 바뀌기까지 0.5초가 걸린다면, 사용자는 "눌렸나? 다시 눌러야 하나?" 하게 됩니다. 이 불확실성이 쌓이면 사이트 신뢰도가 떨어집니다.
내 사이트 점수, 어떻게 확인하나요?
점수를 모르면 개선도 없습니다. 다행히 구글이 무료 도구를 여러 개 제공합니다.
PageSpeed Insights — 가장 빠른 방법
PageSpeed Insights에 내 사이트 주소를 입력하면 10초 안에 결과가 나옵니다. 모바일/데스크탑 점수를 따로 보여주고, 어떤 항목이 문제인지도 설명해줍니다.
한 가지 주의할 점은 이 도구가 실제 사용자 데이터(Field Data) 와 시뮬레이션 데이터(Lab Data) 를 함께 보여준다는 것입니다. 실제 사용자 데이터가 없으면 시뮬레이션 기반으로만 평가되는데, 신규 사이트는 처음에 이 데이터가 없을 수 있습니다. 이 경우 시뮬레이션 결과를 기준으로 개선해나가면 됩니다.
Google Search Console — 실제 방문자 기준 데이터
사이트에 Search Console이 연결되어 있다면 '코어 웹 바이탈' 메뉴에서 실제 방문자들이 경험한 수치를 확인할 수 있습니다. 이 데이터가 구글이 순위 평가에 실제로 사용하는 데이터입니다.
크롬 개발자 도구 — 개발자라면 여기서
크롬 브라우저의 개발자 도구(F12) > Lighthouse 탭에서도 확인할 수 있습니다. 로컬 환경에서 바로 테스트할 수 있어서 개선 전후 비교에 편리합니다.
실제로 어떻게 개선하나요?
지표별로 원인과 해결책이 다릅니다. 대표적인 케이스를 정리해봤습니다.
LCP 개선 — 이미지가 핵심
LCP를 느리게 만드는 가장 큰 원인은 이미지 최적화 부재입니다. 흔한 실수 두 가지만 잡아도 점수가 크게 오릅니다.
1. 이미지를 WebP 또는 AVIF 형식으로 변환하기
JPEG나 PNG는 오래된 형식입니다. 같은 품질에서 WebP는 JPEG 대비 25~34%, AVIF는 최대 50%까지 파일 크기를 줄일 수 있습니다. 구글에 따르면 이미지 최적화만으로 LCP를 30% 이상 개선한 사례가 다수 보고되어 있습니다.
2. 메인 이미지에 loading="eager" 처리하기
보통 이미지를 "나중에 불러오기(lazy load)" 처리하는데, 화면 상단에 바로 보이는 메인 이미지(히어로 이미지)에는 반대로 빠르게 불러오도록 설정해야 합니다. HTML로 쓴다면 이미지 태그에 fetchpriority="high"를 추가하면 됩니다.
Next.js를 사용한다면 next/image 컴포넌트가 이 두 가지를 자동으로 처리해줍니다. 이미지를 WebP로 변환하고, 히어로 이미지에는 priority 속성만 추가하면 끝입니다.
// 메인 이미지에는 priority 속성을 반드시 추가하세요
<Image
src="/hero.jpg"
alt="메인 배너"
width={1200}
height={600}
priority
/>
3. 서버 응답 속도 확인하기
이미지와 별개로 서버 자체가 느리면 LCP도 덩달아 느려집니다. TTFB(Time to First Byte) 라는 지표인데, 이게 600ms를 넘기면 아무리 이미지 최적화를 해도 LCP가 좋게 나오기 어렵습니다. CDN 사용이나 서버 위치 최적화로 해결할 수 있습니다.
CLS 개선 — 크기를 미리 잡아두기
CLS의 주범은 크기가 지정되지 않은 이미지와 늦게 로드되는 광고/임베드입니다.
이미지에 width, height를 명시하기
이미지 크기를 HTML에 미리 적어두면, 브라우저가 이미지가 로드되기 전에 해당 공간을 미리 확보해둡니다. 이미지가 뒤늦게 로드되어도 레이아웃이 흔들리지 않습니다.
<!-- 나쁜 예: 크기 없음 → 이미지 로드 시 레이아웃 변동 발생 -->
<img src="product.jpg" alt="상품 이미지">
<!-- 좋은 예: 크기 명시 → 공간 미리 확보 -->
<img src="product.jpg" alt="상품 이미지" width="400" height="300">
폰트 깜빡임(FOUT) 줄이기
웹폰트가 로드될 때 기본 폰트에서 웹폰트로 교체되면서 텍스트 크기가 바뀌고 레이아웃이 밀리는 현상이 있습니다. font-display: optional을 사용하거나, Next.js의 next/font를 쓰면 이 문제를 효과적으로 줄일 수 있습니다.
INP 개선 — 무거운 작업을 쪼개기
INP가 느린 가장 흔한 원인은 버튼 하나 클릭에 너무 많은 작업이 한꺼번에 실행되는 것입니다. 이는 주로 개발자가 해결해야 하는 부분이지만, 비개발자도 알아두면 좋은 포인트가 있습니다.
- 불필요한 서드파티 스크립트 줄이기: 채팅 위젯, 마케팅 추적 스크립트, SNS 공유 버튼 등 외부 스크립트가 많을수록 메인 스레드가 바빠져서 INP가 나빠집니다. 꼭 필요한 것만 남기고 지연 로딩(
defer,async) 처리를 해야 합니다. - 애니메이션은 CSS로: JavaScript로 만든 애니메이션은 메인 스레드를 사용하지만, CSS 애니메이션(
transform,opacity)은 GPU를 사용해서 메인 스레드 부하를 줄입니다.
자주 하는 실수 세 가지
현장에서 사이트를 분석하다 보면 반복적으로 보이는 패턴이 있습니다.
1. 모바일을 무시하는 경우
PageSpeed Insights 점수를 볼 때 데스크탑만 확인하는 경우가 많은데, 구글은 모바일 우선 색인(Mobile-First Indexing) 을 사용합니다. 모바일 점수가 더 중요합니다. 특히 한국은 모바일 트래픽 비중이 높아서 더욱 그렇습니다.
2. 한 번 개선하고 끝내는 경우
새 플러그인을 추가하거나 광고 배너를 붙이면 점수가 다시 떨어질 수 있습니다. 월 1회 정도 PageSpeed Insights로 체크하는 습관을 들이는 게 좋습니다.
3. 100점에 집착하는 경우
PageSpeed 100점이 목표가 되어서는 안 됩니다. 실사용자 경험이 좋고 Search Console의 코어 웹 바이탈 상태가 '좋음'이면 충분합니다. 점수 1~2점 올리려고 과도한 최적화를 하다 보면 코드가 복잡해지고 유지보수가 어려워집니다.
얼마나 개선하면 효과가 나타날까요?
구글은 "코어 웹 바이탈 점수가 좋으면 검색 순위 신호로 가점이 주어진다"고 밝히고 있습니다. 다만 콘텐츠 품질, 백링크 등 다른 요소와 비교했을 때 가중치는 크지 않습니다.
그러나 사용자 경험 측면에서 효과는 명확합니다. Google의 연구에 따르면 페이지 로딩 시간이 1초에서 3초로 늘어나면 이탈률이 32% 증가합니다. 아무리 좋은 콘텐츠도 로딩되기 전에 사용자가 떠나버리면 의미가 없습니다.
실제로 국내 한 쇼핑몰 사례를 보면, LCP를 4.8초에서 2.1초로 개선한 후 모바일 전환율이 약 15% 상승했다는 보고도 있습니다. 검색 순위 효과는 간접적이어도 실질적인 비즈니스 효과는 꽤 직접적입니다.
정리
Core Web Vitals는 구글이 "이 사이트가 사람들에게 실제로 쾌적한가?"를 판단하는 세 가지 척도입니다.
| 지표 | 측정 항목 | 좋음 기준 |
|---|---|---|
| LCP | 메인 콘텐츠 로딩 속도 | 2.5초 이하 |
| CLS | 레이아웃 안정성 | 0.1 이하 |
| INP | 클릭·탭 반응 속도 | 200ms 이하 |
시작은 단순합니다. PageSpeed Insights에 내 사이트 주소를 한 번 넣어보세요. 어떤 항목이 빨간불인지, 어떤 이유인지 바로 알 수 있습니다. 기술적인 부분은 개발자와 함께 체크리스트를 만들어 하나씩 해결해가면 됩니다.
사이트 속도는 방문자에 대한 예의이기도 합니다. 오래 기다리게 하지 않는 것, 클릭했는데 반응이 빠른 것 — 이런 당연해 보이는 것들이 쌓여서 신뢰가 됩니다.