--- title: 'Core Web Vitals, 무엇을 왜 어떻게 수집할까' marp: true paginate: true theme: default tags: - web-performance - observability - browser date: 2026-10-20 description: 'LCP, INP, CLS가 무엇을 재는지에서 시작해 왜 실제 사용자에게서 재야 하는지, 브라우저와 web-vitals가 값을 어떻게 만들고 언제 넘겨주는지까지 따라간다. 값이 서버에 도착하지 않는 다섯 가지 경우를 직접 측정한 수치로 확인한다.' published: true art: undraw: data-points hue: blue ---
# Core Web Vitals,
무엇을 왜 어떻게 수집할까 사용자가 **페이지를 떠날 때** 확정되는 값
@yceffort
--- ## 오늘 순서
01
### 무엇을 재나 LCP, INP, CLS와 p75
02
### 왜 재나 매출과 검색, Lighthouse로는 알 수 없는 것
03
### 어떻게 재나 브라우저의 성능 기록과 web-vitals
04
### 수집할 때 생기는 질문 값이 서버에 도착하지 않는 다섯 가지 경우
--- ## 이 덱의 측정 환경
web-vitals
6.2.3

2026-10-19 기준 npm 최신

Next.js
16.3.5

web-vitals 4.2.1 내장

Chromium
156

Playwright 1.64.1. 일부는 Chrome Beta 157로 측정

브라우저 지원표
8.1.6

MDN browser-compat-data

라이브러리 버전에 따라 결과가 달라진다. 4장의 일부 내용은 **web-vitals 다음 배포에서 바뀌며**, 해당 위치에 표시했다.
--- ## 먼저 알아 둘 용어

페이지 로드

문서 하나를 새로 여는 것. 지표는 페이지 로드마다 따로 측정된다

성능 기록

"언제 무엇을 그렸는지", "클릭 처리에 몇 ms 걸렸는지" 같은 브라우저의 기록

숨겨진 상태

탭 전환, 앱 전환, 페이지 이동으로 화면에서 사라진 상태. visibilityState가 hidden

p75

값을 작은 순서로 정렬했을 때 75% 위치의 값. 100건이면 75번째 값

필드 데이터

실제 사용자 브라우저에서 측정한 값

랩 데이터

정해진 환경에서 도구로 측정한 값. Lighthouse가 대표적이다

---
1장
# 무엇을 재나 사용자 경험을 세 가지 숫자로 --- ## 사용자가 느끼는 세 가지 질문
"떴나?"
LCP
Largest Contentful Paint

화면에서 가장 큰 텍스트 블록이나 이미지가 그려진 시점

"눌렀는데 반응하나?"
INP
Interaction to Next Paint

클릭, 탭, 키 입력부터 다음 화면이 그려지기까지

"읽다가 밀리지 않나?"
CLS
Cumulative Layout Shift

화면 요소가 예고 없이 움직인 정도. 단위 없는 점수

이 세 지표가 **Core Web Vitals**다. 각각 로딩, 반응성, 시각적 안정성을 측정한다. --- ## 보조 지표: TTFB와 FCP
TTFB응답 첫 바이트 도착
FCP처음 무언가 그려짐
LCP가장 큰 요소가 그려짐
TIME TO FIRST BYTE

요청부터 응답 첫 바이트까지

리다이렉트, 서비스 워커 시작, DNS, 연결과 TLS, 서버가 첫 바이트를 보내기까지를 모두 더한 시간

원인 후보: 서버, CDN, 리다이렉트

FIRST CONTENTFUL PAINT

처음 무언가 그려진 시점

텍스트, 이미지(배경 이미지 포함), svg, 흰색이 아닌 canvas 중 하나. 빈 화면이 끝났다는 신호

원인 후보: 렌더링을 막는 CSS와 JS, 늦게 로드되는 웹 폰트

세 지표 모두 탐색 시작부터 측정한다(막대 길이는 예시). TTFB와 FCP가 Core Web Vitals에 들지 않은 이유는 다음 장. web.dev/articles/ttfb, web.dev/articles/fcp
--- ## TTFB와 FCP는 왜 Core Web Vitals가 아닐까
CORE WEB VITALS의 조건 (web.dev)

