nextJS 왜 쓰는가

 

 

NextJS에 대한 설명을 구글에서 가져오면 아래와 같다.

 

nextJs는 서버 사이트 렌더링, 정적 웹 페이지 생성 등 리액트 기반 웹 애플리케이션 기능들을 가능케 하는 Node.js 위에서 빌드된 오픈 소스 웹 개발 프레임워크이다.

 

일단 nextJs는 SSR이다. 즉 Server Side Rendering이다.

이것과 많이 나오는 개념이 CSR Client Side Rendering이다.

 

 

SSR
서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식
서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 페이지를 보여주는 방식

이렇게 이루어진 사이트를 들어가게되면 새로고침을 해도 깜빡임 없이 바로 페이지를 볼 수 있다.

CSR의 경우 대부분 React를 이용하여 렌더하는데 그렇게 되면 React의 내용이 거의 없는 index.js를 먼저 렌더하고 그 이후에 React 컴포넌트들이 랜더되어 한번의 깜빡임이 일어나게 된다.

 

그러나 SSR은 서버에서 가져온 그대로를 렌더하기때문에 그런 것이 없고 바로 렌더된다.

 

몇몇 사이트의 데이터를 이용하기 위해 셀레니움 크롤링을 자주 했는데, SSR로 이루어진 사이트들의 데이터는 스크랩핑으로도 쉽게 가져올 수 있지만 리액트로 짜여진 페이지의 경우엔 wait을 하고(실제 페이지가 렌더될 때까지) 데이터를 가져왔던 경험이 있었다. 

 

 

CSR
즉, 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내준다.
클라이언트는 그것을 받아 렌더링을 시작한다.

 

 

즉, 유저는 클라이언트가 html과 JS 다운로드가 완료가 되었을때서야 비로소 페이지를 볼 수 있다.

 

 

 

각각의 차이

1. 첫 페이지 렌더 속도

CSR의 경우 HTML, CSS와 모든 스크립트들을 한 번에 불러온다. 반면 SSR은 필요한 부분의 HTML과 스크립트만 불러오게 된다. 따라서 평균적으로 SSR이 더 빠르다.

 

2. 나머지 페이지 렌더 속도

첫 페이지를 로딩한 후, 사이트의 다른 곳으로 이동하는 식의 동작을 가정하자. CSR은 이미 첫 페이지 로딩할 때 나머지 부분을 구성하는 코드를 받아왔기 때문에 빠르다.
반면, SSR은 첫 페이지를 로딩한 과정을 정확하게 다시 실행한다. 즉, 첫 페이지를 렌더했을 때와 같은 깜빡임이 발생하고 다시 서버를 통해 데이터를 받아오기때문에 상대적으로 느리다.

 

3. SEO의 대응

방금 크롤러 얘기와 연결되는 부분이다. 

SSR 방식은 View를 서버에서 전부 렌더링하기 때문에 HTML에 모든 컨텐츠가 저장되어 있어 SEO에 훨씬 효율적이다.

CSR도 SEO가 잘 안되는 것은 아니다. 구글처럼 검색엔진이 자바스크립트 기반이라면 CSR 방식으로도 SEO 최적화가 가능하겠지만, 훨씬 더 리소스가 많이 들어간다. (ex 자바스크립트 검색 최적화, meta 태그 활용 등)

 

 

 

---

그래서, 이 둘의 장점을 잘 살려 프로젝트를 개발하고자 한다면, 업데이트가 많지 않은 첫 화면이나

SEO의 니즈가 있는 페이지의 경우 SSR로 처리하고, 사용자와의 인터렉션이 많고 저장 및 업데이트해야되는 변화가 많은 페이지의 경우에는 CSR로 처리하는 것이 좋을 것 같다.