코어 웹 바이탈

코어 웹 바이탈은 사용자가 웹 페이지에서 겪는 답답함을 세 숫자로 잽니다. 숫자는 서버가 아니라 사용자의 브라우저에서 잽니다. 서버 응답이 빨라도 이 숫자가 나쁘면 사용자에게는 느린 사이트입니다. 구글이 정한 기준이라 구글 검색 순위에도 반영됩니다.

쉽고 빠른 이해

코어 웹 바이탈은 「이 페이지가 쓰기 편한가」를 세 숫자로 매기는 성적표입니다. 쇼핑몰 상품 페이지라면 상품 사진이 뜨기까지의 시간, 장바구니 버튼이 반응하기까지의 시간, 글자가 밀려난 정도를 잽니다.

이게 없으면 서버 쪽 숫자만 보고 빠르다고 믿게 됩니다. 서버는 0.1초 만에 답했어도 사용자는 무거운 이미지와 스크립트 탓에 몇 초를 기다릴 수 있습니다.

판정은 이렇게 돕니다.

1. 방문자의 브라우저가 세 숫자를 잽니다
2. 여러 방문의 기록을 모아 빠른 순으로 줄 세웁니다
3. 방문 넷 중 셋이 「좋음」 선 안에 들면 그 숫자는 합격입니다

판정이 나오려면 진짜 방문자의 기록이 쌓여야 합니다. 세 숫자에 안 잡히는 불편은 따로 살펴야 합니다.

쓰는 곳은 사람이 브라우저로 여는 공개 페이지입니다. 다른 서버가 부르는 백엔드 서비스나 방문이 적은 사내 도구에는 맞지 않습니다.

상세

식당을 떠올리면 됩니다. 손님은 주방이 얼마나 바쁜지 모릅니다. 음식이 언제 나왔는지, 직원을 불렀을 때 언제 돌아봤는지, 식사 중에 식탁이 흔들리지 않았는지를 기억합니다. 손님이 그 식당을 평가하는 기준은 이 셋입니다.

코어 웹 바이탈(Core Web Vitals)도 같은 눈으로 웹 페이지를 봅니다. 서버 안의 사정 대신 사용자가 화면에서 겪는 것을 잽니다. 구글이 웹 페이지의 사용자 경험을 재려고 고른 지표 세 개가 이 묶음입니다.

백엔드에서 흔히 보는 숫자는 응답 시간입니다. 요청을 받고 답을 보내기까지 걸린 시간입니다. 그런데 사용자의 기다림은 답이 도착한 뒤에도 이어집니다. 브라우저가 HTML(HyperText Markup Language)을 읽고 이미지와 스크립트를 더 받아 화면에 칠해야 비로소 내용이 보입니다.

코어 웹 바이탈은 이 뒷부분까지 넣어서 잽니다. 서버 로그로는 안 보이는 기다림을 숫자로 드러내는 것이 이 지표 묶음의 쓸모입니다.

세 지표

세 지표는 사용자가 겪는 답답함을 하나씩 맡습니다. 로딩이 늦은 것, 반응이 늦은 것, 화면이 흔들리는 것입니다. 아래에서 하나씩 풉니다. 기준값은 표로 모읍니다.

지표 이름에 자주 나오는 페인트는 브라우저가 화면에 픽셀을 칠하는 일입니다. 사용자는 칠해진 것만 볼 수 있습니다. 그래서 지표들이 칠한 순간을 기준으로 삼습니다.

최대 콘텐츠풀 페인트(Largest Contentful Paint, LCP)는 로딩을 잽니다. 이름의 「콘텐츠풀」은 내용이 담긴 요소를 칠한다는 뜻입니다. 페이지를 열기 시작한 때부터 스크롤 없이 보이는 첫 화면에서 가장 큰 이미지나 글 덩어리가 칠해질 때까지의 시간입니다. 뉴스 기사라면 대표 사진이나 본문 첫 단락이 그 요소가 되기 쉽습니다.

