SSR(서버 사이드 렌더링) VS CSR(클라이언트 사이드 렌더링)

서버사이드 렌더링

VS

클라이언트 사이드 렌더링

 

전통적인 웹 대부분은 서버사이드렌더링 방식 이었다. 즉, 브라우저에 나타나는 형태 그대로를 HTML로 만들어 제공하고, 브라우저는 HTML을 표시하는 방식이었다. 이런 방식을 사용하다가 일부 HTML과 Script만 브라우저로 전달하고, 브라우저에서 Script를 실행시켜 서버에서 데이터를 조회하여 HTML을 생성하는 방식을 사용하게 되었다.

 

요즘은 웹에서 제공되는 정보가 정말 많기 때문에 전통적인 방식은 성능문제에 이슈를 낳았다. 요청 시 마다 새로고침이 일어나며 페이지를 로딩할 때마다 서버로부터 리소스를 전달받아 해석하고 화면에 렌더링 하는 방식이기 때문이다. 예를들어 현재 주소에서 동일한 주소를 가리키는(갖고있는) 버튼을 눌렀을때, 설정페이지에서 필요한 데이터를 다시 가져올 수 없다.

 

이것은 사용자와 인터랙션이 많은 요즘 웹앱에게 충분하지 않는 방법일 수 있다. 렌더링을 서버쪽에서 하는 것은, 그 만큼 렌더링을 위한 서버 자원이 사용되는 것이고, 불필요한 트래픽도 낭비되는 것이다.

 

반면 클라이언트 사이드 렌더링은 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기 때문에 서버 측에서 렌더링하여 전체 페이지를 다시 읽어들이는 것보다 빠른 인터렉션을 기대할 수 있다. 서버는 단지 JSON파일만 보내주고, html을 그리는 역할은 자바스크립트를 통해 클라이언트 측에서 수행한다.

뷰 렌더링을 유저의 브라우저가 담당하도록 하고, 먼저 웹앱을 브라우저에 로드 한 다음에 정말 필요한 데이터만 전달받아 보여주는 클라이언트사이드렌더링은 트래픽을 감소시키고, 사용자에게 더 나은 경험을 제공했다.

 

서버사이드렌더링 - 검색엔진최적화(SEO) 가능
서버사이드렌더링을 통해 얻을 수 있는 가장 큰 이점!

 

라우팅

주소에 따라 다른 뷰를 렌더링 하는것

 

왜 React를 선택할까?

• 코드의 구조화(Component)가 잘 되어있고, 이해하기 쉽다.
• ES6 지원 : Class기반 개발
• 그리고 내가 클라이언트사이드렌더링을 하는 React에 대한 경험이 있음
•