① 서로 다른 측면

사용자 경험의 한 측면을 지표 하나가 맡는다

② 필드에서 측정

실제 사용자 브라우저에서 측정할 수 있다

③ 사용자가 느끼는 결과

사용자에게 중요한 결과를 반영한다

FCP, ③에 맞지 않는다

로딩의 시작만 잡는다

스플래시 화면이나 로딩 표시만 떠도 FCP가 된다. 주 콘텐츠가 보였는지는 알 수 없다

TTFB, ③에 맞지 않는다

화면에 보이는 결과가 아니다

서버와 연결의 응답 속도를 재는 기반 지표다. 첫 바이트가 빨라도 SPA처럼 내용은 늦게 그려질 수 있다

① 로딩이라는 측면은 LCP가 대표한다. TTFB는 느린 서버 응답을, FCP는 렌더링을 막는 리소스를 찾을 때 쓴다.
web.dev가 제외 이유를 직접 밝히지는 않아, CWV 조건과 지표 문서의 설명을 맞춰 정리했다. 출처: web.dev의 vitals, lcp, ttfb 문서
--- ## good과 poor를 가르는 기준값
GOOD개선 필요POOR
LCP2.5초 이하4초 이하4초 초과
INP200ms 이하500ms 이하500ms 초과
CLS0.1 이하0.25 이하0.25 초과
FCP1.8초 이하3초 이하3초 초과
TTFB0.8초 이하1.8초 이하1.8초 초과
기준값은 web-vitals가 내보내는 LCPThresholds 등의 상수와 같다. 판정은 p75로 한다(1장 마지막 장).
--- ## LCP 후보는 계속 바뀐다

28ms후보: 제목 (H1)

1052ms후보: 이미지 (IMG)

더 큰 요소가 그려지면 **후보가 바뀐다** 탭, 스크롤, 키 입력이 들어오면 브라우저는 후보 기록을 멈춘다 그래서 **언제 값을 확정할지** 정해야 한다. 4장에서 다룬다
--- ## LCP를 네 구간으로 나누면 고칠 곳이 보인다
LCP 요소가 이미지일 때, web.dev 권장 비율
① 약 40%② 10%↓③ 약 40%④ 10%↓
① TTFB

HTML 첫 바이트까지

이동을 시작해 HTML 첫 바이트를 받기까지

길어지는 경우: 느린 서버, CDN 캐시 미스, 리다이렉트

② 리소스 요청 지연

요청 시작까지

브라우저가 HTML에서 LCP 이미지를 발견해 요청하기까지

길어지는 경우: JS로 넣는 이미지, lazy 로딩, CSS 배경

③ 리소스 다운로드

내려받는 시간

요청한 이미지가 모두 도착하기까지

길어지는 경우: 큰 이미지, 캐시 없음, 동시에 받는 다른 요청

④ 요소 렌더링 지연

그려지기까지

도착한 이미지가 화면에 실제로 그려지기까지

길어지는 경우: 렌더링을 막는 CSS와 JS, 바쁜 메인 스레드

네 구간의 합이 곧 LCP다. "지연"이 붙은 ②와 ④는 0에 가까울수록 좋다. LCP가 텍스트면 ②와 ③은 0이다.
비율은 지침이다. LCP가 꾸준히 2.5초 안이면 비율은 크게 상관없다(web.dev/articles/optimize-lcp). web-vitals/attribution으로 네 구간 값을 받을 수 있다.
--- ## INP: 상호작용 하나를 세 구간으로 나눈다
입력 지연핸들러가 시작되기까지원인 후보: 메인 스레드가 다른 작업 중
처리 시간이벤트 핸들러 실행원인 후보: 무거운 핸들러
다음 화면까지스타일, 레이아웃, 그리기원인 후보: 많은 DOM 변경
예를 들어

핸들러가 50ms 만에 끝나더라도, 그 전에 300ms짜리 작업이 실행 중이었다면

INP
350ms 이상
--- ## INP는 "거의 가장 느린" 상호작용
예전 FID (2024년 3월 12일까지)
첫 입력

