next.js - production 배포 전 체크리스트

next.js로 만든 앱을 배포하기 전 체크리스트

• 가능한만큼 캐싱을 적용했는가?
• 데이터베이스와 백엔드가 같은 region에 배포되어있는가?
• 가능한 최소한의 Javascript를 사용하는 것을 목표로 해라
• Javascript 로딩을 가능한 연기하라
• logging이 구현되어 있는가?
• errorHandling이 설정되어있는가?
• 404 페이지와 500 페이지를 만들었는가?
• 성능 측정을 해보아라
• Lighthouse를 실행해서 테스트해보아라.
• 브라우저 호환성을 확인하라
• 성능을 높이기 위해 다음 기능을 사용하라
  • Automatic Image Optimization : next/image에 관한 내용
  • Automatic Font Optimization : next/font에 관한 내용
  • Script Optimization : next/script에 관한 내용
• loading 성능을 개선하라

캐싱

next.js는 /_next/static 에서 서빙되는 불변 assets을 클라이언트로 보낼 때 자동으로 caching 헤더를 붙인다.

1

Cache-Control: public, max-age=31536000, immutable

다른 값을 사용하고 싶다면 next.config.js에서 설정할 수 있다. 만약 캐시를 revalidate 시키고 싶다면 getStaticProps에서 revalidate를 설정하면 된다.

next dev로 실행할 경우엔 자동으로 다음과 같은 값으로 설정되어 캐싱되지 않는다.

1

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

next/image은 별로의 캐싱 규칙이 존재한다.

getServerSideProps나 API Route에서도 caching 헤더를 사용할 수 있다.

1
2
3
4
5
6
7
8
9
10

export async function getServerSideProps({ req, res }) {
  res.setHeader(
    'Cache-Control',
    'public, s-maxage=10, stale-while-revalidate=59'
  )

  return {
    props: {},
  }
}

기본적으로는 Cache-Control은 경우에 따라 다르게 설정된다,

• getServerSideProps, getInitialProps 를 사용하는 페이지 : next start로 설정된 디폴트 Cache-Control 사용하여 캐싱되는 것을 막는다.
• getStaticProps
  • revalidate가 설정되있지 않으면, s-maxage=REVALIDATE_SECONDS, stale-while-revalidate
  • revalidate가 설정되어있으면, s-maxage=31536000, stale-while-revalidate

Javascript 사이즈 줄이기

다음과 같은 툴을 사용하면 Javascript 번들 사이즈를 줄이는데 도움이 된다.

• Import Cost
• Package Phobia
• Bundle Phobia
• Webpack Bundle Analyzer
• bundlejs

/pages 디렉터리에 있는 파일들은 next build시 자동으로 코드가 분리되어 번들된다. Dynamic Imports`를 사용해 lazy-load를 적용할 수도 있다.

Loading Performance

Core Web Vitals를 사용하여 loading performance를 개선할 수 있다. 개선해야할 점이 보이면 다음과 같은 전략을 취할 수 있다.

• 데이터페이스와 API가 배포되는 곳에서 가까운 지역을 caching region으로 삼아라
• stale-while-revalidate를 적절히 사용하라
• Incremental Static Regeneration를 사용해서 백엔드로 보내는 요청량을 줄여라
• 필요없는 Javascript를 지워서 JS 번들 사이즈를 줄여라