Next.js 사이트 PageSpeed 최적화 — Mobile 38에서 88까지

1상황 — Mobile 38점

사이트의 기능과 디자인은 완성된 상태였습니다. SEO 100점, Accessibility 92점, Best Practices 100점. 문제는 Performance 하나였습니다. 측정 결과를 보면 원인이 뚜렷했습니다.

LCP 110초. 오타가 아닙니다. Hero 이미지 하나가 5.6MB였고, 비슷한 크기의 이미지가 6장 더 있었습니다. 총 36MB의 이미지를 슬로우 4G 환경에서 로드하니 110초가 걸린 겁니다.

CLS 0.5도 심각했습니다. 타이핑 애니메이션이 글자를 하나씩 추가하면서 레이아웃을 계속 밀어냈고, 웹폰트가 뒤늦게 로드되면서 텍스트 크기가 바뀌었습니다.

24단계 개선 요약

한 번에 모든 걸 바꾼 게 아니라, 한 가지씩 수정하고 측정하기를 반복했습니다. 덕분에 각 단계에서 얼마나 효과가 있었는지 정확히 파악할 수 있었습니다.

3Phase 1: 이미지 압축

모든 걸 제쳐두고 이미지부터 손봤습니다. Hero 이미지 1장이 5.6MB, 서비스 섹션 이미지 3장이 각각 5~7MB, 배경 텍스처와 사진까지 합치면 총 6장, 36MB였습니다.

Node.js의 sharp 라이브러리로 WebP quality 80, 최대 너비 1920px로 리사이즈했습니다. 총 36MB가 0.8MB로 줄었습니다. 이것만으로 LCP가 110초에서 6.8초로 내려왔습니다.

4Phase 2: CLS 제거

이 단계에서 가장 큰 점수 상승이 있었습니다. CLS(Cumulative Layout Shift)는 페이지 로딩 중 요소가 밀리는 정도를 측정하는 지표인데, 원인은 의외의 곳에 있었습니다.

범인: 타이핑 애니메이션

메인 페이지에 글자가 한 자씩 나타나는 타이핑 효과가 있었습니다. 시각적으로는 멋졌지만, 글자가 추가될 때마다 텍스트의 높이와 너비가 바뀌면서 아래 콘텐츠를 밀어냈습니다. 이 컴포넌트가 4개 섹션에서 사용되고 있었고, 전체 CLS의 60~70%를 차지하고 있었습니다.

해결: Invisible Placeholder 패턴

핵심 아이디어는 간단합니다. 전체 텍스트를 처음부터 렌더링하되, 아직 타이핑되지 않은 부분은 visibility: hidden으로 숨기는 것입니다.

// 타이핑된 부분 — 보임
<span>{text.slice(0, typedCount)}</span>

// 아직 안 타이핑된 부분 — 공간만 차지
<span style={{ visibility: "hidden" }}>
  {text.slice(typedCount)}
</span>

이렇게 하면 전체 텍스트의 공간이 처음부터 확보되어 레이아웃이 고정됩니다. 사용자 눈에는 똑같이 한 글자씩 나타나지만, 브라우저 입장에서는 레이아웃 변화가 없습니다.

추가 수정: Header Suspense

Header 컴포넌트를 Suspense로 감싸면서 fallback으로 80px 높이의 빈 div를 넣어둔 게 있었습니다. 그런데 Header가 position: fixed라서 document flow에 참여하지 않습니다. 즉, fallback의 80px 공간이 Header 로드 후 사라지면서 CLS가 발생했습니다. fallback을 null로 바꿔서 해결했습니다.

5Phase 3: 폰트 최적화

점수 변화만 보면 작아 보이지만, 이 단계에서 CLS가 완전히 0이 되었습니다. 남은 CLS 0.095는 웹폰트 로드 시 텍스트 크기가 바뀌면서 발생한 것이었습니다.

문제: 한국어 폰트의 @font-face 폭발

next/font/google로 Noto Serif KR을 로드하면, 한글 유니코드 범위별로 120개 이상의 @font-face 규칙이 생성됩니다. 이것만으로 렌더 차단 CSS가 약 26KB 추가됩니다. 영문 폰트에서는 상상하기 어려운 규모입니다.

해결: 커스텀 서브셋 + local font

실제 사이트에서 사용하는 한글 문자만 추출하고, Google Fonts의 text API를 통해 해당 글자만 포함된 woff2 파일을 생성했습니다. 그 다음 next/font/local로 로드하니 @font-face 규칙이 1개로 줄었고, 렌더 차단 CSS가 26KB에서 3KB로 감소했습니다.

font-display: optional

font-display: swap은 폴백 폰트를 먼저 보여주고 웹폰트가 로드되면 교체합니다. 이 교체 시점에 텍스트 크기가 바뀌면 CLS가 발생하고, LCP도 재측정됩니다. optional로 바꾸면 100ms 내에 로드되지 않으면 폴백을 유지합니다. 일반 네트워크에서는 100ms 안에 로드되니 실제로는 웹폰트가 표시되지만, 느린 환경에서의 폰트 스왑과 CLS를 방지합니다.

6Phase 4: LCP 개선

마지막 단계는 LCP(Largest Contentful Paint)를 3.4초까지 줄이는 것이었습니다. 여기서 가장 큰 함정을 발견했습니다.

함정: motion/react의 opacity:0

Hero 섹션에 Framer Motion으로 페이드인 애니메이션을 넣어둔 상태였습니다. initial={{ opacity: 0 }}으로 시작해서 animate={{ opacity: 1 }}로 나타나는 패턴입니다.

문제는 SSR(Server Side Rendering)에서 이것이 style="opacity:0"으로 렌더링된다는 것입니다. 브라우저는 opacity:0인 요소를 LCP 후보에서 제외합니다. JavaScript가 실행되어 opacity가 1이 된 후에야 LCP가 측정되기 때문에, LCP = JavaScript 로드 + 실행 시간이 되어버립니다. 이 현상의 상세 분석은 LCP opacity:0 트랩 분석을 참고하세요.

<motion.div
  initial={{ opacity: 0, scale: 0.95 }}
  animate={{ opacity: 1, scale: 1 }}
>
  <img src="/hero.avif"
       fetchPriority="high" />
</motion.div>

<motion.div
  initial={{ scale: 0.97 }}
  animate={{ scale: 1 }}
>
  <img src="/hero.avif"
       fetchPriority="high" />
</motion.div>

추가 개선: AVIF 변환 + Preload 정리

Hero 이미지를 WebP에서 AVIF로 변환하여 추가 압축했습니다. 그리고 아래 fold 이미지들에 loading="lazy"를 누락한 곳이 있었는데, Next.js는 lazy가 없는 img 태그에 자동으로 preload를 생성합니다. 이 불필요한 preload들이 Hero 이미지와 대역폭을 경쟁하고 있었습니다.

7핵심 교훈

하면 안 되는 것