첫 상호작용의 입력 지연만 측정했다

INP, 상호작용 50번 미만
1위

가장 느린 것

INP, 50번 이상 100번 미만
2위

두 번째로 느린 것

페이지에 머무는 동안의 **모든 상호작용**을 대상으로 한다. 오래 머문 페이지에서 한 번 튄 값이 INP가 되지 않도록, 상호작용 50번마다 가장 느린 것부터 하나씩 제외한다. --- ## CLS: 레이아웃 이동을 점수로 매긴다

영향 영역 0.75

이동 거리 0.25

0.75 × 0.25
= 0.1875

### 이동 한 번의 점수 **영향 비율 × 거리 비율.** 화면 절반을 차지한 요소가 화면 높이의 25%만큼 내려가면 0.1875로, 이 한 번만으로 "개선 필요" 구간이다 ### 이동이 여러 번이면 - 간격이 1초 미만인 이동을 한 묶음으로 본다(최대 5초) - 합이 가장 큰 묶음의 점수가 CLS다 - 클릭, 탭, 키 입력 뒤 500ms 안의 이동은 제외한다
--- ## 사용자 한 명이 아니라 p75로 판정한다
페이지 로드의 75%
p75

왜 75인가

방문 대부분이 목표 성능을 경험했다고 볼 수 있고, 이상값 몇 개에 크게 흔들리지 않는다

그래서 수집할 때도

분포를 보존해야 한다. 평균만 저장하면 p75를 다시 계산할 수 없다

같은 페이지라도 사용자마다 기기, 네트워크, 캐시 상태가 다르다. p75가 good이면 페이지 로드의 75% 이상이 good이라는 뜻이다. 근거: web.dev "Defining the Core Web Vitals metrics thresholds"
---
2장
# 왜 재나 매출과 검색, 그리고 개발 환경과 다른 실제 사용자 --- ## 성능 개선 뒤 매출과 참여가 늘어난 사례
VODAFONE
+8%

판매
LCP 31% 개선

랜딩 페이지 A/B 테스트

REDBUS
+7%

판매
검색 페이지 INP 870ms대 → 350ms대 등

기간과 산정 방법은 공개하지 않음

YAHOO! JAPAN 뉴스
+15%

세션당 페이지뷰
CLS 0.2 개선

개선 전후 비교. 원문도 "상관관계"라고 표현

각 회사가 직접 발표한 수치다. 인과관계를 보여 준 것은 A/B 테스트를 한 Vodafone뿐이다. 우리 서비스에서도 같으리라는 보장은 없으니 **우리 서비스의 값을 직접 측정해야 한다.**
--- ## 검색 순위에도 반영된다. 다만 가장 중요한 요소는 아니다
GOOGLE SEARCH CENTRAL

"Core Web Vitals는 순위 시스템에서 사용된다"

GOOGLE SEARCH CENTRAL

"경험이 좋지 않더라도 가장 관련 있는 콘텐츠를 보여 주려 한다"

유용한 콘텐츠가 많은 검색어에서는 좋은 페이지 경험이 도움이 된다

검색에서는 콘텐츠의 관련성이 먼저다. CWV는 순위보다 **사용자 경험을 확인하려고** 측정한다.
--- ## Lighthouse 점수로는 왜 부족한가
랩 데이터

Lighthouse, DevTools

- 기기와 네트워크 조건이 하나로 고정 - 사용자 입력이 없어 **INP를 측정할 수 없다** - 페이지 로드 구간만 측정
필드 데이터

실제 사용자 브라우저

- 사용자마다 기기와 네트워크가 다르다 - 실제 클릭, 탭, 키 입력이 들어온다 - 페이지를 떠날 때까지 측정
필드나빠진 지표를 찾는다
랩재현하고 고친다
필드나아졌는지 확인한다
랩 도구에서는 TBT(Total Blocking Time, 로드 중 메인 스레드가 막힌 시간)로 INP 문제를 가늠한다. INP를 대신하지는 못한다.
--- ## PageSpeed Insights의 필드 데이터만으로는 부족한 이유
브라우저

