Dynamic을 사용하기 전 Next.js 서버 사이드 렌더링(SSR)의 기본 동작 원리를 이해해야한다.
SSR 동작 순서
- 클라이언트 요청
- Server Side 단에서 웹 페이지를 Pre-Rendering 으로 HTML 문서 생성
- 생성된 HTML 문서를 클라이언트에 전송
- 리액트에서 번들링된 JS파일을 클라이언트에 전송
- 클라이언트 단에서는 HTML 문서위에 전송받은 JS 파일을 매칭
이 과정을 Hydrate라고 부른다. 서버에서 1번 클라이언트에서 1번 총 2번의 렌더링을 진행해 비효율적이지 않을까 싶은데, 서버 단에서 Pre-Redering 해주므로써, 가벼운 JS파일로 클라이언트는 빠르게 웹페이지 로딩이 가능하다.
부분적 CSR 구현을 하는 이유
SSR이 아닌 부분적 CSR 방식을 사용해야하는 이유는 여러가지 있을 수 있는데, 내가 직접 경험한 예로는 위지윅(Wysiwyg) 텍스트 에디터를 사용할 때 였다. 위지윅 에디터는 클라이언트 단에서만 사용되는 라이브러리이기 때문에 SSR방식으로 렌더링 할 경우 에러를 동반했다.
Error : 'window is not defined, document is not defined'
그리고 SSR은 클라이언트의 작업을 일정부분 서버에서 진행하기 때문에 서버에 부담이 될 수 있다. 이 경우 퍼포먼스 향상 및 최적화를 위해 Dynamic Import를 사용한다.
Dynamic Import를 사용한 CSR 구현
import dynamic from 'next/dynamic'
const NoSsr = dynamic(() => import('../components'), { ssr : false })
const Dynamic = () => {
return <NoSsr />
}
NoSsr에 불러온 컴포넌트는 서버단에서 Pre-Rendering 하지 않고 클라이언트에서 렌더링 시키겠다는 의미.