SSR과 CSR의 차이

 

SSR(Server Side Rendering)의 가장 큰 특징은 웹 페이지를 브라우저가 아닌 서버에서 렌더링 한다는 점입니다.

 

예를 들어 클라이언트 즉, 브라우저에서 서버에게 요청을 보냅니다. 특정 웹 페이지를 자신에게 보내달라구 말이죠. 이런 요청에 대응하여 서버는 특정 웹 페이지를 처음부터 끝까지 제작하는데 이 페이지를 제작하는 곳이 서버이기 떄문에 SSR이라고 이름을 붙인 것입니다. 추가로 웹 페이지를 만드는 과정에서 필요한 데이터는 서버와 연결된 데이터베이스를 통해 전달 받고 모든 일련의 과정을 통해 완성된 웹 페이지를 요청한 브라우저에게 다시 전달하면 끝나게 됩니다. 

 

 그렇다면 서버에서 웹 페이지를 제작하는 SSR의 반대 개념인 CSR은 무엇일까요?

 

CSR(Client Side Rendering)은 클라이언트에서 직접 필요한 웹 페이지를 제작한다는 개념입니다. 이전 SSR과 마찬가지로 웹 브라우저에서 필요한 특정 웹 페이지를 서버에 요청합니다. 여기까지는 SSR과 같지만 서버에서 완성된 웹 페이지를 반환했던 것과 다르게 CSR은 기본 틀이 될 수 있는 단일 페이지만 반환합니다. 

 

이떄 서버는 기본 페이지와 같이 렌더링에 필요한 JavaScript 파일을 함께 보내는데 이 JavaScript 파일은 브라우저에 도착한 이후 기본 틀 웹 페이지를 완전한 웹 페이지로 변환하는 역할을 수행합니다. 즉, 결과적으로 완전한 웹 페이지를 제작하는 장소가 클라이언트인 웹 브라우저이기 때문에 CSR라고 이름을 붙이게 된 것입니다.  

 

다시 한번 말하지만 가장 주요한 CSR과 SSR의 차이점은 페이지가 렌더링되는 위치입니다. SSR은 서버에서 페이지를 렌더링하고, CSR은 브라우저(클라이언트)에서 페이지를 렌더링합니다.

 

Use SSR

• SEO(Search Engine Optimization) 가 우선순위인 경우, 일반적으로 SSR(Server Side Rendering) 을 사용합니다.
• 웹 페이지의 첫 화면 렌더링이 빠르게 필요한 경우에도, 단일 파일의 용량이 작은 SSR 이 적합합니다.
• 웹 페이지가 사용자와 상호작용이 적은 경우, SSR 을 활용할 수 있습니다.

Use CSR

• SEO 가 우선순위가 아닌 경우, CSR을 이용할 수 있습니다.
• 사이트에 풍부한 상호 작용이 있는 경우, CSR 은 빠른 라우팅으로 강력한 사용자 경험을 제공합니다.
• 웹 애플리케이션을 제작하는 경우, CSR을 이용해 더 나은 사용자 경험(빠른 동적 렌더링 등)을 제공할 수 있습니다.