SSR과 CSR

SSR

서버 사이드 렌더링의 약어로써 단어 그대로 서버에서 렌더링을 작업한다. 기존에 존재하던 방식으로 사용자가 웹 페이지에 접근할 때, 서버에 페이지에 대한 요청을 하며 서버에서는 HTML, view와 같은 리소스들을 어떻게 보여질지 해석하고 렌더링하여 사용자에게 반환한다.

 

웹에서 제공하는 정보량이 많아지고 데스크탑보다 성능이 다소 떨어지는 스마트폰의 웹에 대한 요구가 커지면서 새로운 기법이 탄생했다.

 

 

CSR

클라이언트 사이드 렌더링의 약어로써 최초에 1번 서버에서 전체 페이지를 로딩하여 보여주고 이후에는 사용자의 요청이 올 때마다, 리소스를 서버에서 제공한 후 클라이언트가 해석하고 렌더링을 하는 방식이다. 여기에 Angular JS, Backbone JS같이 SPA 개발에 쉬운 JS 프레임워크가 등장했다. 여기에 점점 클라이언트가 무거워지자 다시 view만 관리하자는 철학으로 React JS가 등장하게 된다.

 

*기존 웹에서 사용하는 방식이 모두 SSR이 아닌 것처럼 SPA 방식이 모두 CSR인 것은 아니다.

 

 

 

차이점

크게 초기 렌더링 속도, SEO, 보안으로 볼 수 있다.

 

 

 

초기 렌더링 속도

CSR의 경우, 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기 때문에 서버 측에서 렌더링하여 전체 페이지를 다시 읽어들이는 것보다 빠른 반응속도를 기대할 수 있다. SSR을 한다 하더라도 ajax 기능을 위해 클라이언트 렌더링 요소가 포함될 수 밖에 없다. 이러한 점으로 미루어보아 클라이언트 측에서 렌더링을 하게 되면 서버 사이드 렌더링이 따로 필요하지 않기 때문에 일관성 있는 코드를 작성할 수 있다.

 

CSR은 페이지를 읽어들이는 시간, JavaScript를 읽어들이는 시간, 그리고 JavaScript가 화면을 그리는 시간까지 모두 마쳐야 콘텐츠가 사용자에게 보여진다. 여기에 웹 서버에서 콘텐츠 데이터라도 가져와야 한다면 그 시간은 더욱 길어진다. 즉, 초기 구동속도가 느리다. 초기 구동속도를 제외하고는 빠른 반응을 보여준다.

 

이와 반대로 SSR의 경우 서버에서 view를 렌더링하여 가져오기 때문에 view를 보기까지 초기 구동속도가 빠르다. 물론 JS 파일을 전부 다운로드 받기 전까지는 제대로 동작하지 않지만 사용자 측면에서는 빠르다 느낄 수 있다.