세 지표가 서로 다른 기다림을 측정해
| 지표 | 좋은 목표 | Next.js에서 쓸 수 있는 수단 |
|---|---|---|
| LCP | 2.5초 미만 | 서버 렌더링, 이미지 preload, 스트리밍, edge 캐시 |
| CLS | 0.1 미만 | next/image 자리 예약, next/font의 교체 흔들림 감소 |
| INP | 200ms 미만 | 서버 컴포넌트로 JavaScript 감축, React transition |
프레임워크 기본값도 활용해야 이점이 생겨
서버 컴포넌트는 전송할 JavaScript를 줄이고, 라우트별 코드 분할은 별도 설정 없이 적용돼. next/image와 next/font는 자산 비용을 줄이고, Link는 목적 라우트를 미리 가져와. Suspense 스트리밍은 실제 완료 시간이 같아도 먼저 쓸 수 있는 화면을 보여 줘.
합성 점수와 현장 지표를 함께 봐
CI에서 Lighthouse를 돌리면 큰 회귀를 빠르게 잡을 수 있어. 하지만 한 기기와 네트워크를 흉내 낸 점수일 뿐이야. Vercel Speed Insights나 자체 Web Vitals reporter로 실제 사용자의 분포를 모아야 진짜 병목을 알 수 있어.
평균만 보면 느린 사용자가 사라져
모바일·지역·페이지별 p75를 나눠 보고, 배포 전후를 같은 조건으로 비교해. 빠른 사용자 다수가 느린 꼬리를 가리는 평균은 제품 경험을 설명하지 못해.
성능 예산을 페이지 유형과 기기 등급별로 정하고 CI의 Lighthouse 회귀선과 실제 사용자 p75를 연결해. LCP가 나쁘면 핵심 자산과 서버 응답, CLS면 예약 공간과 글꼴, INP면 긴 client task를 따라가. 한 번에 한 원인을 바꾸고 배포 전후 분포를 비교해. 점수 90을 만들기 위해 중요한 기능을 숨기거나 측정 경로만 최적화하면 숫자와 제품이 갈라져. 실제 사용자의 느린 지역과 로그인 뒤 화면은 공개 홈 합성 검사에 나타나지 않을 수 있어. 지표는 우승 점수가 아니라 사용자가 막힌 시간을 찾는 센서야. LCP 이미지 지연, 크기 없는 이미지, 긴 client task를 하나씩 주입해 세 지표가 각각 악화되는지 확인해. 수정 뒤 Lighthouse와 실제 Web Vitals p75가 같은 방향으로 움직이는지 보고, 로그인 뒤 느린 화면과 저사양 모바일을 별도 구간으로 나눠.