이번 글에서는 Nextjs에서 사용하는 렌더링 방식에 대해서 작성할 것이다.
CSR(Client Side Rendering)
CSR은 reactjs에서 개발할때, 사용하는 방식처럼 렌더링 주체가 클라이언트인 경우이다.
초기에 HTML 빈 페이지가 먼저 표기된 후 데이터가 받아져 데이터가 채워지는 형태이다.
장점
- 초기 로딩 이후에는 빠른 UX를 제공하고 서버에 부하가 적다.
단점
- 처음으로 페이지에 접속할 때 로딩 시간이 오래 걸린다.
- javascript가 필수적으로 필요하다.
- 보안에 취약함
- SEO에 불리
사용법
- axios나 fetch등을 사용한다.
- nextjs에서 CSR을 사용시에는 SWR을 추천한다.
SSG(Static Site Generation)
SSG는 렌더링을 하는 주체가 서버이다.
어플리케이션을 배포해서 처음 빌드할 때 렌더링이 된다.
장점
- 로딩 시간이 빠름
- javascript가 필요없다.
- 보안이 좋다.
- SEO에 유리
단점
- 데이터가 처음 빌드될 때 데이터이기에 정적이다.
- 실시간으로 데이터가 추가될 경우 데이터 변경이 어렵다.
(실제 개발환경에서는 데이터가 변경되지만, 서버에 올리거나 vercel등으로 배포를 할경우 빌드 시 데이터만 표기된다.)
사용법
- SSG를 사용할때는 getStaticProps, getStaticPaths 를 사용하여 데이터를 전달한다.
이러한 데이터 변경의 문제점을 해결하기 위해 SSR과 ISR을 사용한다.
SSR(Server Side Rendering)
SSR은 SSG와 마찬가지로 렌더링을 하는 주체가 서버이다.
하지만 SSG와 다르게 빌드시 렌더링 하는 것이 아닌, 요청 시 렌더링을 한다.
서버에서 클라이언트로 데이터를 전달하므로, 초기 데이터 로드가 포함된 HTML을 제공한다.
장점
- 초기 로딩 시간이 빠름
- javascript가 필요없다.
- 보안이 좋다.
- 실시간 데이터를 사용하기 때문에 최신의 데이터를 확인할 수 있다.
- SEO 최적화
단점
- 요청 시에 서버에서 렌더링을 해서 클라이언트에 보여주기에 비교적 느릴 수 있다.
- 서버에 부하가 걸릴 수 있다.
사용법
- SSR를 사용할때는, getServerSideProps 를 사용하여 데이터를 전달한다.
ISR(Incremental Static Regeneration)
ISR은 SSG에 포함되는 방식이지만, SSG와 다른 점은 설정한 시간마다 페이지를 새로 렌더링 할 수 있다는 점이다.
기존의 SSG는 빌드 시에 페이지를 렌더링하기에 데이터가 변경되면 다시 렌더링을 해야되지만, ISR은 일정 시간마다 특정 페이지만 다시 빌드하여 페이지를 업데이트 할 수 있다.
장점
- 로딩 시간이 빠름
- javascript가 필요없다.
- 보안이 좋다.
- 데이터가 주기적으로 업데이트 된다.
- SEO 개선
단점
- 초기 로딩 시간이 다소 걸린다.
- 주기적으로 업데이트가 되지만 실시간 데이터는 아니다.
사용법
- SSG 사용하는 방식에 getStaticProps에 revalidate 옵션이 추가된다.
- getStaticPaths 를 통해서 정적생성할 경로를 받을 때 fallback: 'blocking' 옵션이 추가된다.