Chrome만

데스크톱과 Android. iOS의 Chrome, Android 앱 웹뷰, Edge는 제외된다

페이지

방문이 많은 공개 페이지만

검색 엔진이 색인할 수 있고 방문자 수가 기준 이상이어야 한다. 기준은 비공개

기간

최근 28일

28일치를 합산한 값. 매일 갱신된다

분석 기준

우리 기준으로 못 나눈다

배포 버전, 화면, 실험군별로 볼 수 없다

PageSpeed Insights 상단의 필드 데이터는 **CrUX**(Chrome 사용자 경험 보고서)에서 가져온다. 출발점으로는 좋지만 위와 같은 한계가 있다. --- ## 그래서 직접 수집한다
사용자 브라우저실제 기기, 실제 클릭
web-vitals성능 기록을 지표로
우리 서버페이지를 떠날 때 전송
대시보드화면별, 버전별 p75

빨리 알 수 있다

배포 후 나빠진 지표를 다음 날 확인한다. 28일 평균을 기다릴 필요가 없다

원하는 기준으로 나눠 본다

화면, 기기, 배포 버전, 실험군

원인 정보도 함께 받는다

LCP 요소가 무엇이었는지, 어떤 클릭이 느렸는지

대신 값이 서버에 도착하지 않은 경우도 직접 챙겨야 한다. 4장에서 다룬다.
---
3장
# 어떻게 재나 브라우저의 성능 기록과 web-vitals --- ## 브라우저가 성능 기록을 남긴다 ```js new PerformanceObserver((list) => { for (const e of list.getEntries()) { console.log(Math.round(e.startTime), e.element?.tagName) } }).observe({type: 'largest-contentful-paint', buffered: true}) ``` | 기록 종류 | `navigation` | `paint` | `largest-contentful-paint` | `layout-shift` | `event`, `first-input` | | --------- | ------------ | ------- | -------------------------- | -------------- | ---------------------- | | 지표 | TTFB | FCP | LCP | CLS | INP |
DevTools 콘솔에 붙여 넣으면 LCP 후보가 바뀔 때마다 출력된다. buffered: true를 주면 스크립트가 늦게 실행돼도 그 전에 쌓인 기록을 받을 수 있다.
--- ## 성능 기록은 브라우저 엔진이 남긴다
브라우저 엔진네트워크, 렌더링, 입력을 처리하다가
시각을 기록그 순간을 timeOrigin 기준 ms로
Performance Timeline기록을 버퍼에 보관
PerformanceObserverJS가 구독해서 받는다
| 기록 종류 | 정의한 명세 | 표준화 단계 | | ------------------------------- | ------------------------- | ---------------------- | | 공통 틀 (`PerformanceObserver`) | Performance Timeline | W3C 후보 권고안 초안 | | `navigation` | Navigation Timing Level 2 | W3C 작업 초안 | | `paint` | Paint Timing | W3C 작업 초안 | | `largest-contentful-paint` | Largest Contentful Paint | W3C 작업 초안 | | `event` | Event Timing | W3C 작업 초안 | | `layout-shift` | Layout Instability | **WICG 커뮤니티 초안** |
JS가 시간을 재는 것이 아니라 엔진이 남긴 기록을 받아 본다. 그래서 스크립트가 늦게 실행돼도 기록된 시각은 그대로다. 표준화 단계는 2026-10-19 w3.org/TR, wicg.github.io 기준
--- ## 계산 규칙은 web-vitals에 맡긴다
```js import {onCLS, onINP, onLCP} from 'web-vitals' onLCP(console.log) onINP(console.log) onCLS(console.log) ``` LCP 확정, INP 선정, CLS 묶음 계산, 숨겨진 뒤의 그리기 제외, 뒤로 가기 복원 처리까지 Google의 web-vitals 라이브러리가 맡는다.
| 콜백이 받는 값 | 뜻 | | ---------------- | ------------------------------------------- | | `name`, `value` | 지표 이름과 값 | | `rating` | `good`, `needs-improvement`, `poor` | | `id` | 페이지 로드마다 새로 생성. 보고를 묶는 기준 | | `navigationType` | `back-forward-cache` 등 |
web-vitals/attribution에서 불러오면 원인 정보(LCP 요소, 느린 구간)가 함께 전달된다.
--- ## 직접 해 보기: 로그는 언제 출력될까
페이지를 연다출력 없음
아무 곳이나 클릭LCP조금 뒤
다른 탭에 다녀오기CLSINP
다시 클릭, 탭 전환값이 바뀐 지표만 다시
값은 페이지를 열자마자 나오지 않는다. **사용자가 무언가 하거나 화면을 떠날 때** 나온다. 4장의 내용은 대부분 여기서 출발한다.
--- ## 브라우저마다 받을 수 있는 지표가 다르다 | 지표에 필요한 기록 | Chromium 계열 | Firefox | Safari | | ------------------------------ | ------------- | -------- | -------- | | LCP (`LargestContentfulPaint`) | 77 | 122 | 26.2 | | INP (`interactionId`) | 96 | 144 | 26.2 | | CLS (`LayoutShift`) | 77 | **없음** | **없음** |

