1. 핵심요약
Next.js 성능 개선은 LCP와 초기 로딩 속도를 먼저 잡고, 이후 INP와 배포 후 모니터링까지 이어가는 방식이 가장 효과적입니다.
2. Core Web Vitals에서 먼저 확인해야 할 기준
Core Web Vitals는 단순한 속도 점수가 아니라, 사용자가 실제로 느끼는 경험을 기준으로 페이지 품질을 판단하는 지표입니다. Next.js에서는 LCP와 초기 로딩 속도를 함께 보고, 최신 기준에서는 INP까지 확인해야 합니다.
이 글에서는 페이지가 “빨리 보이는가”와 “빠르게 반응하는가”를 분리해서 봅니다. 전자는 주로 서버 응답, 이미지, 렌더링 전략과 연결되고, 후자는 JavaScript 실행과 메인 스레드 점유와 연결됩니다.
핵심은 단일 지표만 개선하는 것이 아니라, 첫 화면의 완성도와 상호작용 성능을 함께 올리는 것입니다. 그래서 이미지 최적화, 폰트 처리, 렌더링 전략을 한 묶음으로 다루는 편이 실무적입니다.
3. 성능 진단과 측정 방법
감으로 수정하면 원인을 잘못 짚기 쉽습니다. 먼저 필드 데이터와 랩 데이터를 함께 확인해야 실제 병목을 정확히 찾을 수 있습니다.
실무에서는 PageSpeed Insights, Search Console, Lighthouse, Chrome DevTools를 함께 사용하면 좋습니다. Next.js의 reportWebVitals로도 핵심 지표를 수집할 수 있습니다.
- 필드 데이터: 실제 사용자 환경에서 수집된 값
- 랩 데이터: 개발 또는 테스트 환경에서 재현한 값
- 비교 목적: 수정 전후 변화와 회귀 여부 확인
진단은 단순합니다. 먼저 도구로 문제를 확인하고, 그다음 원인을 추적한 뒤, 배포 환경에서 다시 검증합니다. 이 순서를 지키면 개선 작업이 체감 속도와 연결되는지 빠르게 판단할 수 있습니다.
4. LCP를 가장 먼저 줄여야 하는 이유
LCP는 사용자가 페이지가 열렸다고 느끼는 순간과 가장 가깝습니다. 그래서 Next.js LCP 최적화는 SEO와 UX 양쪽에서 가장 먼저 다뤄야 할 항목입니다.
첫 화면의 큰 요소가 늦게 뜨면 전체 페이지가 느리게 느껴집니다. 히어로 이미지, 큰 배너, 핵심 카드처럼 화면에서 가장 큰 콘텐츠를 먼저 보여주는 구조가 중요합니다.
| 방법 | 기대 효과 |
|---|---|
| SSR | 서버에서 바로 화면을 만들어 LCP를 줄임 |
| SSG | 미리 생성된 페이지를 제공해 초기 표시를 빠르게 함 |
| 초기 렌더링 최적화 | 첫 화면 요소를 먼저 보여줌 |
가능하면 서버에서 완성된 HTML을 먼저 보내고, 클라이언트 작업은 이후로 미루는 구조가 좋습니다. 이 접근은 초기 로딩 속도와 렌더링 전략을 동시에 개선합니다.
5. 이미지와 JavaScript 최적화 실전 방법
첫 화면의 가장 큰 요소가 이미지라면, 그 이미지를 먼저 빠르게 내려받게 만들어야 합니다. Next.js에서는 next/image를 활용하면 이미지 최적화를 쉽게 적용할 수 있습니다.
priority는 첫 화면에서 꼭 필요한 이미지를 먼저 불러오게 해주고, sizes는 기기 화면에 맞는 크기만 내려받게 해줍니다. width와 height를 지정하면 레이아웃 흔들림도 줄어듭니다.
- next/image 사용
- 첫 화면 히어로 이미지에 priority 적용
- sizes를 알맞게 설정
- width와 height 지정으로 레이아웃 안정화
- 용량을 줄이고 적절한 압축 사용
JavaScript는 초기 로딩 속도를 늦추는 가장 흔한 원인입니다. next/dynamic과 동적 import를 활용하면 필요한 순간에만 코드를 불러올 수 있습니다.
첫 화면에 필요 없는 컴포넌트는 늦게 로드하고, 무거운 라이브러리는 분리하는 편이 좋습니다. 이 과정은 JavaScript 번들 최적화와 직결됩니다.
6. 폰트, 스크립트, 렌더링 전략 정리
폰트와 써드파티 스크립트는 작아 보여도 체감 속도에 큰 영향을 줍니다. Next.js의 next/font와 next/script를 쓰면 로딩 타이밍을 더 정교하게 제어할 수 있습니다.
next/font는 웹폰트를 더 안정적으로 다루게 해주며, CLS를 줄이는 데도 도움이 됩니다. next/script는 분석, 채팅, 광고 같은 외부 스크립트를 적절한 시점에 넣을 수 있게 해줍니다.
| 항목 | 개선 방법 | 기대 효과 |
|---|---|---|
| 폰트 | next/font 사용 | 비동기 로드, CLS 완화 |
| 폰트 | fallback과 preload 고려 | 글자 흔들림 감소 |
| 스크립트 | next/script 사용 | 비필수 JS 지연 |
| 스크립트 | 분석, 채팅, 광고 분리 | 초기 로딩 보호 |
렌더링 전략은 개별 컴포넌트보다 더 큰 영향을 줍니다. 가능한 경우 SSR과 SSG를 활용해 서버에서 먼저 완성된 HTML을 보내고, 클라이언트 전용 UI는 동적 import로 늦추는 구조가 좋습니다.
서버 응답이 길어지면 TTFB가 늘어나고, 그만큼 LCP와 초기 표시도 늦어집니다. 그래서 서버 로직과 캐시 전략까지 함께 점검해야 합니다.
7. 적용 순서와 배포 후 유지보수
최적화는 순서가 중요합니다. 먼저 병목이 LCP인지, JavaScript 과다인지, 폰트 문제인지 확인한 뒤, 가장 큰 원인부터 고치는 방식이 효율적입니다.
실무 적용 순서는 다음처럼 잡으면 됩니다. 첫 화면 이미지가 문제면 이미지 최적화부터, 컴포넌트가 무겁다면 동적 import부터 처리합니다.
- 첫 화면은 가볍게 유지
- 서버 작업은 최소화
- 캐시 전략을 함께 검토
- Middleware나 서버 로직이 무거워지지 않게 관리
- 수정 후 다시 측정해 실제 사용자 데이터 확인
배포 후에도 성능은 계속 변합니다. 새 이미지, 새 스크립트, 새 폰트가 추가되면 다시 느려질 수 있으므로 reportWebVitals와 Search Console, PageSpeed Insights로 지속적으로 확인하는 편이 좋습니다.
8. 자주 묻는 질문 (FAQ)
Q1. Next.js에서 가장 먼저 개선해야 할 지표는 무엇인가요?
가장 먼저 볼 지표는 LCP입니다. 첫 화면이 빨리 보이지 않으면 사용자는 전체 페이지를 느리게 인식하므로, 초기 체감 속도와 SEO에 모두 영향을 줍니다.
Q2. 이미지 최적화는 왜 그렇게 중요하나요?
첫 화면의 큰 요소가 이미지인 경우가 많기 때문입니다. 이럴 때 next/image와 priority를 적용하면 LCP 개선 효과가 큽니다.
Q3. JavaScript를 줄이려면 무엇부터 해야 하나요?
첫 화면에서 필요 없는 컴포넌트와 무거운 라이브러리를 먼저 분리해야 합니다. next/dynamic과 동적 import를 적용하면 초기 번들 크기를 줄이는 데 도움이 됩니다.
Q4. 폰트와 써드파티 스크립트는 어떻게 다루는 게 좋나요?
next/font로 폰트를 안정적으로 관리하고, next/script로 분석·채팅·광고 스크립트를 지연시키는 방식이 좋습니다. 이렇게 하면 초기 표시와 CLS를 함께 관리할 수 있습니다.
Q5. 개선 후에는 무엇을 확인해야 하나요?
reportWebVitals로 실제 사용자 지표를 추적하고, 배포 전후의 필드 데이터와 랩 데이터를 비교해야 합니다. 성능은 한 번 고치고 끝나는 것이 아니라, 기능 추가마다 다시 점검해야 합니다.