🚀 Next.js 심화 8장: Performance Deep Dive — Core Web Vitals 실전 튜닝

📋 목차

• 📌 이 문서를 읽기 전에
• 🤔 왜 알아야 하는가
• 🏗️ 비유로 먼저 이해하기
• 📊 Core Web Vitals — 세 가지 점수판 🟢
• ⚡ LCP 튜닝 — 가장 큰 요소를 가장 빠르게 🟡
• 🖱️ INP 튜닝 — 클릭 반응을 50ms 이내로 🟡
• 📐 CLS 튜닝 — 레이아웃 이동 0으로 만들기 🟡
• 📦 번들 최적화 — 필요한 것만 내려보내기 🔴
• 💥 에러 해결 카탈로그
• 🏁 이번에 배운 내용 총정리
• 📝 마무리 퀴즈
• 🔗 더 알아보기

📌 이 문서를 읽기 전에

⏱️ 예상 읽기 시간: 18분 (전체) / 핵심 파트만: 9분

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 영철(신입): "Lighthouse 점수가 47이에요. 기술 PM인 영수 씨가 'Performance 점수 90 이상 올려야 한다'고 했는데, 뭘 어떻게 건드려야 하는지 모르겠어요. 일단 이미지 압축하면 되나요?"
• 영호(리드): "이미지 압축은 시작이에요. Core Web Vitals 세 가지(LCP, INP, CLS)를 각각 진단하고, 원인에 맞는 최적화를 해야 해요. Lighthouse가 각 지표의 점수를 알려주니까 낮은 것부터 순서대로 공략해봐요."

🗺️ 이 문서의 흐름
Core Web Vitals 개념 → LCP 최적화 → INP 최적화 → CLS 최적화 → 번들 최적화

🎯 이 문서를 다 읽으면 할 수 있는 것

• Lighthouse 결과에서 LCP, INP, CLS 점수를 보고 각각의 원인을 파악할 수 있다
• 각 지표별 최적화 기법을 실제 코드로 적용할 수 있다
• next/dynamic으로 코드 스플리팅을 적용해 초기 번들 크기를 줄일 수 있다

🤔 왜 알아야 하는가

성능은 측정 가능한 비즈니스 지표야. 감이 아니야:

구글은 Core Web Vitals를 검색 랭킹 신호로 사용해. 느린 사이트는 검색 결과에서 밀린다는 뜻이야.

🏗️ 비유로 먼저 이해하기

🧒 5살에게 설명한다면?
음식점 서비스 품질을 세 가지로 평가해봐:

• LCP (첫 음식이 나오는 속도): 주문하고 첫 음식까지 2.5초 이내
• INP (종업원 반응 속도): 손 들면 200ms 이내 눈맞춤
• CLS (상차림 안정성): 음식 가져다 놓을 때 다른 그릇이 밀려나지 않음

세 가지 다 좋아야 "좋은 음식점"이야. 음식이 맛있어도(기능) 서비스가 나쁘면 손님이 안 와(이탈률 증가).

📊 Core Web Vitals — 세 가지 점수판 🟢

🎯 이 섹션을 읽고 나면:

• LCP, INP, CLS가 각각 무엇을 측정하는지 설명할 수 있다
• 각 지표의 Good/Needs Improvement/Poor 기준값을 안다

진단 도구:

• Lighthouse (Chrome DevTools) — 로컬 시뮬레이션
• Chrome DevTools Performance 탭 — 실제 렌더링 타임라인
• Vercel Speed Insights — 실제 사용자 데이터(RUM)

💡 한 줄로 기억하기
LCP는 "첫인상", INP는 "반응성", CLS는 "안정감". 세 가지 모두 사용자 체감에 직결돼.

⚡ LCP 튜닝 — 가장 큰 요소를 가장 빠르게 🟡

🎯 이 섹션을 읽고 나면:

• LCP 요소를 식별하고 priority, preload로 우선 로드할 수 있다
• 렌더링 전략으로 LCP를 개선하는 방법을 안다

LCP를 느리게 만드는 주범:

1. 히어로 이미지에 priority 없음 → Lazy Loading으로 늦게 로드
2. TTFB(서버 응답) 느림 → Dynamic Rendering인데 DB 쿼리가 느림
3. 폰트 로드 지연 → Google Fonts 외부 요청

// ✅ LCP 이미지 최적화 체크리스트
 
// 1. priority 추가 (preload 처리)
<Image
  src="/hero.jpg"
  alt="히어로 배너"
  width={1200}
  height={630}
  priority              // ← 절대 빠뜨리면 안 됨
  sizes="(max-width: 768px) 100vw, 1200px"
/>
 
