이 페이지에서 다루는 검색 주제
Core Web Vitals(CWV)는 “점수 따기”가 아니라 **사용자가 느끼는 로딩·안정성·상호작용**과 맞닿은 지표입니다. 모든 지표를 동시에 최적화하려 하기보다, **가장 많은 사용자에게 가장 큰 체감**을 주는 병목부터 제거하는 순서가 현실적입니다.
LCP: 무엇이 마지막으로 그려지는가
LCP 후보는 보통 히어로 이미지, 큰 비디오 포스터, 큰 텍스트 블록, 배너입니다.
- 이미지는 **표시 크기**에 맞는 해상도·포맷(webp/avif)·`priority`·responsive srcset을 같이 봅니다.
- 서버 TTFB가 길면 아무리 클라이언트를 줄여도 LCP가 늦습니다. 캐시·오리진 구성·불필요한 리다이렉트 체인을 먼저 확인합니다.
- LCP 요소가 텍스트인데 웹폰트 로드가 늦으면 **시스템 폴백·`font-display: swap`·서브셋**으로 첫 페인트를 앞당깁니다.
CLS: “예약된 공간”이 없으면 레이아웃이 무너진다
광고 슬롯, 임베드, 지연 로드 이미지, 웹폰트 swap이 레이아웃을 밀면 CLS가 튀어납니다. **높이 예약**·**스켈레톤**·**삽입 위치 고정**을 컴포넌트 계약으로 정해 두면 재발이 줄어듭니다.
INP: 메인 스레드를 막지 말 것
클릭·입력 후 반응이 느리면 INP가 나빠집니다. 과도한 번들, 무거운 핸들러, 메인 스레드에서 돌아가는 파싱·레이아웃 강제가 원인인 경우가 많습니다. 상호작용이 많은 페이지는 **코드 분할**, **지연 로딩**, **이벤트 핸들러 단순화**부터 봅니다.
측정: Lighthouse만 믿지 말 것
Lab 데이터(Lighthouse)는 재현에 좋고, Field 데이터(CrUX·RUM)는 실제 사용자 분포를 보여 줍니다. 둘 다 없으면 개선 우선순위가 감에 의존합니다. 필드가 나쁜 페이지부터 Lab으로 원인을 좁히는 순서가 일반적입니다.
실험 방법
한 번에 한 변수만 바꿉니다. 같은 기기·네트워크 프로파일로 여러 번 측정해 분산을 줄입니다. 배포 직후 단일 샘플만 보고 성공을 선언하지 않는 것이 안전합니다.
디자인·기획과의 합의
성능은 개발만의 문제가 아닙니다. “큰 이미지 + 무거운 폰트 + 즉시 로드되는 모든 위젯”을 동시에 요구하면 CWV는 구조적으로 한계에 부딪힙니다. **트레이드오프 표**를 만들어 제품·디자인과 합의하는 편이 장기적으로 더 빠릅니다.
회귀 방지
성능 예산(번들 크기, LCP 이미지 상한, 위젯 개수)을 CI나 릴리즈 체크리스트에 넣지 않으면, 몇 달 뒤 다시 무너집니다. “한 번 고치고 끝”이 아니라 **회귀를 잡는 장치**가 필요합니다.