Automatic Static Optimization

Next.js는 페이지가 렌더링될 때 반드시 필요한 데이터가 없다면 해당 페이지가 정적(미리 렌더링 가능한 상태)임을 자동으로 결정합니다. 이 결정은 페이지에 getServerSideProps와 getInitialProps가 없는 경우에 이루어집니다.

이 기능을 통해 Next.js는 서버 렌더링 페이지와 정적 생성 페이지를 모두 포함하는 하이브리드 애플리케이션을 생성할 수 있습니다.

정적으로 생성된 페이지도 여전히 반응형입니다: Next.js는 클라이언트 측에서 애플리케이션을 hydrate하여 완전한 상호작용성을 제공합니다.

이 기능의 주요 이점 중 하나는 최적화된 페이지가 서버 측 계산을 필요로 하지 않으며, 여러 CDN 위치에서 최종 사용자에게 즉시 스트리밍될 수 있다는 점입니다. 그 결과 사용자에게 초고속 로딩 경험을 제공할 수 있습니다.

How it works

만약 페이지에 getServerSideProps 또는 getInitialProps가 포함되어 있으면, Next.js는 해당 페이지를 요청이 있을 때마다 즉시 렌더링하도록 전환합니다.(Server-Side Rendering을 의미합니다.)

위의 경우가 아니라면, Next.js는 페이지를 정적 HTML로 사전 렌더링하여 자동으로 정적 최적화를 수행합니다.

사전 렌더링 중에는 이 단계에서 제공할 query 정보가 없기 때문에 라우터의 query 객체가 비어있게 됩니다. hydration 이후, Next.js는 애플리케이션 업데이트를 트리거하여 query 객체에 라우트 매개변수를 제공합니다.

hydration 이후 query가 업데이트되어 다른 렌더링을 트리거하는 경우는 다음과 같습니다:

• 페이지가 dynamic-route인 경우.
• URL에 query 값이 있는 경우.
• next.config.js에 Rewrites가 구성된 경우, query에서 파싱되어 제공되어야 할 매개변수를 가질 수 있기 때문입니다.

query가 완전히 업데이트되고 사용할 준비가 되었는지 확인하려면 next/router의 isReady 필드를 활용할 수 있습니다.

알아두면 좋은 점: getStaticProps를 사용하는 페이지에 dynamic routes로 추가된 매개변수는 항상 query 객체 내에서 사용할 수 있습니다.

next build는 정적으로 최적화된 페이지에 대해 .html 파일을 생성합니다. 예를 들어, pages/about.js 페이지의 결과는 다음과 같습니다:

.next/server/pages/about.html

그리고 페이지에 getServerSideProps를 추가하게 되면, 다음과 같이 JavaScript로 생성됩니다:

.next/server/pages/about.js

Caveats

• 만약 getInitialProps가 있는 custom App이 있는 경우, Static Generation이 없는 페이지에서는 이 최적화가 비활성화됩니다.
• 만약 getInitialProps가 있는 custom Document를 사용하고 있다면, 페이지가 서버 사이드 렌더링인지 확인하기 위해 ctx.req가 정의되어 있는지 확인 해야 합니다. 사전 렌더링된 페이지의 경우 ctx.req는 undefined로 나타납니다.
• 라우터의 isReady 필드가 true가 될 때까지 렌더링 트리에서 next/router의 asPath 값 사용을 피해야 합니다. 정적으로 최적화된 페이지는 서버가 아닌 클라이언트에서만 asPath를 알기 때문에, 이를 prop으로 사용하면 불일치 오류가 발생할 수 있습니다. active-class-name example (opens in a new tab) 예제는 asPath를 prop으로 사용하는 한 가지 방법을 보여줍니다.