가장 큰 요소를 고른 까닭은 사용자의 느낌과 가깝기 때문입니다. 작은 아이콘 몇 개가 먼저 떠도 사용자는 아직 안 떴다고 느낍니다. 큰 사진이나 본문이 보여야 「이제 떴다」고 느낍니다.

다음 페인트까지의 상호작용(Interaction to Next Paint, INP)은 반응을 잽니다. 사용자가 클릭하거나 화면을 누르거나 키를 친 뒤 화면이 다음으로 칠해지기까지의 시간입니다. 페이지에 머무는 동안 일어난 상호작용을 모두 잽니다.

INP 는 그 가운데 값 하나를 고릅니다. 상호작용이 적으면 가장 느린 값을 그대로 씁니다. 많으면 가장 느린 몇 개를 빼고 그다음으로 느린 값을 씁니다. 우연히 한 번 튄 값이 페이지 전체의 판정을 흔들지 않게 하려는 것입니다.

이 시간이 길어지는 흔한 원인은 메인 스레드가 다른 일에 묶여 있는 것입니다. 메인 스레드는 브라우저가 자바스크립트 실행과 화면 그리기를 함께 맡기는 스레드 하나입니다. 무거운 스크립트가 돌고 있으면 클릭을 받아도 처리할 차례가 늦게 옵니다.

화면이 흔들리는 일에는 이름이 있습니다. 이미 보이던 요소가 예고 없이 위치를 옮기는 일이 레이아웃 이동입니다. 읽던 글이 갑자기 아래로 밀리거나, 누르려던 버튼이 옮겨 가 엉뚱한 것을 누르는 일이 여기에 듭니다.

누적 레이아웃 이동(Cumulative Layout Shift, CLS)은 이 레이아웃 이동을 점수로 매겨 더한 값입니다. 화면의 넓은 부분이 멀리 움직일수록 점수가 커집니다. 시간이 아니라 흔들린 정도라서 단위가 없습니다.

이동 한 번의 점수는 두 비율의 곱입니다. 첫째는 넓이의 비율입니다. 움직인 요소가 움직이기 전과 뒤에 걸친 넓이가 화면의 얼마인지를 봅니다. 둘째는 거리의 비율입니다. 요소가 움직인 거리가 화면 높이의 얼마인지를 봅니다.

예를 들어 화면 폭을 꽉 채우고 높이의 10분의 3을 차지하는 배너가 화면 높이의 5분의 1만큼 아래로 밀렸다고 합시다. 밀리기 전과 뒤에 걸친 넓이는 화면의 절반입니다. 점수는 0.5 × 0.2 = 0.1 입니다. 아래 표에서 「좋음」의 끝이 이 정도입니다.

세 지표에는 각각 「좋음」과 「나쁨」을 가르는 선이 있습니다. 두 선 사이는 「개선 필요」입니다.

표에서 LCP 와 INP 는 시간입니다. CLS 하나만 점수입니다. 셋 다 값이 작을수록 사용자가 덜 답답합니다.

방문 한 번에서 재는 구간

세 지표는 방문 한 번 안에서 서로 다른 때를 봅니다. 아래 그림은 사용자와 브라우저와 서버가 주고받는 순서 위에 세 지표가 끝나는 때를 올려 놓은 것입니다.

sequenceDiagram
    participant 사용자
    participant 브라우저
    participant 서버
    사용자->>브라우저: 주소를 연다
    브라우저->>서버: 페이지를 요청한다
    서버-->>브라우저: HTML 의 첫 바이트
    브라우저->>서버: 이미지와 스크립트를 더 받는다
    Note over 브라우저: 가장 큰 요소를 칠한다 · LCP 끝
    사용자->>브라우저: 버튼을 누른다
    Note over 브라우저: 다음 화면을 칠한다 · INP 끝
    Note over 사용자,브라우저: 머무는 내내 밀려난 요소를 더한다 · CLS

LCP 는 주소를 연 때부터 셉니다. 그래서 서버가 첫 바이트를 늦게 보내면 LCP 도 그만큼 늦어집니다. INP 와 CLS 는 페이지가 뜬 뒤 사용자가 머무는 동안 계속 잽니다.

