Core Web Vitals 입문: LCP, INP, CLS를 측정하고 개선하는 방법

Core Web Vitals는 방문 중 세 가지 경험을 측정합니다. 화면에서 가장 큰 콘텐츠가 얼마나 빨리 나타나는지, 사용자 입력에 얼마나 신속하게 반응하는지, 레이아웃이 예상치 못하게 움직이는지입니다. 현재 지표는 최대 콘텐츠 페인트인 Largest Contentful Paint(LCP), 다음 페인트에 대한 상호작용인 Interaction to Next Paint(INP), 누적 레이아웃 이동인 Cumulative Layout Shift(CLS)입니다. 실제 사용자 결과를 먼저 확인한 다음 통제된 브라우저 기록으로 문제를 일으킨 요소, 상호작용 또는 레이아웃 변화를 찾습니다.

페이지가 완성된 것처럼 보여도 터치에 제대로 반응하지 않을 수 있습니다. 반응은 즉각적이지만 광고가 읽고 있던 문단을 아래로 밀어낼 수도 있습니다. 서로 다른 문제를 하나의 일반적인 속도 점수로 취급하면 최적화가 불필요하게 어려워집니다.

중요한 질문은 단순히 사이트가 빠른지 여부가 아닙니다. 방문의 어느 부분에서 어떤 사용자에게 문제가 발생하며, 변경의 효과를 어떤 근거로 확인할 것인지입니다.

종합 점수보다 세 지표를 먼저 읽습니다

Google의 Core Web Vitals 임곗값 정의 방법은 로딩, 반응성, 시각적 안정성에 별도의 목표를 적용합니다. 다음 기준은 지표 자체의 값에 적용되며 Lighthouse의 색상별 성능 점수 기준이 아닙니다.

LCP는 로딩 중 뷰포트에 보이는 측정 대상 이미지나 텍스트 가운데 가장 큰 콘텐츠를 추적합니다. 상품 사진, 기사 제목, 눈에 띄는 텍스트 블록일 수 있습니다. 페이지의 모든 이미지 다운로드가 끝나는 시간을 뜻하지 않습니다. 작은 로고가 빨리 나타나더라도 핵심 콘텐츠가 늦게 도착하는 문제를 상쇄하지는 않습니다.

INP는 측정 대상 상호작용부터 다음 화면 갱신까지의 지연입니다. 클릭, 탭, 키보드 상호작용이 포함되며 단순한 스크롤은 같은 종류의 측정이 아닙니다. 보고값은 대체로 방문 중 가장 느린 상호작용을 반영하되, 상호작용이 많은 페이지에서는 이상값을 처리합니다. 메인 스레드를 기다리는 시간, 이벤트 핸들러 실행 시간, 다음 프레임 준비 시간이 모두 포함됩니다.

CLS는 단위가 없는 점수입니다. 화면 콘텐츠가 예상치 못하게 이동한 정도를 나타내며, 영향을 받은 뷰포트 면적과 요소가 이동한 거리를 함께 고려합니다. 무한히 긴 방문의 모든 이동을 합산하는 대신, 측정 조건에 맞는 이동 묶음 중 가장 큰 값을 사용합니다. 최근 사용자 입력에 따른 일부 이동은 제외되지만, 상호작용에서 시작된 모든 레이아웃 변경이 무해하다는 뜻은 아닙니다.

이 차이 때문에 하나의 조치로 모든 문제를 해결하기는 어렵습니다. 대표 이미지를 압축하면 로딩에는 도움이 되지만 필터 버튼의 무거운 JavaScript는 사라지지 않습니다. 임베드 공간을 예약하면 레이아웃은 안정될 수 있지만 임베드 스크립트가 빨라지는 것은 아닙니다.

75번째 백분위수의 의미를 이해합니다

Core Web Vitals 평가는 보통 p75라고 쓰는 75번째 백분위수를 사용합니다. 기록값을 빠른 순서대로 정렬하면 측정된 경험의 약 4분의 3이 p75 값 이하에 위치합니다. 평균이 아니며 방금 수행한 자신의 방문 한 번을 나타내지도 않습니다.

