Next의 Pre-rendering, SSG와 SSR에 대한 설명

Pre rendering?

 

nextjs.org/docs/basic-features/pages#pre-rendering

 

By default, Next.js pre-renders every page. This means that Next.js generates HTML for each page in advance, instead of having it all done by client-side JavaScript.(순수 React는 CSR을 하기 때문에 별도의 SSR 세팅을 해줘야 하는데 Next는 이를 자동으로 해준다) Pre-rendering can result in better performance and SEO.

 

Each generated HTML is associated with minimal JavaScript code necessary for that page. When a page is loaded by the browser, its JavaScript code runs and makes the page fully interactive. (This process is called hydration.)

즉, hydration한 상태였다가 실제로 접속하게 되면 자바스크립트가 돌아 인터렉티브하게 작동하도록 만드는 거네요. 이 hydration이라는 속성으로 인해 종종 hydration 전/후의 내용이 다르다고 경고가 뜨기도 합니다.

 

그림으로 쉽게 보면 다음과 같습니다.

 

 

Next가 제공하는 pre rendering은 2가지가 있습니다. SSG와 SSR. 전자는 getStatisProps, getStaticPaths를 사용하고 후자는 getServerSideProps를 사용하면 됩니다.

 

Next.js has two forms of pre-rendering: Static Generation and Server-side Rendering. The difference is in when it generates the HTML for a page.

• Static Generation (Recommended): The HTML is generated at build time and will be reused on each request.
• Server-side Rendering: The HTML is generated on each request.

 

 

SSG vs SSR

 

getInitialProps를 대체하는 getStaticProps, getStaticPaths, getServerSideProps

 

• getStaticProps : 빌드 타임 때 data fetch => 딱 한 번만 실행됨 따라서 빌드시 고정되는 값이고, 빌드된 이후에는 변경이 불가능함.
• getStaticPaths : data에 기반하여 pre-render할 동적 라우팅을 적어주어라. (getStaticProps와 함께 쓰입니다.)
• getServerSideProps: 각각의 요청마다 data를 fetch한다. => 같은 페이지에서 페칭하고 다른 내용은 렌더함. Static이 아니기 때문에 매 요청마다 데이터를 서버로 부터 가져옴

주의할 점은 개발 모드에서는 SSG를 사용해도 매 요청시마다 가동된다는 것입니다. 왜 SSG가 안되는지 헤매지 맙시다. SSG는 프로덕션 모드에서만 build 타임때 실행됩니다.

In development : (npm run dev or yarn dev), getStaticProps runs on every request.
In production : getStaticProps runs at build time.

 

In development mode (when you run npm run dev or yarn dev), every page is pre-rendered on each request — even for pages that use Static Generation.

 

 

Next에서는 가급적 SSG를 사용할 수 있는 부분은 전부 SSG를 사용하고 필요한 부분에만 SSR을 사용할 것을 권하고 있습니다. 왜냐하면 your page can be built once and served by CDN, which makes it much faster than having a server render the page on every request. 과 같은 이점이 있기 때문입니다.

 

언제 SSG를 사용해야 하는 지에 대해서는 Can I pre-render this page ahead of a user's request?" If the answer is yes, then you should choose Static Generation. 라고 합니다. 음..유저가 요청하기 전에 만들어낼 수 있는 정적인 페이지라면 이라면 SSG를 사용하라는 말이군요.

 

반대로 On the other hand, Static Generation is not a good idea if you cannot pre-render a page ahead of a user's request. Maybe your page shows frequently updated data, and the page content changes on every request. 매 요청마다 내용이 달라지는 경우는 SSR을 사용하라는 군요.

 

공식 문서는 SSG를 사용하면 좋은 케이스를 다음과 같이 들고 있습니다. 

 

• Marketing pages
• Blog posts
• E-commerce product listings
• Help and documentation

 

또, SSG를 사용하되 클라이언트 사이드에서 서버 요청을 하는 방식으로 진행해도 됩니다. 물론 클라이언트에서 데이터를 페칭해오는 만큼 그 특유의 "깜박"이 존재할 수 있습니다.