합격을 가르는 기준

방문 한 번만으로는 판정하지 않습니다. 같은 페이지도 방문자의 기기와 네트워크에 따라 숫자가 크게 달라지기 때문입니다. 그래서 많은 방문의 기록을 모아 백분위수로 판정합니다.

백분위수는 값을 작은 순으로 줄 세웠을 때 몇 퍼센트 지점에 오는 값인지를 말합니다. 코어 웹 바이탈은 75번째 백분위수를 씁니다. 방문 100번의 LCP 를 빠른 순으로 세웠을 때 75번째 값이 2.5초 이하면 그 페이지의 LCP 는 「좋음」입니다.

방문의 4분의 3이 좋음 선 안에 들어야 한다는 뜻입니다. 평균을 쓰면 아주 빠른 방문 몇 건이 느린 방문들을 가립니다. 줄 세운 값의 한 지점을 보면 느린 방문이 가려지지 않습니다.

휴대폰과 데스크톱은 따로 셉니다. 둘은 처리 능력과 네트워크가 달라서 섞으면 어느 쪽 사정도 안 보입니다. 세 지표가 모두 「좋음」이어야 그 페이지가 코어 웹 바이탈을 통과한 것으로 칩니다.

현장 데이터와 실험실 데이터

숫자를 얻는 길은 둘입니다. 진짜 방문자의 브라우저에서 모으는 길과 시험용 환경에서 페이지를 한 번 열어 보는 길입니다. 앞의 것을 현장 데이터, 뒤의 것을 실험실 데이터라고 부릅니다.

현장 데이터가 판정의 근거입니다. 크롬 브라우저가 모은 방문 기록은 Chrome UX Report(Chrome User Experience Report, CrUX)라는 공개 통계로 나옵니다. 구글 검색이 보는 숫자도 이 통계에서 옵니다.

현장 데이터를 직접 모을 수도 있습니다. 페이지에 측정 스크립트를 심어 방문자마다 값을 서버로 보내게 하는 것입니다. 이렇게 직접 모으는 방식이 실사용자 모니터링(Real User Monitoring, RUM)입니다.

실험실 데이터는 원인을 찾을 때 씁니다. Lighthouse 같은 도구가 정해진 기기와 네트워크를 흉내 냅니다. 그 조건에서 페이지를 엽니다. 조건이 늘 같아서 고치기 전과 후를 견주기 쉽습니다.

실험실에는 사용자가 없습니다. 아무도 누르지 않으니 INP 는 실험실에서 잴 수 없습니다. Lighthouse 는 LCP 와 CLS 만 잽니다.

지표가 바뀌어 온 과정

세 지표는 고정된 목록이 아닙니다. 새 지표는 시험 단계와 예고 단계를 거칩니다. 그 뒤 안정 단계에 올라야 정식 코어 웹 바이탈이 됩니다.

INP 가 그렇게 들어왔습니다. 그 전에는 첫 입력 지연(First Input Delay, FID)이 반응을 쟀습니다. FID 는 첫 상호작용 하나만 봤습니다. 그마저 브라우저가 처리를 시작하기까지만 셌습니다.

INP 는 머무는 내내의 상호작용을 화면이 바뀔 때까지 잽니다. 사용자가 느끼는 반응에 더 가깝습니다. 2024년에 INP 가 안정 단계에 올랐습니다. 그때부터 FID 를 대신합니다.

백엔드와 닿는 부분

세 지표는 브라우저에서 재지만 원인은 서버에도 있습니다. 이 소절은 백엔드 개발자가 손댈 수 있는 곳을 지표별로 짚습니다.

LCP 는 서버 응답에 바로 묶입니다. 브라우저가 요청을 보낸 뒤 응답의 첫 바이트가 올 때까지의 시간을 첫 바이트까지의 시간(Time to First Byte, TTFB)이라고 부릅니다. TTFB 가 1초면 LCP 가 좋음 선에 들 여유는 1.5초만 남습니다.