설명을 위한 가상의 방문 집합을 생각해 볼 수 있습니다. 대부분은 페이지를 빨리 보지만 상당한 소수는 훨씬 오래 기다립니다. 평균은 이러한 불균형을 숨길 수 있습니다. 백분위수는 몇 개의 극단적인 관측값에 전체 판단을 맡기지 않으면서도 넓은 사용자 집단이 목표를 충족하는지 살펴보게 해 줍니다.

모바일과 데스크톱 집단은 따로 평가해야 합니다. 반응형 디자인은 같은 URL을 사용하면서도 다른 이미지를 제공하고, 다른 조작 요소를 노출하며, 서로 다른 하드웨어에서 실행될 수 있습니다. 데스크톱 결과가 좋다고 모바일 방문자도 같은 경험을 한다고 판단할 수 없습니다.

세 지표를 모두 평가하려면 각 p75 결과가 세 가지 좋음 기준을 모두 충족해야 합니다. 누락된 측정값은 별도로 취급해야 합니다. 특히 측정 대상 상호작용이 없는 방문에서는 INP 값이 생성되지 않습니다. 이 빈칸을 스프레드시트에서 0으로 채우지 마세요. 실제로 즉각적인 응답이 측정되었다는 잘못된 뜻이 됩니다.

Google 보고 도구에도 데이터 충분성에 관한 별도 규칙이 있습니다. PageSpeed Insights는 INP 데이터가 충분하지 않을 때 LCP와 CLS로 평가할 수 있습니다. 누락값을 만들어 내거나 모든 도구의 표시 규칙이 같다고 가정하지 말고, 보고서에 실제로 표시된 평가와 데이터 범위를 확인합니다.

실제 사용자 보고서와 통제된 테스트를 구분합니다

현장 데이터는 기록된 방문을 설명합니다. 실험실 데이터는 통제된 테스트를 설명합니다. 둘 다 유용하지만 답하는 질문이 다릅니다.

Chrome User Experience Report, 즉 CrUX는 수집 요건을 충족하는 Chrome 사용자 경험을 집계합니다. API는 최근 28일의 이동 수집 기간을 제공합니다. PageSpeed Insights의 실제 사용자 섹션은 CrUX를 사용하고, 실험실 섹션은 정해진 조건에서 Lighthouse를 실행합니다. 따라서 두 섹션의 결과가 다르더라도 이상하지 않습니다.

실험실 실행은 동의 선택이나 로그인 상태, 사용자 상호작용 없이 홈페이지를 로드할 수 있습니다. 실제 방문자는 배너를 닫고, 메뉴를 열고, 상품 목록을 필터링하고, 임베드 영상까지 스크롤한 뒤 캐시된 페이지로 돌아올 수 있습니다. 이런 경로에서는 로딩만 검사하는 테스트가 실행하지 않은 작업이 발생합니다.

반대 상황도 가능합니다. 자원이 제한된 실험실 테스트가 실제 사용자 다수의 경험보다 나쁘게 나타날 수 있습니다. 이때는 테스트 조건을 조사해야 하며 결과를 버릴 이유가 되지는 않습니다. 느린 하드웨어나 연결에서 중요해지는 실제 병목을 드러낸 것일 수 있습니다.

CrUX는 모든 브라우저와 모든 방문자를 대표하지도 않습니다. 페이지는 충분한 적격 트래픽과 포함 요건을 충족해야 합니다. 보고서가 없다는 사실은 데이터 가용성의 문제이며 페이지가 빠르거나 느리다는 증거가 아닙니다. Google은 포함을 보장하는 보편적인 방문자 수 기준을 공개하지 않습니다.

보고서가 다르면 현장 데이터와 실험실 데이터 가이드를 참고합니다. 값을 비교하기 전에 URL, 기기 범주, 수집 기간, 개별 URL인지 전체 출처인지 기록합니다.

질문에 맞는 보고서를 선택합니다

