SSR에 대해서는 너무나도 많은 글이 있지만 내 자신이 이해하기 위해서 정리를 한번 해보려고 한다.
내 생각은 유저의 입장에서 결국 적은 로딩 시간 -> 더 나은 UX로 귀결되기 때문에 이 점에 있어서 NextJS의 SSG가 CSR에 비해 더 나은 UX를 제공할 수 있다고 할 수 있겠다.
그러니까.. 유저가 새로고침 버튼을 눌러 완전히 새로 로딩되는 것을 플레인 리액트와 NextJS로 나누어 생각해본다면
CSR
- 유저가 새로고침 버튼을 누른다
- 브라우저는 서버와 통신해서 index.html, CSS, JS 번들을 요청한다.
- 먼저 index.html(리액트가 로딩되는 그 빈 html)을 받고 이를 렌더링한다.
- JS 번들이 로딩된다. 이 단계에서 리액트의 로직이 시작된다.
- 리액트의 컴포넌트들이 마운트되며(데이터가 없기 때문에, 로딩이 뜨거나 뜨지 않거나 Fallback state일 것이다.), 여기서 CSR이 시작된다.(데이터를 받고 이에 맞춰 컴포넌트를 그려줌)
- 모든 데이터가 채워지고 리액트 앱이 유저의 인풋을 받아들일 수 있는 상태가 된다.
NextJS
SSG
- nextJS에서는 빌드 과정에서 라우터에 할당된 페이지의 static한 HTML을 만들어 낸다.
- 유저가 해당 URL에 입장할 때 서버에서는 1.에서 생성된 HTMl을 내려주게 된다.
- 이 html과 css, js 번들을 브라우저가 받아서 렌더링 한다.
-- 여기까지가 SSG -- - JS 번들이 로딩되면서 NextJS의 로직이 실행된다.
-- 여기서부터 CSR - 리액트의 컴포넌트들이 마운트되며 CSR 로직이 실행된다.(빌드 시 이미 getStaticProps가 실행된 상태이므로, 따로 페칭하지 않는다.)
- 모든 데이터가 채워지고 리액트 앱이 유저의 인풋을 받아들일 수 있는 상태가 된다.
이 두 가지 과정에서 가장 큰 차이점은,
새로고침이 되었을 때 CSR에서는 html 렌더링 이후 페칭을 통해 데이터를 받아오는 과정을 거치고, 여기서 필연적으로 어떤 형태의 로딩이 발생할 수 밖에 없다는 것이다.
SSG에서는 5번의 과정이 이미 수행된 html을 받기 때문에 여기에서 확실한 이득을 볼 수 있다고 생각한다.
또한
https://blog.logrocket.com/ssg-vs-ssr-in-next-js/
의 정보에 따르면, SSG는 html을 만들어주기 때문에 CDN을 거쳐서 해당 파일을 캐싱해 더욱 빠른 다운로드 시간을 보장한다고 한다.
setback
한가지 생각하지 못했던 것은 이 SSG 방식은 각각의 페이지에 파일을 따로 생성하므로, 빌드 시간이 더욱 길어지는 문제점이 있다고 한다.
이 부분은 위 getStaticProps가 복잡해지고 페이지가 많아질 수록 더욱 늘어날 것이고, 수정이 많은 페이지일 경우 일반적인 빌드(수동으로 빌드 & 디플로이 파는 경우)가 굉장히 복잡해질 수도 있다.
이 부분은 사실 nextJS로 프로덕션 레벨을 만들어본 적이 없어서(사이드로 페이지 5개 이하정도만 만들어봐서...) 생각하지 못했던 문제인데, 페이지가 늘어나면 확실히 문제가 될 수 있다고 생각이 된다.
