CSR(Client-side Rendering)
클라이언트가 서버에서 HTML, CSS, JS 파일을 내려 받습니다. 서버는 단지 JSON 파일만 보내주는 역할을 하며 HTML을 그리는 역할은 클라이언트의 JS에서 수행합니다.
사용자의 행동에 따라 필요한 부분만 불러옵니다.
사이트의 개발자 도구를 켜 볼 시에 빈 HTML 문서를 불러왔는데 화면에서는 웹페이지가 정상적으로 나옵니다. bundle.js 파일을 통해 만들어지는데 React에서는 빌드를 할 때 코드를 전부 하나의 js 파일로 만들어 줍니다. 클라리언트에서는 이러한 bundle.js 파일을 통해 페이지를 그릴 수 있게 되는 것입니다.
초기에 JS 파일을 읽어서 그리는 작업을 하는 동안 딜레이가 생기게 되지만 그 이후 작업에서는 서버의 의존도가 없이 클라이언트 혼자 그릴 수 있고 사용자의 행동에 따라 필요한 부분만 다시 읽어 들이기 때문에 빠른 화면 전환이나 인터랙션이 가능합니다.
단점으로는 index.html 에 단순히 뼈대만 있기 때문에 검색 엔진의 봇들이 크롤링 할때 아무 내용이 없어 SEO에 취약하다는 점 입니다. 또한 첫페이지의 로딩 시간이 SSR이 더 빠를 수 있습니다. 왜냐하면 CSR은 모든 걸 다 다운 받기 때문입니다.
SSR(Server-Side-Rendering)
SSR은 요청시 마다 새로고침이 일어나며 서버에 새로운 페이지에 대한 요청을 하는 방식입니다. 말 그대로 서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식입니다.
User가 웹사이트 오청을 보내면 서버는 Read to Render , 즉시 렌더링 가능한 html 파일을 만듭니다. 클라이언트에 전달된 순간 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링이 됩니다. 그리고 그 후에 클라이언트가 자바스크립트를 다운 받습니다.
이미 DOM이 다 구성된 파일을 브라우저가 받기 때문에 바로 그릴 수가 있어 초기 구동속도가 매우 빠릅니다. 즉 첫페이지의 로딩시간이 빠릅니다.
단 첫페이지를 로딩한 후 사이트의 다른 곳으로 이동을 하게 되면 CSR은 이미 첫페이지를 로딩할 때 나머지 부분을 구성하는 코드를 받아왔기 때문에 빠르지만
SSR은 첫페이지를 로딩한 과정을 정확하게 다시 실행합니다.
CSR과 달리 SSR은 SEO에 대응하기 용이합니다.
CSR은 초기 구동이 SSR 보다 무조건 느리다고 할 수 없습니다. 서버의 상태가 매우 나쁠 경우 서버에서 렌더링을 거치는 SSR 방식이 더 느릴 수도 있습니다.
SPA로 구성된 웹앱에서 SSR이 필요한 이유
SPA의 정의를 한번 짚고 넘어가봅시다.
단일 페이지로 구성된 웹어플리케이션
첫 로딩시 전체페이지를 로딩하고 필요한 데이터만 JSON형태로 받아 동적으로 렌더링하는 방식
react 에서 아무 설정을 안건드리면 CSR 방식으로 렌더링을 합니다. SPA에 SSR이 필요한 이유는 SPA에서는 초기 웹사이트 진입시 필요한 모든 js html css등의 파일을 다 다운 받기 때문에 초기의 화면에서 로딩화면을 길게 볼 수 있습니다.
초기화면의 로딩시간을 줄이고 빠른 화면을 보여주고 싶다면 SSR이 필요하게 됩니다.
(물론 서버의 상태가 좋다는 가정하에)
또한 SPA는 필요한 파일을 클라이언트가 다 다운받아 화면을 그리므로 검섹엔진의 봇들이 비어있는 html 요소들만 보게 되므로 노출이 덜 되게 됩니다.
이런 SEO에 대응하기 위해 SSR이 필요 하게 됩니다.
Next.js
React의 SSR 프레임워크로 쉽게 SSR을 구축 할 수 있습니다.
Next.js를 설정하고 npm run을 하게 되면 먼저 _app.js 파일이 실행이 되게 됩니다.
_app.js는 서버로 요청이 들어왔을 때 가장 먼저 실행되는 컴포넌트로 , 페이지에 적용할 공통 레이아웃의 역할을 하게 됩니다.
위에서 Component 속성값은 서버에 요청한 페이지가 됩니다.
pageProps는 getInitialProps, getStaticProps, getServerSideProps 중 하나를 통해 페칭한 초기 속성값이 됩니다.
위의 함수들은 Next.js에서 어떠한 렌더링 방법을 선택을 할것이냐에 따라 선택하여 쓰는 함수들 입니다.
