웹사이트 속도와 CORE WEB VITALS.
느리거나 화면이 들썩이는 웹사이트는 고객이 한 글자도 읽기 전에 고객을 잃습니다. Google은 이 경험을 세 가지 Core Web Vitals로 측정합니다. 각각의 의미, 내 사이트를 무료로 테스트하는 법, 그리고 소규모 비즈니스 사이트에서 대개 가장 중요한 개선 방법을 알려 드립니다.
최근 달라진 점
- Google, 뒤로 가기 버튼 가로채기를 스팸으로 간주 — 브라우저 뒤로 가기 버튼을 막는 것이 이제 명시된 스팸 행위입니다.
이 가이드는 변하지 않는 내용을 다룹니다. 변화는 블로그에서 나오는 대로 정리합니다.
세 가지 지표
Google은 Core Web Vitals를 로딩 성능, 상호작용성, 시각적 안정성에 대한 실제 사용자 경험을 측정하는 지표 모음으로 설명합니다.2 Interaction to Next Paint(INP)는 2024년 First Input Delay를 대신해 Core Web Vital이 되었습니다.1
| 지표 | 측정 대상 | 좋음 |
|---|---|---|
| Largest Contentful Paint(LCP) | 로딩: 주요 콘텐츠가 나타나는 시점 [1] | 2.5초 이하 [1][3] |
| Interaction to Next Paint(INP) | 반응성: 탭, 클릭, 입력에 페이지가 얼마나 빨리 반응하는지 [1] | 200밀리초 이하 [1][3] |
| Cumulative Layout Shift(CLS) | 시각적 안정성: 로딩 중 페이지가 얼마나 들썩이는지 [1] | 0.1 이하 [1][3] |
web.dev는 페이지 로드의 75번째 백분위수에서 모바일과 데스크톱을 따로 측정하라고 권장합니다.1 Search Console은 LCP 4초까지, INP 500 ms까지, CLS 0.25까지를 “개선 필요”로, 그 이상은 “나쁨”으로 평가합니다.3
순위에 영향을 주나?
Google은 좋은 Core Web Vitals가 더 넓은 페이지 경험의 일부로서 핵심 순위 시스템이 보상하려는 것과 일치한다고 말합니다.2 여러 고려 요소 중 하나일 뿐입니다. 빠르지만 내용이 부실하거나 도움이 안 되는 페이지가 더 나은 답을 이기지는 못하니, 속도는 이미 얻은 방문자를 붙잡는 수단으로 생각하세요.
사이트 테스트 방법
| 도구 | 보여 주는 것 | 주의할 점 |
|---|---|---|
| PageSpeed Insights | 실제 Chrome 사용자의 필드 데이터(CrUX)와 Lighthouse의 실험실 데이터, 모바일과 데스크톱 [4] | 필드 데이터는 최근 28일을 기준으로 하므로 개선 효과가 나타나기까지 시간이 걸리며, 실험실 결과와 필드 결과가 다를 수 있음 [4] |
| Search Console Core Web Vitals 보고서 | 실제 사용자 데이터를 바탕으로 비슷한 URL 그룹을 좋음, 개선 필요, 나쁨으로 평가 [3] | CrUX 데이터가 부족한 소규모 사이트는 “사용 가능한 데이터 없음”이 표시될 수 있음 [3] |
아직 필드 데이터가 없나요? PageSpeed Insights의 실험실 결과를 참고로 삼고, 가장 중요한 페이지인 홈, 서비스, 연락처를 테스트하세요.
소규모 비즈니스의 흔한 개선 방법
- 이미지를 줄이세요. 사진을 압축하고 최신 이미지 형식을 쓰세요.5 휴대폰으로 찍은 원본 사진은 보통 화면에 필요한 크기보다 훨씬 큽니다.
- 히어로 이미지는 지연 로딩하지 마세요. web.dev는 LCP 이미지를 절대 지연 로딩하지 말라고 하며,
fetchpriority속성으로 어떤 리소스가 가장 중요한지 브라우저에 알려 줄 수 있습니다.5 - 이미지와 임베드에 크기를 지정하세요.
width와height속성을 넣거나 CSSaspect-ratio로 공간을 확보해 콘텐츠가 밀리지 않게 하세요.6 - 웹 폰트를 미리 계획하세요. 폰트가 로딩되면서 바뀌면 글자가 움직일 수 있으니, 비슷한 대체 폰트를 고르세요.6
- 제3자 스크립트를 줄이세요. 채팅 위젯, 추적 코드, 임베드는 쌓이면 무겁습니다. web.dev는 뚜렷한 가치가 없는 스크립트는 없애고, 페이지 렌더링 전에 꼭 실행해야 하는 게 아니라면 제3자 스크립트를 비동기로 로드하라고 말합니다.7
- 클릭 처리 코드는 가볍게 하세요. INP를 위해 web.dev는 이벤트 콜백에서 가능한 한 적은 작업을 하고 긴 작업은 나누라고 권합니다.8
- 괜찮은 호스팅과 CDN을 쓰세요. web.dev는 파일이 이동하는 거리를 줄이기 위해 콘텐츠 전송 네트워크(CDN)를 권장합니다.5
속도는 쓰기 좋은 사이트의 한 부분입니다. 나머지 절반인 키보드, 스크린 리더, 화면 확대를 쓰는 사람들에 관해서는 웹사이트 접근성 가이드를 참고하세요.
FAQ
PageSpeed 점수는 낮은데 Search Console은 좋음이라고 합니다. 어느 쪽이 맞나요?
둘 다 맞을 수 있습니다. 점수는 시뮬레이션한 실험실 테스트에서 나오고, Search Console은 일정 기간 동안의 실제 방문자 데이터를 씁니다. Google은 실험실 데이터와 필드 데이터가 다를 수 있다고 설명합니다.4
완벽한 100점이 필요한가요?
아닙니다. 주요 페이지에서 위의 “좋음” 기준값을 목표로 하고, 나머지 시간은 콘텐츠와 고객에 쓰세요.
사이트가 빨라지면 리드가 늘어난다고 보장되나요?
누구도 그렇게 약속할 수 없습니다. 속도는 걸림돌을 없애 줄 뿐, 판매는 여전히 상품 구성, 리뷰, 후속 연락이 합니다.
출처
- web.dev, Web Vitals.
- Google Search Central, Understanding Core Web Vitals and Google search results(Core Web Vitals와 Google 검색 결과 이해하기).
- Search Console Help, Core Web Vitals report(Core Web Vitals 보고서).
- PageSpeed Insights documentation, About PageSpeed Insights(PageSpeed Insights 안내).
- web.dev, Optimize Largest Contentful Paint(LCP 최적화).
- web.dev, Optimize Cumulative Layout Shift(CLS 최적화).
- web.dev, Efficiently load third-party JavaScript(제3자 JavaScript 효율적으로 로드하기).
- web.dev, Optimize Interaction to Next Paint(INP 최적화).
더 읽어보기
전략 상담 예약
사이트가 왜 느린지 모르겠나요? 링크를 보내 주시면 무엇이 발목을 잡는지 함께 살펴봐 드립니다.