SSR 과 CSR의 장단점 및 특징에 대한 이야기

이글에서는 SSR (Server Side Rendering) 과 CSR (Client Side Rendering) 의 차이점과 장단점 그리고 특징에 대해서 알고 프로젝트 성향에 고려해서 어떤방식을 사용하는지 좋을지에 대해서 알아보도록 하자

 

사실 이름에서 알수있듯이 매우 간단하게 설명이 가능한데 SSR은 ' 서버에서 HTML을 만들어서 우리에게 보여줌 ' 이고, CSR은 ' 클라이언트에서 HTML 만들어서 우리에게 보여줌 ' 이라고 생각하면된다

 

 

 

 

 

CSR (Client Side Redering)


 

 

우선 먼저 알아볼것은 CSR인데 CSR을 알고나서 SSR에 대해서 보면 차이점을 한눈에 알수있을것이다

우선 위에 그림에 적힌대로 한번 시나리오를 생각해보도록 하자

 

처음 유저가 웹사이트에서 요청을 보낸다(URL 입력) 그러면 CDN이 HTML 파일 및 JS로 접근할수있는 링크를 클라이언트로 보내게된다 여기서 CDN이란 유저의 요청에서 물리적으로 가장 가까운 서버에 요청을 보내는 것을 의미한다

이떄 클라이언트는 접근할수있는 링크를 받고 HTML과 JS를 다운로드한다 이때 유저는 아무것도 브라우저상에서 볼수없다

 

그다음 다운로드한 JS와 HTML을 실행하게되며 다운로드가 끝나고 실행되야 사용자가 볼수있게된다

그다음 데이터를 불러오기위해 서버에 API를 호출하게되며 서버는 이를 응답하여 Response를 클라이언트에 내려준다

응답받은 데이터를 컨텐츠안에 넣게되며 이제 페이지는 상호작용이 가능하고, 서버에서 가공된 데이터도 볼수있게된다

 

CSR의 큰특징은 HTML과 JS를 CDN 즉 클라이언트상에서 받아온다는것이다

CDN에서 받은 링크를 통해 다운로드하고 그다음 서버에 데이터를 얻기위한 API를 호출하게 된다는것을 볼수있는데

서버는 API를 호출하여 데이터를 줄뿐 HTML 및 JS를 렌더링하지않는다 클라이언트에서 렌더링을 하는것을 볼수있다

 

CSR을 기억하며 그다음 SSR에 대해서 알아보도록 하자

 

 

 

 

 

 

SSR (Server Side Redering)


 

 

 

그다음으로 살펴볼건 SSR로써 CSR과 동일하게 유저가 웹사이트에 요청을 보내는것까진 동일하다 (URL 입력)

여기서 우리가 주의깊게 봐야할것은 HTML과 같은 리소스들이 어디에서 렌더링되는지 확인하면 된다

CSR 같은경우에는 CDN에서 링크를 받아 다운로드후 실행한다(렌더링) 즉 클라이언트에서 렌더링을 하고 사용자에게 보여지게된다

 

하지만 SSR은 요청을 보낸순간 서버에서 바로 렌더링 가능한 HTML을 만들게되는데 이걸 클라이언트에게 전달해준다

여기서 이미 렌더링을 가능한 상태로 만들어놓았기때문에 HTML파일은 클라이언트에게 보내지는 즉시 바로 렌더링하게되며 그다음 클라이언트는 자바스크립트를 다운받는다

여기까지 아직 자바스크립트는다운받아지지 않았기때문에 사이트의 조작은 불가능하다

 

여기까지보면 SSR과 CSR의 차이점이 보일것이다 바로 HTML 파일의 렌더링을 서버에서하냐 클라이언트에서 하냐에 다라 다르다는것이다

 

그다음 자바스크립트를 다운완료하면 브라우저는 JS를 실행하여 컴파일하고 이제 최종으로 우리에게 보여질 화면이 만들어지게된다

 

