누군가 사이트 속도를 측정해 54점이 나왔다며 느리다고 합니다. 다른 도구는 91점을 줍니다. 두 숫자 모두 방문자가 실제로 어떻게 느끼는지는 알려 주지 않으며, Google이 쓰는 것은 바로 그 실제 경험입니다.
Core Web Vitals는 사이트의 실제 방문에서 얻은 세 가지 측정값입니다. 페이지를 기다리는 것, 눌러도 반응 없는 버튼, 로딩 중에 튀는 콘텐츠처럼 사람들이 직접 느끼는 문제를 나타내므로 알아 둘 가치가 있습니다.
세 가지 측정값
Largest Contentful Paint(LCP): 주요 콘텐츠, 대개 가장 큰 이미지나 제목이 나타나기까지 걸리는 시간입니다. 2.5초 이하면 좋음입니다.
Interaction to Next Paint(INP): 누군가 탭하거나 클릭하거나 입력했을 때 페이지가 얼마나 빨리 반응하는지입니다. 200밀리초 이하면 좋음입니다. 2024년에 First Input Delay를 대체했습니다.
Cumulative Layout Shift(CLS): 사용하는 동안 레이아웃이 예상치 못하게 얼마나 움직이는지입니다. 0.1 이하면 좋음입니다.
세 가지 모두에서 방문의 75% 이상이 좋음 기준을 충족하면 통과이며, 휴대폰과 데스크톱은 따로 평가합니다. 기준값은Google의 Web Vitals 가이드에서 나온 것입니다.
실험실 점수와 실제 방문은 다르다
Lighthouse 같은 도구의 점수는 실험실 테스트로, 하나의 기기와 연결 환경에서 방문을 한 번 흉내 낸 결과입니다. 원인을 찾는 데는 유용하지만 실행할 때마다 달라지고 실제 사용자를 대표하지 않습니다.
필드 데이터는 사이트를 방문한 실제 Chrome 사용자에게서 모은 것으로, Chrome UX Report에 최근 28일 단위로 기록됩니다. 사용자의 휴대폰, 네트워크, 위치가 반영됩니다. 고객이 느린 사이트를 경험하는지 알고 싶다면 답은 필드 데이터에 있습니다.
결과가 나쁜 흔한 원인
느린 LCP
휴대폰에 맞게 줄이지 않은 큰 이미지, 느린 서버 응답, 페이지를 막는 글꼴이나 스크립트, JavaScript로 추가되는 탓에 늦게 뜨는 메인 이미지 등입니다.
나쁜 INP
한꺼번에 너무 많은 JavaScript가 실행되는 경우로, 채팅 위젯, 추적 태그, 무거운 페이지 빌더가 원인인 경우가 많습니다. 페이지는 다 뜬 것처럼 보여도 바빠서 탭에 반응하지 못합니다.
높은 CLS
공간을 미리 잡아 두지 않은 이미지와 임베드, 콘텐츠를 아래로 밀어내는 배너, 로딩되면서 글자 크기를 바꾸는 웹 글꼴 등입니다.
하루가 아니라 추이를 보기
필드 데이터는 28일을 묶은 값이라 개선 효과는 조금씩 나타납니다. 어느 한 주가 나쁜 것은 캠페인, 새 플러그인, 외부 스크립트 때문일 수도 있습니다. 주별 추이를 보면 변경이 효과가 있었는지 알 수 있고, 서서히 나빠지는 것도 문제가 되기 전에 잡아낼 수 있습니다.
제가 무료로 제공하는실사용자 속도 기록은 Chrome UX Report History API를 읽어 사이트 전체와 특정 페이지의 LCP, INP, CLS, FCP, TTFB를 기기별 그래프로 보여 주며, Google 기준값과 주별 좋은 방문 비율도 표시합니다. Chrome 방문이 너무 적은 사이트는 공개 데이터가 없으며, 이 경우 도구가 추측하지 않고 그렇다고 알려 줍니다.
고칠 만한 가치가 있을까
Core Web Vitals는 Google 검색의 여러 신호 중 하나일 뿐이며, 관련성 높은 콘텐츠보다 더 크게 작용하는 경우는 드뭅니다. 고쳐야 할 더 큰 이유는 고객입니다. 바로 반응하는 결제 화면과 손가락 아래에서 튀지 않는 페이지는 그냥 더 쓰기 편합니다.
빨간색으로 표시된 지표가 있다면 매출이나 문의로 이어지는 페이지부터 시작하세요. 측정하고, 원인 하나를 고치고, 이후 몇 주간의 추이를 확인하세요.
도움 받기
속도 문제는 대개 수십 가지가 아니라 두세 가지 주요 원인에서 생깁니다. 기록에 나쁜 결과가 보인다면사이트와 중요한 페이지를 보내 주세요. 원인을 찾고, 어떤 것을 고칠 가치가 있는지 알려 드리고, 수정까지 맡겠습니다.