iOS는 Safari 기준

iOS의 Chrome, Firefox, 앱 웹뷰(WKWebView)도 같은 WebKit 엔진이다. 26.2 이전에는 TTFB와 FCP만 수집된다

Android 웹뷰는 Chrome 기준

Chromium 기반이라 기기에 설치된 WebView 버전의 Chrome과 같다

CLS 건수가 적은 것은 정상

web-vitals는 지원하지 않는 브라우저에서 오류 없이 아무 값도 보고하지 않는다

MDN browser-compat-data 8.1.6
---
4장
# 수집할 때 생기는 질문 다섯 가지 값이 서버에 도착하지 않는 경우 ---
이 장의 원칙
## CWV 값은 사용자가
**페이지를 떠날 때** 확정된다

LCP 후보가 바뀐다

CLS 이동 점수가 누적된다

INP 더 느린 클릭이 나오면 갱신된다

--- ## 이 장에서 답할 질문 다섯 가지
1"console.log를 걸었는데 왜 안 찍혀요?"
2"CLS가 같은 페이지에서 두 번 왔어요"
3"LCP가 FCP보다 적게 모여요. 데이터 빠진 거죠?"
4"떠날 때 fetch로 보내면 되죠?"
5"Next.js의 useReportWebVitals면 되죠?"
---
1"왜 안 찍혀요?"
## 지표마다 보고 시점이 다르다
문서 열림
첫 그림FCP
loadTTFB
첫 클릭, 키 입력LCP조금 뒤
계속 사용
숨겨질 때CLSINP입력이 없었다면 LCP도

TTFB

load 전에 떠나면 보고되지 않는다

FCP, LCP

그리기 전에 숨겨지면 보고되지 않는다

CLS, INP

원래 숨겨질 때 보고된다

---
1"왜 안 찍혀요?"
## 값이 없으면 콜백도 불리지 않는다
① 측정한 값이 있나value >= 0
② 보고 시점인가숨겨질 때, 확정될 때
③ 첫 보고이거나 값이 바뀌었나같은 값이면 다시 부르지 않는다
콜백 호출onINP(cb)의 cb
상호작용이 없던 페이지 로드
INP 없음

0이 아니라 값 자체가 없다. 지표 값은 -1에서 시작한다

레이아웃 이동이 없던 페이지 로드
CLS 0

CLS만 0에서 시작하므로 0도 보고된다

서버에 INP가 없다는 사실만으로는 클릭이 없었던 것인지, 클릭은 있었지만 받지 못한 것인지 구별할 수 없다. web-vitals 6.2.3 src/lib/bindReporter.ts
---
2"두 번 왔어요"
## 숨겨질 때마다 다시 보고된다
보임
숨김CLS 0
다시 보임
위쪽에 요소 삽입레이아웃 이동 발생
숨김CLS 0.1124같은 id

서버에서는 id로 묶는다

따로 세면 탭을 오간 페이지 로드가 두 번 집계된다. 첫 값과 마지막 값 중 무엇을 쓸지 정해 둔다

