SSR & CSR

서버에서 사용자에게 보여줄 페이지를 모두 구성하여 사용자에게 페이지를 보여주는 방식
JSP/Servlet의 아키텍처에서 사용

주의 사항

1. 페이지가 CSR보다 빨리 렌더링되어 빨리 보여줄 수는 있으나, react의 실행이 완료될 때까지 실제로 페이지와 상호작용할 수 없다.
   만약 고객이 빠르게 버튼을 클릭하면 react 실행이 완료될 때까지 작업이 실행되지 않는다.
2. SSR TTFB는 서버가 상대적으로 빈 응답을 보내는 대신 페이지에 대한 HTML을 만드는데 시간을 소비해야 하기 때문에 CSR보다 느림
3. 서버의 SSR 처리량이 CSR 처리량보다 적다. 특히 React의 경우 처리량이 매우 크다. ReactDOMServer.renderToString은 이벤트 루프를 유지하는 동기식 CPU 바인딩 호출이다.
   즉, ReactDOMServer.renderToString이 완료될 때까지 서버가 다른 요청을 처리할 수 없다.
4. 서버가 페이지에 대한 HTML로 응답하므로 SSR의 문서 크기가 CSR보다 크다.
5. SSR이 페이지 완료지섬이 더 빠르나 검색 속도 등 응답 속도는 CSR이 더 빠름
   

장점 & 단점

• 모든 데이터가 매핑된 서비스 페이지를 클라이언트(브라우저)에게 바로 보여줄 수 있음
• 서버를 이용해 페이지를 구성하기 때문에 CSR보다 페이지를 구성하는 속도는 늦어짐
• 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점이 빠름

결론
CSR은 초기 화면 구성이 빠르지만 데이터를 서버에 추가 요청해야 되기 때문에 전체적인 페이지 완료 시점이 SSR보다 느려짐

참고 자료 CSR VS SSR

• SEO : 웹사이트가 검색 결과에 더 잘 보이도록 최적화하는 과정

• SPA : 단일 페이지 애플리케이션으로, 현재의 페이지를 동적으로 작성함으로써 사용자와 소통하는 애플리케이션

  기존의 페이지 덩어리(JSP/Servlet)를 CSR 영역과 SSR 영역으로 분리
  

• Node.js 기반의 SSR

1. Node.js 기반의 SSR은 JS를 최대한 활용할 수 있다.
2. SSR을 사용하면 프론트엔드 영역과 백엔드 영역을 완전히 분리할 수 있다