이미지가 많은 Next.js 사이트에서 LCP 2초 아래로 내리기

포트폴리오나 미디어 사이트처럼 이미지가 화면의 대부분을 차지하는 사이트는 LCP(Largest Contentful Paint)가 거의 항상 이미지입니다. 그래서 이미지 최적화가 곧 성능 최적화입니다.

next/image를 쓰면 자동으로 최적화된다고 알려져 있지만, 기본 설정만으로는 2초를 넘기는 경우가 많습니다. 실제로 효과가 있었던 것부터 순서대로 정리합니다.

1. 히어로 이미지에 priority를 준다#

가장 효과가 큽니다. next/image는 기본이 lazy loading이라, 첫 화면 이미지도 뷰포트 계산 후에 로드됩니다. 그만큼 늦어집니다.

<Image
  src="/images/hero.avif"
  alt=""
  width={1600}
  height={900}
  priority
  fetchPriority="high"
  sizes="100vw"
/>

2. sizes를 정확히 준다#

이게 두 번째로 큽니다. sizes를 생략하면 100vw로 간주해 데스크톱 기준 가장 큰 이미지를 내려받습니다. 그리드 안의 작은 카드에도 2400px 이미지가 들어옵니다.

// 12칼럼 중 7칼럼을 차지하는 카드
sizes="(min-width: 900px) 700px, (min-width: 640px) 50vw, 100vw"

레이아웃과 sizes가 어긋나면 최적화가 통째로 무력해집니다. 브레이크포인트를 바꿀 때 sizes도 같이 바꿔야 합니다.

3. width/height를 반드시 명시한다#

CLS(Cumulative Layout Shift) 문제입니다. 크기를 모르면 브라우저가 공간을 미리 잡지 못해 이미지가 로드될 때마다 화면이 밀립니다.

fill을 쓸 때는 부모에 aspect-ratio를 주면 같은 효과를 냅니다.

<div className="relative aspect-[16/10]">
  <Image src={src} alt={alt} fill sizes="..." className="object-cover" />
</div>

4. AVIF를 켜되 폴백을 남긴다#

// next.config.ts
const nextConfig: NextConfig = {
  images: { formats: ["image/avif", "image/webp"] },
};

AVIF는 같은 화질에서 WebP보다 20~30% 작습니다. 다만 인코딩이 느려서 빌드 시간이 눈에 띄게 늘어납니다. 이미지가 수백 장이면 빌드 타임 변환 대신 CDN 리사이징을 고려하세요.

5. 폰트가 LCP를 잡고 있지 않은지 확인한다#

의외로 자주 놓치는 부분입니다. 외부 CDN에서 웹폰트를 <link rel="stylesheet">로 불러오면 렌더 블로킹이 걸립니다. 이미지를 아무리 최적화해도 텍스트가 안 나오면 LCP는 그대로입니다.

• next/font를 쓰면 빌드 시 self-host + preload가 자동입니다
• 외부 CDN을 써야 한다면 최소한 preconnect를 걸어두세요
• 한글 폰트는 subset이 필수입니다. 전체 글리프는 수 MB입니다

효과가 거의 없었던 것들#

시간을 들였지만 측정해보니 의미가 없었던 것들도 적어둡니다.

• 이미지 CDN 교체 — 이미 AVIF로 잘 압축되고 있었다면 차이가 미미했습니다
• loading="eager" 남발 — priority 없이 eager만 주면 우선순위가 안 올라갑니다
• placeholder blur — 체감은 좋아지지만 LCP 수치 자체는 오히려 나빠질 수 있습니다 (base64가 HTML을 키움)

측정 없이 최적화하지 않기#

가장 중요한 이야기를 마지막에 합니다. 위 항목들도 여러분의 사이트에서는 순서가 다를 수 있습니다.

npx lighthouse https://example.com --only-categories=performance --view

Lighthouse는 LCP 요소가 무엇인지 직접 알려줍니다. 거기서 시작하세요. 짐작으로 최적화하면 효과 없는 항목에 며칠을 씁니다.