콜백이 받는 metric은 매번 같은 객체

저장해 둔 객체를 나중에 읽으면 그사이 바뀐 값이 보인다

---
3"적게 모여요"
## 백그라운드 탭으로 열린 페이지는 그리기 지표가 빠진다
TTFB
5/5
FCP
0/5
LCP
0/5
CLS
0/5
INP
5/5
- 10ms에서 18ms 만에 화면에 보이게 됐지만 결과는 같았다 - 한 번이라도 숨겨졌다면 **그 뒤에 그려진 것은 측정하지 않는다.** 사용자가 보지 못한 화면이기 때문이다 - CLS는 FCP가 보고된 뒤부터 측정하므로 함께 빠졌다
Chromium 156, web-vitals 6.2.3. 보고된 페이지 로드 수 / 전체. 포그라운드 탭(대조)은 다섯 지표 모두 5/5
---
3"적게 모여요"
## `load` 전에 떠나면 TTFB가 보고되지 않는다
첫 바이트 도착TTFB 값은 이때 이미 정해진다
load까지 대기navigation 기록의 나머지 값이 채워질 때까지
보고load 다음 task
1초 뒤 이탈 (load는 3초)
TTFB 0/5

FCP, LCP, CLS는 5/5

5초 뒤 이탈
TTFB 5/5

모두 보고됨

수집된 TTFB는 **`load`까지 머문 페이지 로드에 치우친다.** 서버가 느려 `load`도 늦어지는 페이지일수록 느린 TTFB가 더 많이 빠질 수 있다. ---
3"적게 모여요"
## 뒤로 가기로 복원된 페이지는 측정 기준이 다르다
| 클릭 핸들러 | 처음 로드 INP | 복원 뒤 INP | | ----------- | ------------- | ----------- | | 0ms | 16ms | **8ms** | | 20ms | 24ms | **8ms** | | 60ms | 64ms | 64ms |
- **bfcache**: 뒤로, 앞으로 가기 때 페이지를 메모리에 보관했다가 그대로 복원하는 캐시 - 복원 뒤 FCP와 LCP는 프레임 두 개를 그리는 시간(약 16ms에서 39ms) - 복원 뒤 TTFB는 0 - 40ms 미만의 클릭은 8ms로 보고된다
navigationType이 back-forward-cache인 값은 따로 분리해서 본다. 복원 비율이 늘면 LCP p75가 좋아진 것처럼 보일 수 있다.
---
4"fetch로 보내면 되죠?"
## 페이지가 닫혀도 전송되는 방법 두 가지
방법 1

navigator.sendBeacon(url, data)

응답을 확인할 수 없다. 반환값 true는 전송 대기열에 넣었다는 뜻이다

방법 2

fetch(url, {keepalive: true, ...})

문서가 아직 남아 있다면 응답을 확인할 수 있다

- 일반 요청은 문서가 사라질 때 **함께 취소될 수 있다** - 진행 중인 keepalive 요청의 본문 크기는 **모두 합쳐 64KiB로 제한된다**(Fetch 명세). 원인 정보를 많이 담으면 한도에 가까워진다 ---
4"fetch로 보내면 되죠?"
## sendBeacon이 성공해도 서버에 도착했다는 뜻은 아니다 | 보내는 방법 | 서버가 200 | 서버가 400 | CORS 거부 | | --------------- | ---------- | ---------- | ------------------------ | | sendBeacon | 성공 | **성공** | **성공** (서버 수신 0건) | | keepalive fetch | 성공 | 실패 | 실패 |
sendBeacon의 반환값으로 알 수 있는 것은 브라우저 전송 대기열에 들어갔는지까지다. 400 응답이나 CORS 거부도 대기열에는 들어간다.
OpenTelemetry JS OTLP exporter 0.57.2(sendBeacon)와 0.223.0(keepalive fetch)이 보고한 결과, 각 조합 2번. 블로그 시리즈 2편, cwv-otel-grafana/experiments/e2-exporter
---
4"fetch로 보내면 되죠?"
## 페이지를 떠날 때 이벤트 발생 순서
1beforeunloadvisible
2pagehidevisiblewindow에서만 발생한다. document에 등록한 리스너는 호출되지 않았다
3visibilitychangeweb-vitals가 여기서 CLS와 INP를 보고한다
4unload
pagehide에서만 전송하면 CLS와 INP는 아직 보고되기 전이다. web-vitals 다음 배포부터는 pagehide에서도 보고
같은 탭에서 링크로 이동, Chromium 156에서 2번 모두 같은 결과. visibilitychange는 window capture, document, window 순으로 호출됐다. cwv-otel-grafana/experiments/e3-lifecycle
---
4"fetch로 보내면 되죠?"
## 권장하는 방법: 숨겨질 때 모아서 한 번에
```js import {onCLS, onINP, onLCP} from 'web-vitals' const queue = new Set() const add = (metric) => queue.add(metric) onCLS(add) onINP(add) onLCP(add) addEventListener('visibilitychange', () => { if (document.visibilityState !== 'hidden') return if (queue.size === 0) return const body = JSON.stringify([...queue]) navigator.sendBeacon('/analytics', body) queue.clear() }) ```

