🍩 SSR

서버 사이드 렌더링 (Server Side Rendering)의 줄임말로,
리액트를 공부할 때 CSR과 함께 등장해 나를 괴롭히던 친구다.

SSR은 간단히 말해서 서버에서 렌더링 준비를 끝낸 후 클라이언트에 전달하는 방식을 말한다.
클라이언트에서 요청시마다 페이지가 새로고침되며 다음과 같은 순서로 렌더링이 진행된다.

1. 서버에서 즉시 렌더링이 가능한 HTML을 클라이언트에게 보냄. 즉, 화면을 먼저 그림.
   
2. 이 때 유저가 페이지를 만지게 되면, 아직 JS가 읽히기 전이라 사이트를 조작(인터랙션)할 수 없음.
   
3. 그 사이에 몰래 클라이언트는 JS를 열심히 다운받음.
   
4. 브라우저가 다운받은 JS를 컴파일하고 나서야 기억하고 있던 사용자 조작을 실행하며 인터랙션이 가능해짐.

🍩 CSR

클라이언드 사이드 렌더링 (Client Side Rendering)의 약자다.

서버에 요청이 들어오면 HTML과 JS를 클라이언트에게 전달하기에 클라이언트 측에서 렌더링을 진행한다.
SPA에서 쓰이는 방식으로써 하나의 빈 페이지를 서버측에서 제공하고,
View에 대해서는 클라이언트에서 JS를 통해 렌더링 하는 방식이다.

1. CDN이 HTML 파일과 JS에 접근할 수 있는 링크를 클라이언트에게 보냄.
   (CDN : 유저 요청에 '물리적으로' 가까운 서버에서 요청에 응답하는 방식 - ATM 같은 역할)
   
2. 클라이언트가 HTML과 JS를 다운로드
   ** SSR과 달리 유저는 아무런 화면도 보지 못하게 됨 **
   
3. JS 실행 후 화면이 어느정도 그려지고, 데이터를 받아오기 위해 API로 서버에 호출 => 응답

🍩 SSR과 CSR의 차이

1. 로딩 시간

1-1. 첫 페이지 로딩 시간

SSR은 필요한 HTML + 스크립트만, CSR은 HTML + CSS + 모든 스크립트를 한번에 불러오므로 보통 SSR이 더 빠르다.

1-2. 나머지 로딩 시간

CSR이 첫 로딩때 전부 받아왔기에 더 빠르다.
반면, SSR은 로딩 과정을 제대로 다시 실행하므로 느리다.

2. SEO (검색엔진 최적화)

CSR은 맨 처음 HTML 파일이 비어있기에 크롤러가 데이터를 수집할 수 없다.
따라서 SSR이 SEO에 더 유리하다.

3. 서버 자원 사용

SSR이 매번 서버에 요청을 하기 때문에 해당 자원을 더 많이 사용한다.
CSR은 클라이언트에게 일을 토스하므로 서버 부하가 적다.

🍩 각각 언제 쓰는게 적합한가?

SSR을 기준으로 적합한 사용 환경에 대해 말해보고자 한다.
이에 반대되는 환경에서는 CSR을 쓰는 것이 좋다.

• 네트워크가 느린 환경
• SEO가 필요한 경우
• 최초 로딩이 빨라야 하는 경우
• 인터랙션이 별로 없는 웹사이트를 개발하는 경우
  (인터랙션이 많은 사이트를 CSR로 해야하는 이유는, 아예 렌더링을 막아 인터랙션을 못하게 하는 것이 UX 측면에서 더 낫기 때문)
• 메인 스크립트가 무거운 경우

=> SSR과 CSR에 대해 공부하고 보니 왜 리액트가 CSR 기반인지에 대해 알 수 있었고, SEO에 대한 취약점 때문에 SSR을 얹거나 넥스트를 이용한다는 것도 배우게 됐다.

🍩 Next.js

SSR의 단점은 불필요한 부분까지 렌더링된다는 것이고,
CSR의 단점은 초기 진입 속도가 느리며 SEO에 취약하다는 것이다.
해당 단점을 해결하면서 각 방식의 장점을 살리고자 Next.js라는 프레임워크가 생겼다.
Next.js는 첫 페이지를 백엔드 서버에서 렌더링하여 데이터가 채워진 html을 받아 SEO 문제를 해결하고,
다음 페이지부턴 CSR 방식을 적용하여 필요한 데이터 부분만 갱신해 서버 부하를 줄이게 한 것이다.

SSR, CSR 방식에 정답이 있는 것은 아니다. 그저 각 방식의 장단점을 파악하여 프로젝트 환경 및 특징에 따라 필요한 것을 취사선택하는 것이 올바른 방법이다.

🔗 참고자료
SSR과 CSR의 차이
서버사이드 렌더링 , 클라이언트 사이드 렌더링
CSR vs SSR (feat. Next.js)
SSR vs CSR 비교 설명, Next.js가 탄생하게 된 이유