서버 사이드 렌더링은 서버에서 내용을 채운 HTML 을 완성해 보내는 방식입니다. 브라우저에서 스크립트로 내용을 그리는 방식이면 빈 HTML 을 받은 뒤 스크립트를 내려받아 실행해야 내용이 생깁니다. 서버 사이드 렌더링은 HTML 에 이미 내용이 있습니다. 그 기다림 없이 가장 큰 요소를 칠할 수 있어서 LCP 가 당겨집니다.

CDN(Content Delivery Network, 콘텐츠 전송 네트워크)은 사용자와 가까운 곳에 둔 여러 서버에서 파일을 내주는 망입니다. 큰 이미지가 먼 원래 서버 대신 가까운 서버에서 오면 받는 시간이 줄어듭니다. 그만큼 LCP 도 줄어듭니다.

CLS 는 늦게 도착하는 내용에서 자주 생깁니다. 페이지가 먼저 그려진 뒤 추가 요청의 응답으로 배너나 목록이 끼어들면 아래 내용이 밀려납니다. 크기를 모르는 이미지가 늦게 도착해도 같은 일이 생깁니다. 응답이 오기 전에 그 내용이 들어갈 공간을 미리 비워 두면 밀림이 줄어듭니다.

INP 는 주로 브라우저 안의 자바스크립트 몫입니다. 서버가 한 번에 너무 큰 데이터를 내려보내면 브라우저가 그것을 처리하느라 메인 스레드가 묶이기도 합니다. 응답을 나눠 보내면 한 번에 묶이는 시간이 짧아집니다.

쓰임새와 한계

코어 웹 바이탈은 사람이 브라우저로 여는 공개 페이지에 맞춰져 있습니다. 검색으로 들어오는 방문이 많은 페이지일수록 챙길 까닭이 큽니다. 구글 검색이 순위를 정하는 여러 신호 가운데 하나로 이 숫자를 보기 때문입니다. 순위를 정하는 신호는 이것 말고도 많습니다.

브라우저가 없는 곳에는 쓸 수 없습니다. 앱이나 다른 서버가 부르는 백엔드 서비스는 응답 시간과 오류율 같은 서버 지표로 잽니다.

방문자가 적은 페이지는 공개 통계에 잡히지 않습니다. 사내 관리 도구가 그렇습니다. 이런 페이지는 실사용자 모니터링을 직접 달아야 숫자가 나옵니다.

세 숫자가 모두 좋아도 쓰기 불편한 페이지는 있습니다. 세 지표는 로딩과 반응과 흔들림만 봅니다. 찾는 정보가 없거나 과정이 복잡한 불편은 이 숫자에 안 잡힙니다.

관련 항목

코어 웹 바이탈을 이루는 지표

최대 콘텐츠풀 페인트 · 다음 페인트까지의 상호작용 · 누적 레이아웃 이동

코어 웹 바이탈 밖에서 함께 보는 웹 성능 지표

첫 입력 지연 · 첫 바이트까지의 시간 · 첫 콘텐츠풀 페인트 · 첫 페인트 · 총 차단 시간

이 지표를 재는 도구

Lighthouse · Chrome UX Report · PageSpeed Insights · Search Console · 개발자 도구 · web-vitals

이 지표를 모으고 판정하는 수단

실사용자 모니터링 · 합성 모니터링 · 백분위수 · PerformanceObserver

이 숫자를 움직이는 브라우저 렌더링 단계

렌더링 · 렌더 파이프라인 · 레이아웃 · 리플로우 · 페인트 · 리페인트 · 합성 · 메인 스레드 · 레이아웃 이동

이 숫자를 줄이는 최적화 기법

서버 사이드 렌더링 · CDN · 캐싱 · 지연 로딩 · 이미지 최적화 · 웹 폰트 · 코드 분할

이 지표가 속하는 상위 분야

프론트엔드 · 웹 성능 · 사용자 경험 · 검색 엔진 최적화 · 지표