nextjs.org/docs 공식문서의 내용을 번역, 정리한 내용입니다.
사진 출처는 nextjs.org 공식문서입니다.
Next.js에서 route는 정적 또는 동적으로 렌더링 된다.
기본적으로 Next.js는 성능 향상을 위해서 route를 정적으로 렌더링한다. 즉, 모든 렌더링 작업이 미리 처리되어 유저에게 지리적으로 가까운 CDN으로부터 페이지를 바로 받아볼 수 있다는 것이다.
기본적으로 Next.js는 캐싱 방법을 따로 정의하지 않은 fetch()
요청들에 대해서는 결과를 캐싱하게 된다. cache
옵션을 따로 설정하지 않은 fetch 요청에 대해서는 force-cache
옵션을 사용한다는 뜻이다.
만약 route 상의 어떤 fetch 요청이라도 revalidate
옵션을 사용한다면, route는 갱신 시 정적으로 re-rendering 된다.
정적 렌더링을 할 때 동적인 함수 또는 동적인 fetch()
요청(캐싱이 되지 않는)이 발견된다면, Next.js는 전체 route를 request time에 동적으로 렌더링하도록 변경한다. 캐싱된 데이터 요청은 동적 렌더링 시에도 여전히 재사용 가능하다.
아래 표는 동적인 함수의 존재 혹은 캐싱 여부가 route의 렌더링 방식에 어떤 영향을 미치는지 보여준다.
Data Fetching | Dynamic Functions | Rendering |
---|---|---|
정적 (캐싱 O) | X | 정적 렌더링 |
정적 (캐싱 O) | O | 동적 렌더링 |
캐싱 X | X | 동적 렌더링 |
캐싱 X | O | 동적 렌더링 |
위 표에서 알 수 있듯이 동적인 함수의 존재는 데이터 fetching이 캐싱 되는지 여부에 상관 없이 route를 동적으로 렌더링하도록 만든다. 다시 말해, 정적 렌더링은 어떻게 데이터 fetching을 하는지 뿐만 아니라, route 내에서 사용되는 동적인 함수 여부에 영향을 받는다.
동적인 함수는 유저의 쿠키, 현재 요청의 헤더, URL의 search params와 같이 request time에만 알 수 있는 정보에 의존한다. Next.js에서 동적인 함수의 예는 다음과 같다.
cookies()
또는 headers()
함수를 사용하는 것은 전체 route를 request time에서 동적으로 렌더링 되도록 한다.useSearchParams
를 사용하는 것은 정적인 렌더링을 건너뛰고 대신 가장 가까운 부모 Suspense Boundary 내의 모든 클라이언트 컴포넌트를 클라이언트에서 렌더링 한다.useSearchParams()
를 사용하는 클라이언트 컴포넌트를 <Suspense />
boundary로 감쌀 것을 권장한다. 이를 통해 해당 컴포넌트 상위의 클라이언트 컴포넌트들은 정적으로 렌더링 할 수 있다.searchParams
에서 반환하는 값을 prop으로 사용하는 페이지는 request time에 동적으로 렌더링 된다.동적인 데이터 fetch는 cache
옵션을 'no-store'
로 설정하거나 revalidate
옵션을 0
으로 설정한 fetch()
요청을 말한다.
레이아웃이나 페이지에서의 모든 fetch 요청에 대한 캐싱 옵션은 segment config 객체를 활용하여 설정할 수도 있다.
(segment config
의 옵션은 여기서 확인해 볼 수 있다.)
Next.js의 관점에서 런타임은 실행 시 코드에서 사용 가능한 라이브러리, API, 그리고 전반적인 기능들의 집합을 말한다.
Next.js는 애플리케이션 코드의 일부들을 렌더링 할 수 있는 2개의 서버 런타임을 가지고 있다.
기본적으로 app
디렉토리는 Node.js 런타임을 사용한다. 하지만 각 route 별로 다른 런타임을 사용할 수도 있다.