왜 visibilitychange인가

web-vitals는 같은 이벤트를 window capture 단계에서 먼저 받는다. 그래서 이 리스너가 실행될 때는 CLS와 INP가 이미 queue에 들어 있다

왜 Set인가

같은 지표가 다시 보고돼도 같은 객체이므로 하나만 남는다

web-vitals README의 "Batch multiple reports together"를 줄인 것
---
4"fetch로 보내면 되죠?"
## 도착 여부는 서버에서 센다 | 보낸 곳 | TTFB | FCP | LCP | INP | CLS | | ------------------------------ | ---- | --- | --- | ----- | ----- | | `pagehide`, `visibilitychange` | 1 | 1 | 1 | **0** | **0** | | `visibilitychange`만 | 1 | 1 | 1 | 1 | 1 |

오류는 어디에도 없었다

콘솔과 서버 로그 모두 오류가 없었다. TTFB, FCP, LCP만 확인했다면 정상이라고 판단했을 것이다

그래서

수집 코드를 바꾸면 실제로 페이지를 떠나 보고, 지표별로 보낸 건수와 받은 건수를 비교한다

원인은 OpenTelemetry JS(sdk-metrics 2.9.0 이상)가 두 번째 전송 전에 첫 번째 전송의 응답을 기다린 것이다(블로그 시리즈 2편). 도구가 달라도 확인 방법은 같다
---
5"useReportWebVitals면 되죠?"
## INP는 클릭 직후 처리되지 않는다
클릭핸들러 실행
다음 화면렌더링
기록 도착web-vitals가 수신
idle까지 대기6.2.3: 최대 1초
4.2.1: 상한 없음
INP 반영이후 보고 가능

왜 기다리나

한 상호작용에 속한 기록이 모두 도착할 때까지 기다리기 위해서다(소스 주석). idle은 브라우저가 할 일이 없는 때다

측정해 보니

Chromium에서는 클릭 뒤 다른 입력이 없으면 idle 콜백이 호출되지 않았다. 마우스를 움직이면 그때 처리된다