키포인트는 렌더링 가능한 상태로 HTML파일이 클라이언트에게 전달되기때문에 기존 CSR은 링크를 받고 다운을 받는동안 사용자에게 아무것도 보여줄수없었지만 SSR은 HTML파일이 렌더링가능한 상태로 클라이언트에게 전달되기때문에 사용자가 볼수있다 (조작은 불가능)

 

 

 

 

 

 

SSR과 CSR의 특징 및 장단점


그래서 결국 SSR 과 CSR이 렌더링되는 지점이 클라이언트냐 서버냐에 따라서 다르다는것을 알수있었다

그렇다면 해당특징을 가진채로 어떤 장단점이 있는지 한번 확인해보도록 하자

 

첫번째로 웹페이지를 로딩하는시간은 어느방식이 더 빠른지 생각해보자

우선 CSR같은 경우에는 HTML 과 JS를 다운로드 후 실행한다는 과정이 있다 SSR은 HTML파일이 서버에서 렌더링이 된채로 우리에게 보여준다

CSR은 HTML 과 JS를 동시에 다운로드하고 실행하기때문에 사용자에게 보여지지 않는다는 점을 생각해보면 SSR은 HTML을 렌더링해서 주기때문에 CSR보다는 SSR이 페이지를 로딩하는 시간이 더 적다는것을 알수있다

 

하지만 만약 첫페이지에서 다른페이지로 넘어갈경우 SSR은 위에 과정을 전부 거쳐야하지만(매번 서버에서 렌더링가능한 HTML 파일을 클라이언트로 전달해준다) CSR같은 경우에는 처음 HTML파일과 JS를 다운로드 하게되면 더이상 다운로드 받을필요없이 바로 실행된다

 

이점에서 첫페이지 로딩은 SSR이 더빠르지만 그후 다른 동작측면에서는 CSR이 더 우세하다는것을 알수있다

그다음으로는 자원의 문제인데 SSR같은 경우에는 서버에 사람들이 많이 접속할경우에 서버자원을 더 많이 사용한다는 것을 알수있다

 

서버에서 일일히 사용자에게 렌더링된파일을 클라이언트에게 보내주지만 CSR같은 경우에는 클라이언트에서 다운을 받고 ' 서버 API ' 를 호출하기때문에 CSR이 서버자원 측면에서 더 좋은 효율을 가지고있다

 

왜냐면 SSR은 서버에 전부 맡긴다고 치면 CSR은 다운로드는 클라이언트에서 진행하기때문이다

이러한 특징들을 기억하면서 어느때 쓰면 좋을지 한번 생각해보자

 

 

 

 

 

SSR을 사용하면 좋을때


- 사용자의 네트워크가 느릴때 (CSR은 한번에 불러오지만 SSR은 페이지의 요청이 있을때마다 불러온다)

- 웹사이트의 동적인 작용이 별로없을때

- 처음 로딩이 빨라야할때

- 스크립트의 파일이 크고 로딩이 느려질때(CSR은 스크립트 로딩후 API로 데이터요청 하지만 SSR은 요청한번에 렌더링 가능한페이지를 클라이언트에게 전달해준다)

 

 

 

 

 

 

 

 

CSR을 사용하면 좋을때


- 사용자의 네트워크가 빠를때(한번에 다운로드 받는 속도가 빠를때)

- 서버에 자원을 클라이언트에서 나눠쓰고 싶을때(서버에 자원이 별로없을때)

- 스크립트가 가벼울때

- 어플리케이션에서 사용자와의 상호작용들이 많을때

 

 

 

 

여기까지 CSR과 SSR의 차이점을 알아보았으며 가장큰 차이점으로는 렌더링이 클라이언트에서 되냐, 서버에서 되냐 이점만 기억하면 될것이다

또한 API를 불러오는것은 CSR은 HTML, JS가 로딩되고나서 API를 호출하지만 SSR은 한번에 렌더링되어 클라이언트에게 보내진다는것을 기억하자