// 2. fetchPriority="high" (Next.js 16+)
<Image
  src="/hero.jpg"
  fetchPriority="high"  // 브라우저에 명시적으로 우선순위 힌트
  // ...
/>

서버 응답(TTFB) 개선:

// ✅ DB 쿼리가 LCP를 늦추는 경우 — ISR 또는 PPR로 전환
 
// Dynamic Rendering → ISR로 바꿔 TTFB 개선
export const revalidate = 60  // 60초마다 재생성
 
// 또는 PPR로 정적 셸을 먼저 보내고 DB 데이터는 스트리밍
export const experimental_ppr = true
// Suspense로 DB 조회하는 부분만 감싸기

🖱️ INP 튜닝 — 클릭 반응을 50ms 이내로 🟡

🎯 이 섹션을 읽고 나면:

• INP가 나쁜 원인을 파악하고 Long Task를 분할하는 방법을 안다
• next/dynamic으로 클라이언트 JS를 지연 로드해 하이드레이션 비용을 줄일 수 있다

INP는 메인 스레드가 블로킹되면 나빠져. JS가 실행 중이면 클릭에 반응을 못하거든.

INP를 나쁘게 만드는 주범:

1. 큰 JS 번들 → Hydration에 오래 걸림
2. Long Task (50ms 이상 실행되는 JS)
3. 이벤트 핸들러에서 무거운 동기 연산

// ✅ 1. next/dynamic으로 코드 스플리팅 — 초기 번들에서 제외
import dynamic from 'next/dynamic'
 
// 에디터, 차트 같은 무거운 컴포넌트는 지연 로드
const RichTextEditor = dynamic(
  () => import('@/components/features/posts/RichTextEditor'),
  {
    loading: () => <div>에디터 로딩 중...</div>,
    ssr: false,   // SSR 제외 (브라우저 API 의존 컴포넌트)
  }
)
 
// ✅ 2. 서버 컴포넌트로 전환 — 클라이언트 번들에서 로직 제거
// 클라이언트에서 데이터 가공하는 로직을 서버 컴포넌트로 이동
// → Hydration 비용 ↓ → INP ↑
 
// ✅ 3. scheduler.yield()로 Long Task 분할
async function processLargeList(items: string[]) {
  for (const item of items) {
    await processItem(item)
 
    // 메인 스레드에 잠시 양보 → 클릭 이벤트가 끼어들 수 있게 함
    if (typeof scheduler !== 'undefined') {
      await scheduler.yield()
    }
  }
}

📐 CLS 튜닝 — 레이아웃 이동 0으로 만들기 🟡

🎯 이 섹션을 읽고 나면:

• CLS가 발생하는 원인 3가지를 알고 각각의 해결책을 적용할 수 있다

CLS 발생 원인과 해결책:

원인 1: 이미지/영상 크기 미지정

// ❌ 크기 없는 이미지 → 로드 전 공간 없음 → 로드 후 레이아웃 이동
<img src="/photo.jpg" alt="..." />
 
// ✅ next/image로 미리 공간 예약
<Image src="/photo.jpg" alt="..." width={800} height={400} />

원인 2: 동적으로 삽입되는 콘텐츠 (광고, 배너)

// ❌ 배너가 나중에 삽입되어 아래 콘텐츠가 밀림
<div>  {/* 나중에 배너 삽입 */}  </div>
<main>게시글 목록</main>
 
// ✅ 배너 영역 높이를 미리 예약
<div style={{ minHeight: '90px' }}>  {/* 광고 들어올 공간 예약 */}  </div>
<main>게시글 목록</main>

원인 3: 폰트 교체(FOUT) — 폰트 로드 전후 글자 크기 차이

// ✅ next/font로 FOUT 방지 + size-adjust로 크기 맞춤
import { Inter } from 'next/font/google'
 
const inter = Inter({
  subsets: ['latin'],
  display: 'swap',   // FOUT 허용하지만 layout shift 최소화
  adjustFontFallback: true,  // 시스템 폰트와 크기 자동 맞춤 → CLS 감소
})

📦 번들 최적화 — 필요한 것만 내려보내기 🔴

🎯 이 섹션을 읽고 나면:

• @next/bundle-analyzer로 번들 구성을 시각화할 수 있다
• Tree shaking이 안 되는 패키지를 올바르게 import하는 방법을 안다

# 번들 분석기 설치
npm install @next/bundle-analyzer

// next.config.ts
import withBundleAnalyzer from '@next/bundle-analyzer'
 
const bundleAnalyzer = withBundleAnalyzer({
  enabled: process.env.ANALYZE === 'true',
})
 
export default bundleAnalyzer({
  // ...next config
})

# 번들 분석 실행 → 브라우저에서 treemap 시각화
ANALYZE=true npm run build

흔한 번들 최적화 패턴:

// ❌ lodash 전체 import → 번들에 다 들어감 (70kb+)
import _ from 'lodash'
const result = _.merge(obj1, obj2)
 
// ✅ 필요한 함수만 import → Tree shaking
import merge from 'lodash/merge'
const result = merge(obj1, obj2)
 
// ✅ 또는 ES 모듈 버전 사용
import { merge } from 'lodash-es'

// ❌ moment.js — locale 파일까지 다 들어감 (300kb+)
import moment from 'moment'
 
// ✅ date-fns 또는 dayjs — Tree shaking 완벽 지원
import { format } from 'date-fns/format'
import { ko } from 'date-fns/locale/ko'

next/dynamic으로 클라이언트 번들 분리:

// 무거운 라이브러리를 지연 로드 → 초기 번들 크기 감소
const ChartComponent = dynamic(() => import('@/components/features/Chart'), {
  ssr: false,           // 서버에서 렌더 안 함
  loading: () => <ChartSkeleton />,
})

💥 에러 해결 카탈로그

❌ Lighthouse LCP가 이미지인데 점수가 낮음

체크리스트:

1. <Image> 컴포넌트 사용 중인가?
2. LCP 이미지에 priority 속성 있는가?
3. sizes 속성이 정확한가?
4. 이미지가 CDN에 있는가 (응답 속도)?

❌ window is not defined — SSR 오류

원인: 클라이언트 전용 라이브러리를 SSR에서 실행.

해결책:

const HeavyLibrary = dynamic(() => import('@/components/HeavyLibrary'), {
  ssr: false,  // SSR 비활성화
})

🏁 이번에 배운 내용 총정리

📋 지표별 최적화 요약

⚠️ 절대 하지 말 것

📝 마무리 퀴즈

Q1. LCP가 히어로 이미지 때문에 느리다. 가장 먼저 확인할 Next.js Image 설정은 무엇인가?

✅ 정답: 실제 LCP 이미지에 priority 또는 적절한 preload 의도를 주고, sizes와 크기 정보를 정확히 지정했는지 확인한다.

💡 상세 해설: LCP 이미지는 브라우저가 빨리 발견하고 올바른 크기로 내려받아야 한다. 단순히 압축률만 낮추면 해결되지 않는다. 반대로 모든 이미지에 우선순위를 주면 네트워크 경쟁이 심해져 진짜 중요한 이미지가 늦어질 수 있다.

Q2. 무거운 에디터 때문에 초기 INP가 나빠졌다. 어떤 전략이 적절한가?

✅ 정답: 초기 화면에 필요 없는 에디터는 dynamic import로 분리하고, 상호작용 직전에 로드되도록 설계한다.

💡 상세 해설: INP는 사용자의 입력에 페이지가 얼마나 빨리 반응하는지를 본다. 사용하지도 않은 에디터 JS를 첫 로드에 모두 하이드레이션하면 메인 스레드가 막힌다. 코드 스플리팅, 클라이언트 컴포넌트 경계 축소, 이벤트 핸들러 단순화가 함께 필요하다.

Q3. 영철이의 테스트 타임: 배너가 늦게 로드되며 글 목록이 아래로 밀린다. CLS를 줄이려면 무엇을 해야 할까?

✅ 정답: 이미지와 광고 영역의 width/height 또는 aspect-ratio를 미리 예약하고, fallback도 같은 공간을 차지하게 만든다.

💡 상세 해설: CLS는 뒤늦게 생긴 요소가 기존 레이아웃을 밀어낼 때 악화된다. 데이터가 빨리 오게 하는 것만으로는 부족하다. 스켈레톤, 이미지 크기, 폰트 로딩 전략처럼 "공간을 먼저 약속하는 설계"가 필요하다.

🐣 영철이의 퇴근 일기

오늘은 성능을 Lighthouse 점수 하나로만 보지 않기로 했다. LCP는 발견과 전송, INP는 메인 스레드와 하이드레이션, CLS는 공간 예약 문제라는 식으로 원인을 나눠야 해결책도 정확해졌다.

💡 "성능 개선은 숫자를 낮추는 일이 아니라 병목의 종류를 맞히는 일이다."

다음 PR에서 이미지가 보이면 크기와 sizes를, 클라이언트 컴포넌트가 보이면 초기 JS 필요성을, 스켈레톤이 보이면 실제 콘텐츠와 같은 공간을 차지하는지 확인하겠다. 이제 "느려요"라는 피드백을 받으면 먼저 어떤 Core Web Vitals가 흔들리는지부터 물어볼 수 있다.

🔗 더 알아보기

• Next.js 공식 문서 — Optimizing
• web.dev — Core Web Vitals
• Chrome DevTools — Performance 패널