---
5"useReportWebVitals면 되죠?"
## 대기 중에 페이지를 떠나면 INP가 보고되지 않는다
WEB-VITALS 6.2.3 (지금 npm 최신)
0.1초 뒤1/10
0.3초 뒤0/10
0.6초 뒤1/10
1.5초 뒤10/10
MAIN (다음 배포 예정, #809)
0.1초 뒤10/10
0.3초 뒤10/10
0.6초 뒤10/10
1.5초 뒤10/10

원인

숨겨질 때 보고 처리가 먼저 실행되고, 대기 중이던 클릭 처리는 그 뒤에 실행된다

수정

2026-10-15 main에 병합. npm 최신은 아직 6.2.3

배포 전까지는

INP만 reportAllChanges를 켜고 id별 마지막 값을 보낸다(30번 중 30번 보고)

---
5"useReportWebVitals면 되죠?"
## Next.js 16.3.5에는 web-vitals 4.2.1이 내장되어 있다
4.2.1, 클릭 1.5초 뒤 이탈
0/5

클릭 뒤 다른 입력 없음

4.2.1, 클릭 4.5초 뒤 이탈
0/5

클릭 뒤 다른 입력 없음

6.2.3, 클릭 1.5초 뒤 이탈
10/10

1초 상한이 있어 보고됨

- `useReportWebVitals`는 Next.js에 내장된 4.2.1로 측정한다. 4.2.1에는 **대기 시간 1초 상한이 없다** - 직접 설치한 web-vitals와 함께 쓰면 같은 페이지 로드라도 값과 `id`가 서로 다르다 - 프레임워크가 제공하는 도구도 **내장된 web-vitals 버전**이 페이지를 떠나기 직전의 값을 어떻게 처리하는지 확인해야 한다 ---
5"useReportWebVitals면 되죠?"
## 측정 이야기: 1.28초의 정체
클릭을 1.3초 간격으로 반복
1.28초

"클릭 후 1.28초면 idle이 온다"?

클릭을 3.5초 간격으로 반복
약 3.5초

idle 시각도 함께 늦어졌다

정체
다음 클릭

idle이 아니라 다음 입력이 들어간 시각이었다

- 측정 방법 자체가 결과에 영향을 준다. **조건을 하나 바꿔 다시 측정하면** 드러난다 - 자동화 도구 때문인지 확인하려고 DevTools를 연결하지 않은 Chrome에 OS 수준 클릭으로 다시 측정했다. 결과는 같았다 - 확인한 것은 "다른 입력이 없으면 idle 콜백이 호출되지 않는다"까지이고, 원인은 아직 확인하지 못했다 --- ## 원칙 하나로 다섯 질문에 답하기 > CWV 값은 사용자가 **페이지를 떠날 때** 확정된다
1. 왜 안 찍혀요?값이 확정될 때 보고되고, 값이 없으면 보고되지 않는다
2. 왜 두 번 와요?숨겨질 때마다 그때까지의 값을 보고한다. 돌아와서 값이 바뀌면 다시 온다
3. 왜 적게 모여요?보지 않은 화면, 확정 전에 떠난 페이지, 지원하지 않는 브라우저에서는 값이 원래 없다
4. 언제 어떻게 보내요?숨겨질 때 한 번, 페이지가 닫혀도 전송되는 방법으로 보낸다. 도착 여부는 서버에서 센다
5. 기본 도구면 돼요?내장된 web-vitals 버전이 떠나기 직전의 값을 어떻게 처리하는지 확인한다
--- ## 참고 - 블로그 시리즈 1편: [web-vitals는 언제 핵심 웹 지표를 보고하는가](https://yceffort.kr/2026/10/web-vitals-report-timing) - 블로그 시리즈 2편: [페이지를 떠나는 순간 핵심 웹 지표를 보내기](https://yceffort.kr/2026/10/cwv-send-on-page-leave) - [web-vitals v6.2.3](https://github.com/GoogleChrome/web-vitals/tree/v6.2.3), INP 누락 [#805](https://github.com/GoogleChrome/web-vitals/issues/805)와 수정 [#809](https://github.com/GoogleChrome/web-vitals/pull/809) - web.dev: [LCP](https://web.dev/articles/lcp), [INP](https://web.dev/articles/inp), [CLS](https://web.dev/articles/cls), [기준값을 정한 방법](https://web.dev/articles/defining-core-web-vitals-thresholds), [랩과 필드의 차이](https://web.dev/articles/lab-and-field-data-differences) - 사례: [Vodafone](https://web.dev/case-studies/vodafone), [redBus](https://web.dev/case-studies/redbus-inp), [Yahoo! JAPAN 뉴스](https://web.dev/case-studies/yahoo-japan-news) - [Google Search Central: 페이지 경험](https://developers.google.com/search/docs/appearance/page-experience), [CrUX 수집 방법](https://developer.chrome.com/docs/crux/methodology) - 측정 코드: [blog-experiments/cwv-otel-grafana](https://github.com/yceffort/blog-experiments/tree/main/cwv-otel-grafana)