1. SSR (Server Side Rendering)

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

SSR을 사용하면 모든 데이터가 맵핑된 서비스 페이지를 클라이언트(브라우저)에게 바로 보여줄 수 있다.
서버를 이용해서 페이지를 구성하기 때문에 클라이언트에서 구성하는 CSR(client-side rendering)보다 페이지를 구성하는 속도는 늦어지지만 전체적으로 사용자에게 보여주는 콘텐츠 구성이 완료되는 시점은 빨라진다는 장점이 있다.

2. CSR (Client Side Rendering)

CSR은 Client Side Rendering의 약자로 최초에 한번 서버에서 전체 페이지를 로딩하여 보여주고 이후에는 사용자의 요청이 올 때마다, 리소스를 서버에서 제공한후 클라이언트가 해석하고 렌더링하는 방식이다.

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

3. 차이점

1. 초기 렌더링 속도

SCR은 첫 렌더링된 html 을 클라이언트에게 전달해 주기때문에 초기로딩속도를 많이 줄여줄 수 있다. 자바스크립트 파일을 불러오고 렌더링 작업이 완료되기 전에 사용자가 사이트 컨텐츠를 이용할 수 있게된다.

CSR은 페이지를 읽어들이는 시간, 자바스크립트를 읽어들이는 시간, 그리고 자바스크립트가 화면을 그리는 시간까지 모두 마쳐야 콘텐츠가 사용자에게 보여진다. 여기에 웹 서버에서 콘텐츠 데이터라도 가져와야 한다면 그 시간은 더욱 길어진다.

즉, 초기 구동속도가 느리다. 하지만 그 이후 CSR은 사용자의 행동에 따라 필요한 부분만 다시 읽어들이기 때문에 서버 측에서 렌더링하여 전체 페이지를 다시 읽어들이는 것보다 빠른 반응속도를 기대할 수 있다.

2. SEO

대부분의 웹 크롤러, 봇들이 자바스크립트 파일을 실행시키지 못하고 HTML에서만 컨텐츠를 수집한다. 때문에 CSR 방식으로 개발된 페이지를 빈 페이지로 인식하게 된다. 검색엔진에 제대로 노출이 되지 않는 다면 웹페이지의 유입이 줄어드는 악순환이 반복된다.
SSR은 view를 서버에서 전부 렌더링하여 내려주므로 HTML에 모든 컨텐츠가 저장되어 있기 때문에 SEO 적용에 큰 문제가 없다.

3. 보안

기존의 SSR에서는 사용자에 대한 정보를 서버 측에서 세션으로 관리를 하지만 CSR 방식은 클라이언트 측의 쿠키말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않다.