performance · high priority
Core Web Vitals & 웹 성능 최적화
Google이 정의한 사용자 경험의 핵심 지표
학습 개요
쉬운 설명
복잡한 개념을 실생활 비유로 설명합니다.
“병원 대기실”
LCP는 "병원에 들어가서 의사를 처음 만나는 시간". CLS는 "대기 중에 의자가 갑자기 다른 데로 옮겨져서 엉덩방아 찧는 것". INP는 "버튼을 눌렀을 때 화면이 반응하는 시간". 모두 사용자가 "이 서비스 좋다/나쁘다"를 느끼는 지점입니다.
핵심 개념
LCP - Largest Contentful Paint
가장 큰 콘텐츠(이미지 또는 텍스트 블록)가 화면에 그려지는 시간. 페이지 로딩 속도를 나타냄.
Good: ≤2.5초 / Needs Improvement: 2.5~4초 / Poor: >4초CLS - Cumulative Layout Shift
페이지 로드 중 예상치 못한 레이아웃 이동의 누적 점수. 0에 가까울수록 좋음.
Good: ≤0.1 / Needs Improvement: 0.1~0.25 / Poor: >0.25INP - Interaction to Next Paint
사용자 상호작용(클릭, 탭, 키보드)부터 다음 화면 업데이트까지의 시간. FID 대체 (2024년 3월부터).
Good: ≤200ms / Needs Improvement: 200~500ms / Poor: >500msFID → INP 변경 (2024년 3월)
FID(First Input Delay)는 첫 번째 클릭만 측정했지만, INP는 페이지 전체 수명 동안의 모든 인터랙션의 최대 응답 시간을 측정합니다. 훨씬 사용자 경험을 잘 반영합니다.
실무 적용
어떤 상황에서 사용하는가
Lighthouse 점수가 낮거나 SEO를 개선해야 할 때
어떻게 적용하는가
Chrome DevTools → Lighthouse 측정 → Core Web Vitals 확인 → 문제 지표 개선 → PageSpeed Insights로 실제 사용자 데이터(CrUX) 확인
흔한 실수와 안티패턴
- LCP 이미지에 loading="lazy" 적용하면 오히려 LCP 악화
- will-change를 광범위하게 사용해서 메모리 사용량 증가
- Lighthouse는 합성 데이터라서 실제 사용자 데이터와 다를 수 있음
면접 질문
답변 방향 힌트
LCP/CLS/INP 각각의 정의, Good 기준, 개선 방법을 설명하세요. 실제 수치 개선 경험을 덧붙이세요.
반드시 언급할 키워드
- LCP ≤2.5s
- CLS ≤0.1
- INP ≤200ms
- 측정 도구
- 개선 방법
예상 꼬리 질문
- Lighthouse와 실제 CrUX 데이터가 다른 이유는?
- INP가 높을 때 어떻게 디버깅하나요?