Core Web Vitals 점수란 없습니다 (그리고 이것이 중요한 이유)

"저희의 Core Web Vitals 점수가 떨어지고 있습니다. 도와주실 수 있나요?"

제가 하루에도 몇 번씩 받는 질문입니다. 제가 가장 먼저 스스로에게 묻는 질문은 '말씀하시는 Core Web Vitals 점수가 무엇인가요?'입니다. 사람들이 저에게 연락할 때는 페이지 속도에 문제가 있다는 것을 막 알게 되었고 스스로 해결할 수 없을 때입니다. 대개 이는 실험실 데이터(Lighthouse)나 필드 데이터(CrUX 및 RUM)가 실패하고 있음을 의미합니다.

최종 검토: 2026년 3월, Arjen Karel

따라서 누군가가 자신의 Core Web Vitals가 실패하고 있다고 말한다면, 먼저 그들이 실험실 데이터에 대해 말하는 것인지 필드 데이터에 대해 말하는 것인지 파악해야 합니다. 실험실 데이터(Lighthouse)에 대해 이야기하고 있다는 가장 좋은 신호는 이 'Core Web Vitals 점수'를 언급한다는 것입니다.

오 이런, Lighthouse 점수군요

그 마법의 'Core Web Vitals 점수'에 대해 물어보면 저에게 연락하는 많은 사람들이 실패한 Lighthouse 점수를 보여줍니다. 여기서 상황이 복잡해집니다! 실패한 Lighthouse 점수가 Core Web Vitals에서 실패하고 있다는 의미는 아닙니다. '녹색' Lighthouse 점수가 Core Web Vitals를 통과하고 있다는 의미가 아닌 것과 같습니다. 이는 단지 해당 특정 테스트를 통과하거나 실패했다는 것을 의미할 뿐입니다.

숫자가 이를 증명합니다. HTTP Archive 연구에 따르면 Lighthouse에서 90점 이상을 받은 페이지의 43%가 실제 필드에서 여전히 하나 이상의 Core Web Vital에 실패했습니다. 거의 완벽에 가까운 99점의 Lighthouse 점수에서도 4개 페이지 중 거의 1개가 실패했습니다. 2024년 3월에 INP가 FID를 대체했고 Lighthouse는 INP를 전혀 측정할 수 없기 때문에 오늘날 그 격차는 아마도 더 벌어졌을 것입니다.

필드 데이터에 대해 알려주세요

그래서 제가 다음으로 하는 일은 그들에게 필드 데이터에 대해 알려주는 것입니다. 이 경우에는 CrUX 데이터입니다. CrUX는 Chrome User Experience Report의 약자입니다. CrUX는 실제 Chrome 사용자가 웹의 인기 있는 목적지를 어떻게 경험하는지 보여주는 데이터 세트입니다.

CrUX는 Web Vitals 프로그램의 공식 데이터 세트입니다. 즉, 3가지 지표(LCP, INP, CLS)에 대한 Core Web Vitals를 통과(또는 실패)하려면 방문자의 최소 75%가 좋은 경험을 가져야 합니다. Google은 이를 75번째 백분위수에서 측정합니다. 즉, 방문 중 가장 나쁜 25%가 점수를 결정한다는 뜻입니다. 트래픽이 많을 때 서버 응답이 한 번 느려지면 전체 오리진의 점수가 떨어질 수 있습니다.

Google 검색 옹호자인 John Mueller는 이에 대해 분명히 밝혔습니다. "Chrome의 Lighthouse 도구도 점수를 생성합니다. Google은 검색에 이러한 점수를 사용하지 않습니다." Google이 사용하는 것은 CrUX 필드 데이터입니다. Core Web Vitals가 순위에 미치는 영향에 대한 전체 분석은 Core Web Vitals와 SEO를 참조하세요.

이제 여러분은 Core Web Vitals를 통과하거나 실패하게 만드는 단일 'Core Web Vitals 점수'가 없다는 것을 이해하셨을 것입니다.

필드 데이터를 보여주세요

이제 클라이언트가 필드 데이터에 대해 알았으니 보여줄 차례입니다. 방금 보여드린 '실패한' Lighthouse 점수를 기억하시나요? 이것이 해당 CrUX 데이터입니다. 보시다시피 그들은 통과하고 있으며 이 클라이언트에 대해서는 Core Web Vitals를 전혀 걱정할 필요가 없습니다.

