서버 사이드 렌더링(SSR)과 클라이언트 사이드 렌더링(CSR)에 대하여

SSR, CSR 등 공부를 하면서 들어는 봤지만 이게 정확히 뭘 뜻하는 것인지 헷갈리는 단어들이 나오기 시작했다. 

들어는 봤지만 뜻을 잘 몰랐기에 간단하고 쉽게 정리를 해보고자 한다. 

서버 사이드 렌더링(SSR)

서버 사이드 렌더링이란 서버에서 필요한 모든 데이터(Data)를 가져와서 파일(HTML)을 만든 뒤 동적인 소스코드와 함께 클라이언트로 보내게 된다.

장점

• 초기 로딩속도가 빠르다. 
• 콘텐츠가 HTML에 포함되어 있기 때문에 검색엔진이 이를 판단해 보다 노출이 잘된다. 

단점

• 페이지를 이동할 때마다 전체적인 웹사이트를 서버에서 다시 받아오는 것이기 때문에 깜빡임 이슈가 있다. 
•  사용자가 요청할 때마다 서버에서 HTML을 만들기 때문에 서버의 과부하 걸리기가 쉽다. 
• TTV(Time to View)와 TTI(Time to Interact)의 차이가 발생되게 된다.
  로딩이 된 후 사용자에게 보이는 시점(TTV)에 동적인 Js파일을 다운로드하기 때문에 실제로 사용자가 사용할 수 있는 시점(TTI)은 조금 더 후이다.

클라이언트 사이드 렌더링(CSR)

클라이언트 사이드 렌더링이란 클라이언트 측에서 모든 것을 해결하는 것을 말한다. 

즉 클라이언트(브라우저)에서 서버에 요청을 하면 HTML 파일만 반환한 후 사용자에게 보여준 뒤 추후에 서버로부터 로직, 프레임워크, 라이브러리 등 필요한 데이터를 다운로드하기 시작한다.   

장점

• CSR은 초기에 모든 데이터를 다운로드하여 오기 때문에 첫 로딩 이후로 구동 속도가 빠르다. 
• 초기에 뼈대 역할만 하는 HTML만 보내기 때문에 서버의 부하가 적다. 

단점

• 초기에 데이터를 받아오기 때문에 초기 로딩 속도가 느리다. 
• 검색 엔진에서 CSR의 경우 데이터를 받아오기 전에 판단을 하기 때문에 노출이 잘 되지 않는다는 단점이  있다.
  이 현상을  Low SEO(Search Engine Optimization)라고 한다. 
  하지만 구글의 검색엔진은 다른 검색엔진과 달라 CSR을 사용하여도 검색엔진이 이를 판단하여 노출을 시켜준다. 

결론

SSR과 CSR은 각각의 장단점을 모두 갖고 있기 때문에 어느 한 가지만 좋다고 할 수는 없다. 

그렇기에 개발자가 만들고자 하는 브라우저가 SSR로 렌더링 하는 것이 더 좋은지, CSR로 렌더링 하는 것이 더 좋은지 직접 판단하여 사용하는 것이 제일 좋은 방법이다.