2026년 기준 Core Web Vitals: LCP(Largest Contentful Paint, 2.5초 이내), INP(Interaction to Next Paint, 200ms 이내), CLS(Cumulative Layout Shift, 0.1 이내). INP가 FID를 대체한 것이 가장 큰 변화.
웹 성능 최적화 — Core Web Vitals 2026 가이드
한 줄 요약: Core Web Vitals 2026의 핵심은 INP(Interaction to Next Paint)가 FID를 완전 대체했고, LCP 3초 이내 + CLS 0.1 이하 + INP 200ms 이하가 기준이다. Google은 Core Web Vitals를 검색 랭킹 요소로 사용하며, 2025년 3월부터 INP가 FID를 공식 대체했다.
by Lee
한 줄 요약: Core Web Vitals 2026의 핵심은 INP(Interaction to Next Paint)가 FID를 완전 대체했고, LCP 3초 이내 + CLS 0.1 이하 + INP 200ms 이하가 기준이다.
Google은 Core Web Vitals를 검색 랭킹 요소로 사용하며, 2025년 3월부터 INP가 FID를 공식 대체했다. 이 가이드는 각 지표의 측정법, 최적화 전략, 실전 디버깅 방법을 정리한다.
2026년 Core Web Vitals
LCP(Largest Contentful Paint): 뷰포트 내 가장 큰 콘텐츠 요소가 렌더링되는 시간. 3초 이내가 목표. 가장 흔한 원인은 최적화되지 않은 히어로 이미지, 렌더 블로킹 CSS/JS, 느린 서버 응답이다.
INP(Interaction to Next Paint): 사용자 인터랙션(클릭, 탭, 키보드)부터 다음 화면 업데이트까지의 시간. 200ms 이내가 목표. 메인 스레드를 오래 차단하는 JavaScript가 주 원인이다.
CLS(Cumulative Layout Shift): 페이지 로드 중 예기치 않은 레이아웃 이동의 총합. 0.1 이하가 목표. 크기가 지정되지 않은 이미지, 동적으로 삽입되는 광고, 웹폰트 로드 시 FOUT가 주요 원인이다.
web-vitals 라이브러리로 측정import { onLCP, onINP, onCLS } from 'web-vitals'; onLCP(metric => console.log('LCP:', metric.value)); onINP(metric => console.log('INP:', metric.value)); onCLS(metric => console.log('CLS:', metric.value));
LCP 최적화
LCP를 개선하는 핵심 방법: 이미지 최적화(WebP/AVIF, 적절한 사이즈), 서버 응답 시간 단축(CDN, 엣지), 렌더링 차단 리소스 제거(CSS 인라인, JS defer).
INP 최적화
INP를 개선하는 방법: 긴 작업 분할(requestIdleCallback, scheduler.yield), 이벤트 핸들러 최적화, 메인 스레드 부하 감소.
최적화 실전 체크리스트
측정 도구: Chrome DevTools의 Performance 탭, Lighthouse, PageSpeed Insights, Chrome UX Report(CrUX)를 조합하여 측정하라. 실제 사용자 데이터(RUM)가 Lab 데이터보다 중요하다.
실전 디버깅 방법
LCP 디버깅: Chrome DevTools > Performance 탭에서 녹화 후, LCP 마커를 찾아 원인 요소를 확인한다. 대부분 이미지 최적화(WebP + srcset + sizes), 폰트 프리로드, 서버 응답 시간 개선으로 해결된다.
INP 디버깅: PerformanceObserver로 slow interaction을 기록하고, 메인 스레드를 차단하는 긴 태스크를 scheduler.yield()나 requestIdleCallback으로 분할한다.
자주 묻는 질문
더 깊게 공부하려면 어떤 자료를 보면 좋을까요?
기준 문서는 web.dev의 Core Web Vitals 허브와 각 지표 개별 페이지(Optimize LCP, Optimize INP, Optimize CLS)입니다. 지표 정의와 합격선뿐 아니라 원인별 진단·개선 레시피를 가장 체계적으로 다룹니다. INP가 처음이라면 web.dev의 INP 마이그레이션 글로 FID와 무엇이 다른지부터 잡는 것을 권합니다. 측정 도구로는 web-vitals 라이브러리 깃허브 README와 Chrome UX Report(CrUX) 공식 문서가 실측(RUM) 수집의 출발점이고, 깊이 들어가려면 scheduler.yield와 Long Tasks API, requestIdleCallback 명세를 함께 보면 INP 최적화의 메인 스레드 분할 전략이 명확해집니다.
웹 성능 최적화, 한 줄로 정리하면 어떻게 되나요?
2026년 Core Web Vitals의 합격선은 LCP 2.5초 이내, INP 200ms 이내, CLS 0.1 이내 세 가지이며, 2025년 3월부터 INP가 FID를 공식 대체한 것이 가장 큰 변화입니다. LCP는 히어로 이미지·서버 응답·렌더 블로킹 리소스가, INP는 메인 스레드를 오래 잡는 JS가, CLS는 크기 미지정 이미지·광고·웹폰트가 주범입니다. 핵심은 Lighthouse 같은 Lab 점수가 아니라 web-vitals나 CrUX로 모은 실제 사용자 데이터(RUM)를 기준으로, 가장 많이 초과한 지표 하나부터 원인을 찾아 잡아 나가는 것입니다.
실무에서 처음 도입할 때 가장 먼저 확인할 것은 무엇인가요?
측정 기준을 실제 사용자 데이터(RUM)로 맞추는 것이 먼저입니다. Lighthouse 같은 Lab 점수만 보고 최적화하면 실측과 어긋나기 쉬우니, web-vitals 라이브러리로 onLCP·onINP·onCLS를 수집하거나 Chrome UX Report(CrUX)로 현장 수치를 먼저 확보하세요. 그다음 세 지표 중 어느 것이 기준을 벗어났는지 봅니다. LCP는 2.5초, INP는 200ms, CLS는 0.1이 합격선입니다. 셋 다 따로 잡으려 하기보다, 가장 많이 초과한 지표 하나를 골라 그 원인(LCP면 히어로 이미지·서버 응답, INP면 메인 스레드 차단 JS, CLS면 크기 미지정 이미지·광고)부터 손대는 순서를 권장합니다.
가장 자주 발생하는 실수나 함정은 무엇인가요?
아직도 FID를 기준으로 잡고 있는 것이 가장 흔한 착오입니다. 2025년 3월부터 INP가 FID를 공식 대체했으므로, 이제는 인터랙션부터 다음 페인트까지 200ms 이내를 봐야 합니다. 두 번째는 Lab 점수에만 매달리는 것으로, Lighthouse가 90점이어도 실제 사용자 기기에서는 메인 스레드를 오래 잡는 JS 때문에 INP가 무너질 수 있습니다. 세 번째는 CLS를 일으키는 무심한 마크업인데, 이미지에 width·height를 지정하지 않거나 광고·웹폰트를 자리 예약 없이 끼워 넣으면 로드 중 레이아웃이 밀려 점수가 깨집니다. 크기 명시와 폰트 프리로드만으로도 상당 부분 잡힙니다.
다른 대안과 비교했을 때 어떤 상황에 적합한가요?
측정 도구는 목적에 따라 갈라 씁니다. 빠른 개발 중 회귀를 잡고 싶을 때는 Lighthouse나 DevTools Performance 탭 같은 Lab 도구가 적합합니다. 동일 조건에서 반복 측정되고 원인 요소를 바로 짚어 주기 때문입니다. 반면 실제 검색 랭킹에 반영되는 점수를 봐야 한다면 Lab 도구만으로는 부족하고, CrUX나 web-vitals 라이브러리로 모은 실사용자 데이터(RUM)가 기준이 되어야 합니다. 기기·네트워크가 천차만별인 실사용 환경은 Lab 환경과 어긋나기 때문입니다. 정리하면 개발 단계 회귀 탐지는 Lab, 출시 후 모니터링과 우선순위 결정은 RUM이 맞고, INP처럼 사용자 인터랙션에 좌우되는 지표일수록 RUM 비중을 더 높여야 합니다.
성능core-web-vitalsLCPCLSINPSEO