공개 URL을 조사할 때 PageSpeed Insights는 유용한 출발점입니다. 실제 사용자 섹션이 있다면 먼저 확인합니다. 요청한 페이지의 데이터인지, 출처 데이터로 대체되었는지 구분해야 합니다. 출처는 스킴, 호스트 이름, 포트가 같은 페이지를 묶으므로 개별 템플릿 각각에 대한 진단은 아닙니다.

그다음 실험실 섹션을 봅니다. 진단과 인사이트는 조사할 원인을 제안합니다. 독립적인 점수 감점 항목이 아니며, 예상 절약 시간을 모두 더해 보장된 개선 효과로 해석해서는 안 됩니다. 여러 권고가 동일한 지연 원인을 다룰 수 있기 때문입니다.

Search Console에서는 비슷한 경험 문제를 가진 URL 그룹을 찾을 수 있습니다. 공유 템플릿이 여러 기사나 상품에 영향을 줄 때 특히 유용합니다. 그룹에서 대표 URL을 열고 공통 구현을 검사합니다. 예시 페이지 하나를 수정했다고 그룹 전체가 해결되었다고 가정하지 않습니다.

Chrome DevTools를 사용하면 실제 실행 순서를 조사할 수 있습니다. LCP는 페이지 로딩을, 반응성은 상호작용을 기록합니다. 늦게 나타나는 콘텐츠, 배너, 임베드를 재현하면서 레이아웃 이동 이벤트를 살펴봅니다. 다른 사람이 재현할 수 있도록 기록 조건도 메모와 함께 남깁니다.

자체 실제 사용자 모니터링인 RUM은 집계 보고서에 없는 세부 정보를 제공합니다. 구현의 데이터 범위와 개인정보 보호 선택에 따라 성능 악화를 배포나 템플릿과 연결할 수 있습니다. 사용자 집단, 브라우저 API, 측정 세부사항이 다르므로 RUM과 CrUX가 정확히 일치한다고 기대해서는 안 됩니다.

리소스를 따라가며 느린 LCP를 진단합니다

먼저 기록에서 LCP 요소를 식별합니다. 관련된 뷰포트 크기로 확인해야 합니다. 데스크톱의 큰 이미지가 모바일에서는 작은 이미지나 텍스트 블록으로 바뀔 수 있으므로 실제로 지표를 결정하는 리소스를 최적화해야 합니다.

이미지 기반 LCP라면 네 구간을 조사합니다. 첫 HTML 바이트까지의 시간, 이미지 요청이 시작되기 전 지연, 이미지 다운로드 시간, 다운로드 완료 후 렌더링까지의 지연입니다. 작은 파일이라도 애플리케이션 초기화 이후 JavaScript가 URL을 삽입한다면 늦게 나타날 수 있습니다.

첫 점검은 구체적입니다. 초기 HTML에서 이미지를 발견할 수 있는지, 잘못 지연 로딩하도록 지정되었는지, 반응형 설정이 불필요하게 큰 파일을 선택하는지 확인합니다. 이미지가 도착한 뒤에도 스타일시트나 스크립트가 표시를 막는지도 확인합니다.

다음 예시는 중요한 이미지에 크기와 높은 가져오기 우선순위를 지정합니다. 참조하는 이미지 파일은 프로젝트에 실제로 있어야 합니다.

<img
  src="/images/article-hero-960.webp"
  srcset="/images/article-hero-960.webp 960w,
          /images/article-hero-1600.webp 1600w"
  sizes="(max-width: 960px) 100vw, 960px"
  width="1600"
  height="900"
  fetchpriority="high"
  alt="A request moving from a browser to a server"
>

loading="lazy"가 없는 것은 의도한 것입니다. fetchpriority는 스케줄링 힌트이며 브라우저의 모든 결정을 덮어쓰는 명령이 아닙니다. 전체 갤러리가 아니라 실제로 중요한 리소스에만 높은 우선순위를 사용합니다.

