Core Web Vitals, 세 지표의 합격선은 숫자로 정해져 있습니다

세 지표의 합격선은 공개된 숫자입니다

성능 논의가 겉도는 이유는 기준이 사람마다 다르기 때문입니다. 핵심 지표에는 공개된 합격선이 있습니다. 2026년 10월 19일 공식 문서에서 확인한 값으로, 가장 큰 콘텐츠가 그려지는 시간은 2.5초 이하가 양호입니다. 입력에 대한 반응 시간은 200밀리초 이하가 양호이고 500밀리초를 넘으면 불량입니다. 레이아웃이 밀리는 정도는 0.1 이하가 양호이고 0.25를 넘으면 불량입니다. 이 숫자를 팀이 공유하면 '느리다'는 말이 '2.5초를 넘는다'로 바뀌고, 개선 작업의 완료 조건도 분명해집니다.

평균이 아니라 75번째 백분위수로 봅니다

같은 공식 문서에서 확인한 측정 방법이 하나 더 있습니다. 기준은 실제 사용자 데이터의 75번째 백분위수이고, 모바일과 데스크톱을 나눠서 봅니다. 평균을 쓰지 않는 이유는 소수의 매우 느린 경험이 평균에 묻히기 때문입니다. 반대로 최악값만 보면 이상치에 흔들립니다. 75번째 백분위수는 '대부분의 사용자가 이보다 좋은 경험을 한다'고 말할 수 있는 지점입니다. 그래서 측정 결과를 적을 때는 항상 세 가지를 함께 적습니다. 지표 이름, 75번째 백분위수 값, 그리고 기기 구분입니다. 이 세 가지가 없는 숫자는 비교할 수 없습니다.

몇 건이 기준을 넘는지 세어 봅니다

학습용 가정으로 계산합니다. 가정값은 한 달 페이지뷰가 10,000건이라고 두겠습니다. 75번째 백분위수는 느린 순서로 정렬했을 때 7,500번째 값입니다. 이 값이 기준을 넘는다면 적어도 2,500건은 그보다 더 느립니다. 가정으로 기준 초과 비율이 32퍼센트라면 초과 건수는 3,200건이고 기준을 만족하는 것은 6,800건입니다. 이것이 중간 계산값입니다. 최종 목표는 초과 비율을 25퍼센트 아래로 내리는 것입니다. 그러면 75번째 백분위수 값이 기준 안으로 들어옵니다. 즉 개선 목표를 '몇 초 줄이기'가 아니라 '초과 건수를 몇 건 줄이기'로 적을 수 있습니다.

현장 데이터가 없으면 판단이 어렵습니다

결론을 뒤집는 조건은 데이터 출처입니다. 개발자 장비에서 측정한 값은 네트워크와 기기 성능이 좋아 실제보다 훨씬 낫게 나옵니다. 그래서 그 값으로 합격을 판단하면 안 됩니다. 현장 데이터를 모으는 수단이 없다면 실험실 측정으로 시작하되 '실험실 조건'이라고 적고, 기기와 네트워크 조건을 함께 기록합니다. 두 번째 조건은 트래픽이 적은 페이지입니다. 표본이 적으면 백분위수가 불안정하므로, 페이지별이 아니라 템플릿 단위로 묶어 봅니다. 그래서 보고서에는 표본 수를 함께 적고, 표본이 적은 항목은 참고로만 씁니다.

성능 최적화 실행 전 점검표

• 세 지표의 합격선을 팀이 공유하는 문서에 적었다
• 75번째 백분위수와 기기 구분을 함께 기록한다
• 기준 초과 건수를 세어 개선 목표를 건수로 적었다
• 현장 데이터와 실험실 측정을 구분해 표기했다