과정은 간단합니다. 브라우저에서 pagespeed.web.dev로 이동하여 URL을 입력합니다. 다음으로 ('이 URL' 바로 옆에 있는) Origin을 선택하여 시작 페이지뿐만 아니라 전체 사이트의 Core Web Vitals를 표시합니다. 또한 CrUX 히스토리 보고서를 사용하여 시간에 따라 지표가 어떻게 변하는지 추적할 수 있습니다. 그리고 아니요, CrUX 데이터는 28일마다 업데이트되는 것이 아닙니다.

그렇다면 Lighthouse는요?

이 시점에서, 설득력 있는 주장을 펼치고 기본적으로 방금 말씀드린 내용을 증명한 후에도 99%의 클라이언트들은 여전히 Lighthouse 점수를 놓을 준비가 되어 있지 않습니다. 이해합니다. 그것은 매력이 있습니다. 누구나 해석할 수 있는 녹색, 주황색, 빨간색 숫자가 전혀 중요하지 않다고 상상하기는 어렵습니다.

하지만 Lighthouse는 단지 테스트일 뿐이라는 점을 기억해야 합니다. 그것은 매우 멋진 테스트입니다. 저는 그것의 많은 기능과 코드 작성 방식을 좋아하며 일부 Core Web Vitals 문제를 해결하는 데 도움이 되는 방식도 좋아합니다. 그러나 Lighthouse가 할 수 없는 4가지가 있습니다:

1. 페이지와 상호 작용하기. 이로 인해 이 테스트는 기본적으로 쓸모없게 됩니다. 방문자들은 귀하의 페이지와 상호 작용할 것입니다. 그 상호 작용을 통해 전환을 얻게 됩니다.

2. 재방문자처럼 행동하기. Lighthouse는 (기본적으로, 이 설정을 변경할 수는 있습니다) 귀하의 페이지를 이전에 한 번도 방문한 적이 없는 것처럼 방문합니다. 페이지 렌더링 및 페이지 타이밍 측면에서 이것은 종종 엄청난 차이를 만듭니다. 따라서 Lighthouse는 상당수 방문자의 대표성을 갖지 못합니다.

3. 귀하의 페이지에 대해 어떤 것이든 이해하기. 가장 좋은 예는 Total Blocking Time 감사입니다. 심지어 대부분의 전문가들도 높은 Total Blocking Time은 나쁘다는 데 동의하지만, 그게 전부가 아닙니다. 페이지가 응답해야 할 때(강제로 발생시킬 수 있습니다!) '차단'이 발생하지 않고, 초기 렌더링 중에 차단이 발생하지 않는 한 Lighthouse 점수가 나쁘더라도 아마 전혀 문제없을 것입니다!

4. Interaction to Next Paint 측정. INP는 세 가지 Core Web Vitals 중 하나이지만 Lighthouse는 실제 사용자 상호 작용이 필요하기 때문에 0%의 가중치를 부여합니다. Lighthouse는 Total Blocking Time을 프록시로 사용하여 가장 높은 가중치인 30%를 얻지만, TBT와 INP는 반대 방향으로 움직일 수 있습니다. 2025년에 실험실 TBT는 58% 증가한 반면 필드 INP는 오히려 향상되었습니다. 그것만으로도 하나의 Lighthouse 숫자를 얼마나 신뢰해야 하는지 알 수 있습니다.

2025 Web Almanac에 따르면, 모바일 오리진의 48%만이 세 가지 Core Web Vitals를 모두 통과했습니다. 데스크톱에서 그 수치는 56%입니다. 클라이언트가 통과하고 있다면 그들은 웹의 절반 이상보다 앞서 있는 것입니다. 그 상태를 유지하려면 Real User Monitoring을 설정하여 클라이언트보다 먼저 퇴행을 포착할 수 있도록 하세요. CoreDash가 추적하는 사이트 전반에 걸쳐 적극적인 모니터링을 갖춘 오리진은 주기적인 Lighthouse 확인에 의존하는 사이트가 몇 주 걸리는 것에 비해 평균 48시간 이내에 CWV 퇴행을 포착합니다.

Core Web Vitals를 통과하기 위한 단계별 계획을 원하시면 Core Web Vitals 통과 방법을 확인하세요.