HTML 자체가 늦게 도착하면 이미지 최적화로 그 이전의 기다림을 없앨 수 없습니다. 리디렉션, 캐시 미스, 애플리케이션 작업을 중심으로 서버 응답 시간과 TTFB를 조사합니다. 이미지가 제때 도착해도 보이지 않는다면 렌더링과 메인 스레드 작업을 살펴봐야 합니다.

실제 상호작용을 재현하여 나쁜 INP를 진단합니다

메뉴 열기, 상품 옵션 선택, 검색 제출, 긴 섹션 펼치기처럼 구체적인 행동을 고릅니다. 페이지 로딩이 끝난 뒤 평소의 백그라운드 스크립트가 실행되는 상태에서 기록합니다. 상호작용이 없는 기록으로 실제 상호작용의 지연을 설명할 수는 없습니다.

지연은 핸들러 실행 전에 발생할 수 있습니다. 다른 스크립트가 메인 스레드를 사용하여 입력이 기다릴 수 있습니다. 필터가 큰 데이터 집합을 다시 계산하는 등 핸들러 안에서 발생할 수도 있습니다. 이후 브라우저가 대규모 변경의 스타일, 레이아웃, 페인트를 준비할 때 발생할 수도 있습니다.

각 단계를 따로 다룹니다. 불필요한 분석 콜백을 없애도 비용이 큰 레이아웃 연산은 해결되지 않습니다. 핸들러를 줄여도 시작을 막는 다른 작업은 사라지지 않습니다. 먼저 트레이스에서 어떤 단계가 가장 큰 비중을 차지하는지 확인해야 합니다.

불필요한 작업부터 줄입니다. 그다음 시각적 피드백 전에 완료할 필요가 없는 작업을 나눕니다. 조각 사이에 제어권을 양보하면 브라우저가 다른 작업을 처리할 기회가 생깁니다. DOM을 사용하지 않는 적절한 계산은 worker로 옮겨 메인 스레드 밖에서 수행할 수 있습니다. 그렇더라도 필요 없는 데이터를 반복 처리하는 알고리즘을 그대로 두어도 된다는 뜻은 아닙니다.

일반적인 Lighthouse 탐색 테스트는 메인 스레드 차단의 실험실 지표로 Total Blocking Time을 사용합니다. TBT는 INP가 아니므로 검사 도구의 INP 칸에 넣어서는 안 됩니다. 통제된 대화형 기록으로 상호작용 지연을 측정할 수 있습니다. 한계는 로딩 전용 테스트에 있으며 모든 실험실 측정에 있는 것이 아닙니다.

이동을 일으킨 원인을 찾아 CLS를 진단합니다

움직인 요소는 원인이 아니라 영향을 받은 대상일 수 있습니다. 문단이 아래로 밀렸다면 그 위에 무엇이 나타났는지 봅니다. 새 배너나 크기를 예약하지 않은 이미지가 문단에 허용된 공간을 바꿨을 수 있습니다.

이미지와 영상부터 확인합니다. 크기나 적절한 종횡비를 지정하면 미디어가 도착하기 전에 공간을 예약할 수 있습니다. 이후 광고, 임베드 플레이어, 추천 패널 등 비동기 콘텐츠를 검사합니다. 자리표시자에는 장식적인 로딩 애니메이션뿐 아니라 각 화면 분기점에 맞는 현실적인 크기가 필요합니다.

글꼴도 중요합니다. 대체 글꼴과 다운로드한 웹 글꼴은 문자 폭과 수직 메트릭이 다를 수 있습니다. 교체 시 줄바꿈과 주변 콘텐츠 위치가 바뀔 수 있습니다. 적절한 로딩 방식을 선택하고 대체 글꼴의 메트릭 조정을 고려합니다. 텍스트를 즉시 보여 준다고 레이아웃 위험이 모두 사라지는 것은 아닙니다.

이동을 고치려다 접근성을 떨어뜨리지 않아야 합니다. 고정 오버레이는 좁은 화면이나 확대된 텍스트에서 콘텐츠와 조작 요소를 가릴 수 있습니다. 배너나 슬롯을 바꾼 뒤에는 키보드 탐색, 확대, 주요 작업에 남은 공간을 검사합니다.

