CSR vs SSR

CSR (Client Side Rendering)

CSR은 말 그대로 클라이언트에서 페이지를 렌더링함을 의미한다. 

• 브라우저에서 서버에 요청을 보내면, 서버에서 웹 페이지를 렌더링하지 않고 Single Page+ JS 파일를 클라이언트로 보낸다.  
• 클라이언트에서는 전달 받은 웹 페이지+JS 파일을 완전히 렌더링 된 페이지로 바꾼다. 
• 브라우저의 요청 경로가 다를 경우 새롭게 서버에 요청하는 것이 아닌, 기존에 받은 파일을 기반으로 페이지를 다시 렌더링하게 된다. 

장점

• 후속 페이지 로딩이 더 빠르다. 모든 파일이 사전에 로드되기 떄문
• 새로고침이 발생하지 않아 네이티브 앱과 비슷한 사용자 경험 제공 가능
• 별도의 API 호출이 필요가 없는 페이지의 경우 로딩 모듈 필요X 
• 서버 호출 때마다 전체 UI를 리 로딩할 필요 X
• TTV(Time to View)와 TTI (Time to Interaction)의 시점이 동일하다.

단점

• TTV가 SSR보다 느리다. (코드 spliting으로 일부 해결 가능- 먼저 필요한 JS만 보여주기) - 나머지는 누른 것에 따라 받아오기 (lazy loading) 
• SEO에 치명적인 단점이 존재한다. 크롤러가 웹 페이지에 대한 데이터 수집을 못하는 경우가 발생- sitemap 문서를 작성해 보완 작업을 할 수 있다. 

SSR (Server Side Rendering)

SSR은 CSR과 달리 브라우저가 아닌 서버에서 렌더링하는 것을 의미한다. 

• 브라우저가 요청을 보내면, 서버는 정해진 웹 페이지 파일을 브라우저로 보낸다. (완전히 렌더링된 상태로 보낸다) 
• CSR과 달리 데이터베이스에 있는 데이터가 필요한 경우 데이터를 불러온 다음 완전히 렌더링 후 보낸다. 
• 다른 경로로 이동할 경우 서버는 동일한 작업을 반복 수행한다. 

장점

• TTV가 CSR보다 빠르다. 
• SEO에 친화적이다. 다 만들어진 페이지를 검색엔진 크롤러가 요청으로 응답을 받기 때문에
• 당연한 말이지만 브라우저의 부담이 CSR보다 덜하다 

단점

• 페이지 이동마다 서버에서 페이지를 생성하기 때문에 TTFB(Time to First Btye)가 느리다. 
• 초기 로드에 많은 데이터가 필요한 대시 보드와 같은 경우 오히려 사용자 경험을 헤칠 수 있다. 

---

사용 관점

CSR 사용

• SEO가 우선순위가 아닌 경우
• 상호작용이 많은 경우 (빠른 라우팅으로 강력한 사용자 경험을 제공하기 때문)
• 웹 애플리케이션을 제작하는 경우

SSR 사용

•  SEO가 우선순위인 경우 
• 첫 화면 렌더링이 빠르게 일어나야 하는 경우 
• 사용자와의 상호작용이 적은 경우

---

출처

https://www.searchenginejournal.com/client-side-vs-server-side/482574/

Client-Side Vs. Server-Side Rendering

https://www.startupcode.kr/company/blog/archives/12

CSR과 SSR의 장단점

https://ajdkfl6445.gitbook.io/study/web/csr-vs-ssr-vs-ssg

CSR vs SSR vs SSG - 콥 노트