새로고침만 기록하면 로딩 이후의 이동을 놓칠 수 있습니다. 스크롤하고 필요한 조작 요소를 열고 늦게 도착하는 콘텐츠를 기다리는 동안에도 기록을 유지합니다. 현장에서 보고된 문제와 관찰된 이동을 비교한 뒤 해결 여부를 판단합니다.

작고 반복 가능한 측정 절차를 만듭니다

홈페이지만 검사하지 말고 대표 페이지를 선택합니다. 기사, 카테고리, 상품 또는 방문자에게 중요한 다른 템플릿을 포함합니다. 탐색 메뉴, 글꼴, 광고 슬롯, 동의 제어 등 공유 구성요소를 기록합니다.

각 기기 범주의 기준값을 보관합니다. 보고서, 날짜, 테스트 버전, 중요한 지표값을 저장합니다. 같은 조건에서 비교 가능한 실험실 테스트를 여러 번 실행합니다. 한 번의 좋은 결과만으로 개선과 정상적인 변동을 구분하기는 어렵습니다.

이미 web-vitals 패키지를 번들에 포함한 개발 프로젝트라면 다음 작은 진단 모듈로 브라우저가 보고하는 값을 기록할 수 있습니다. 로컬 디버깅용 예시이며 완전한 분석 시스템은 아닙니다.

import { onCLS, onINP, onLCP } from 'web-vitals';

function logMetric(metric) {
  console.log({
    name: metric.name,
    value: metric.value,
    rating: metric.rating,
    id: metric.id
  });
}

onLCP(logMetric);
onINP(logMetric);
onCLS(logMetric);

일부 콜백은 페이지 수명 주기나 수행한 상호작용에 따라 실행됩니다. 조용한 탭을 열자마자 세 가지 유의미한 값이 나온다고 기대하지 않습니다. 운영 환경의 수집에는 엔드포인트, 집계, 샘플링 결정, 적절한 개인정보 보호 제어가 필요하며 콘솔 출력은 이를 제공하지 않습니다.

배포 후에는 성능 악화를 감시하고 수집 기간이 새 방문을 반영하도록 기다립니다. 이동 창에는 충분한 시간이 지날 때까지 이전 경험과 이후 경험이 함께 들어 있습니다. Lighthouse를 반복 실행해도 이 과정이 빨라지거나 누락된 CrUX 트래픽이 채워지지 않습니다.

SEO에서 Core Web Vitals의 역할을 정확히 봅니다

Google Search Central은 순위 시스템이 Core Web Vitals를 사용한다고 설명하면서도 좋은 보고 결과가 높은 순위를 보장하지는 않는다고 밝힙니다. 관련성, 유용한 콘텐츠, 다른 페이지 경험 요소도 중요합니다. Lighthouse 점수 상승을 검색 순위 상승으로 환산하는 공식은 문서화되어 있지 않습니다.

이 관점은 우선순위를 실용적으로 만듭니다. 사용자가 필터를 쓸 수 없다면 작업을 방해하기 때문에 고칩니다. 널리 쓰이는 템플릿의 주요 이미지가 늦으면 공유 원인을 해결합니다. 중요한 콘텐츠가 여전히 찾거나 쓰기 어려운데 이미 좋은 합성 점수 한 점을 높이는 데 예산을 모두 쓰지 않습니다.

첫 발견을 구체적인 변경으로 연결합니다

대표 URL 하나와 문제가 있는 지표 하나를 고릅니다. 관찰된 원인, 제안하는 변경, 이후 비교할 근거를 적습니다. 그러면 다른 개발자가 구현하고 검토자가 평가할 수 있는 범위가 명확한 작업이 됩니다.

Core Web Vitals 검사 도구로 실제 측정값을 분류하되 출처와 단위를 유지합니다. 구현 작업은 성능 체크리스트로 추적합니다. 방문의 어느 부분을 개선할지 알게 되면 Core Web Vitals 가이드에서 다음 진단 경로를 선택할 수 있습니다.