✏️CSR vs SSR

1. CSR

CSR = Client Side Rendering

• 렌더링이 클라이언트(브라우저) 에서 일어난다.
• 서버는 요청을 받으면 클라이언트에 HTML과 JS를 보내준다. 클라이언트는 그것을 받아 렌더링을 시작한다.
• 서버에서 처리없이 클라이언트로 보내주기 때문에 자바스크립트가 모두 다운로드 되고 실행이 끝나기 전까지 사용자는 볼 수 있는 것이 없다.

 

2. SSR

SSR = Server Side Rendering

• 서버에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식이다.
• 서버에서 이미 '렌더 가능한 상태'로 클라이언트에 전달되기 때문에 JS가 다운로드 되는 동안 사용자는 무언가를 보고 있을 수 있다.

3. CSR 과 SSR 비교

	CSR	SSR
첫 페이지 로딩 시간	-HTML, CSS, 스크립트를 한 번에 불러온다. => 평균적으로 CSR이 느리다. -첫 화면은 빈화면이 나타나고 이후 링크된 app.js를 서버로부터 다운 받는다.	-필요한 부분의 HTML과 스크립트만 불러온다. => 평균적으로 SSR이 더 빠르다. -잘만들어진 HTML문서를 받아와서 바로 사용자에게 보여줄 수 있다. =>모든 콘텐츠가 문서 안에 담겨져 있기 때문에 좀 더 효율적인 SEO를 기대할 수 있다.
나머지 로딩 시간	-이미 첫페이지를 로딩할 때 나머지 부분을 구성하는 코드를 받아왔기 때문에 빠르다.	-첫 페이지를 로딩한 과정을 다시 실행하기 대문에 더 느리다.
SEO 대응	-자바스크립트를 실행시켜 동적으로 컨텐츠가 생성되기 때문에 자바스크립트가 실행되어야 meta data가 바뀐다.	-애초에 서버 사이드에서 컴파일되어 클라이언트로 넘어오기 때문에 크롤러에 대응하기 용이하다.
서버 자원 사용	-서버 부하가 적다.	-매번 서버에 요청을 하기 때문에 서버 자원을 더 많이 사용한다. -사용자가 많은 서버일수록 서버에 과부하가 걸리기 쉽다.(사용자가 클릭할 때마다 서버에 요청해서 필요한 데이터를 가져온 후 HTML을 만들기 때문에)
기타 참고사항	-브라우저가 서버에서 받아오는 최초의 HTML은 고작 <div id="root"></div> 태그 하나이기 때문에 검색엔진이 사이트의 내용을 파악하기 어렵다	-서버사이드 렌더링을 구현하는 메소드 renderToString이 스택을 막고 동기적으로 처리되는데, 실행되는 동안 서버가 멈춘다. -페이지를 이동할 때마다 깜빡임 이슈가 존재한다. -웹사이트를 빠르게 확인할 수 있다. -동적으로 데이터를 처리하는 JS파일을 아직 다운로드 받지 못해서 클릭해도 반응이 없을 수 있다.
필요한 경우	-색인이 비교적 중요하지 않은 경우 -관리자 페이지나 사용자 경험이 중요한 카카오맵과 같은 웹 앱	-검색 엔진의 색인이 필요한 경우 -콘텐츠가 주를 이루는 뉴스나 강의 페이지 같은 경우

* SEO : SEO(검색 엔진 최적화)는 웹사이트가 검색 결과에 더 잘 보이도록 최적화하는 과정. 검색 랭크 개선이라고도 한다. 검색 엔진은 웹을 크롤링하면서 페이지에서 페이지로 링크를 따라가고, 찾은 콘텐츠의 색인을 생성합니다.

*크롤러 : 한 웹페이지에서 다른 웹페이지로 연결되는 링크를 따라가며 웹사이트를 자동으로 검색하는 데 사용되는 프로그램

*색인(indexing) :  효율적인 검색을 위해 [문서 집합]을 미리 가공해두는 과정을 의미

4. TTV와 TTI

• TTV(Time To View) : 사용자가 웹브라우저에서 내용을 볼 수 있는 시점
• TTI(Time To Interact) : 사용자가 웹브라우저에서 인터렉션 할 수 있는 시점

5. CSR이 사용자에게 웹사이트를 보여주기 까지의 모든 과정

1. 클라이언트가 사이트에 접속한다
2. 서버에게서 index 파일을 받아온다 -> 텅텅 비어진 태그와 JS파일 링크 -> 빈화면
3. 해당 웹 앱에 필요한 모든 로직이 담긴 링크된 JS파일 요청 -> 빈화면
4. 동적으로 HTML을 생성할 수 있는 웹 앱 로직이 담긴 JS파일을 받아옴 -> 웹 사이트 노출, 상호작용

 => CSR은 4번부터 웹사이트가 사용자에게 보여짐과 동시에 사용자와의 상호작용이 가능해진다.

=> 즉, CSR은 TTV와 TTI가 동시에 이루어진다.

6. SSR이 사용자에게 웹사이트를 보여주기 까지의 모든 과정

1. 클라이언트가 사이트에 접속한다
2. 서버에서 이미 잘 만들어진 index 파일을 받아온다 -> 웹 사이트 노출
3. 동적으로 제어할 수 있는 로직이 담긴 링크된 JS파일 요청 -> 웹 사이트 노출
4. 사용자와 상호작용이 가능한 JS 파일을 받아옴 -> 웹 사이트 노출, 상호작용

=> 2번부터 웹사이트가 사용자에게 보여진다.

=> 사용자와의 상호작용은 4번부터 가능해진다.

=> 따라서 사용자가 웹사이트를 볼 수 있는 시간과 상호작용할 수 있는 공백시간이 꽤 생긴다.

=> 즉, SSR은 TTV와 TTI 사이의 공백 시간이 존재한다.

 

 

 

👀 생각해보기

React를 이용하여 프로젝트를 만들어 보기로 하면서 CSR을 사용할지, SSR을 사용할지에 대해 이야기를 나누었다.
SSR일 경우 react.js보다 next.js를 사용하는 것이 더 효율적이고,
next.js를 사용하게 되면 프론트와 백의 구분없이 다 같이 개발이 가능하다는 의견이 나왔다.
어느 기술이 무조건 좋다고 말할 수 없기 때문에 각자 CSR과 SSR 에 대해 찾아보고
이번 프로젝트에 어울리는 기술은 무엇일지 자신의 생각을 정리해오기로 하였다.

참고 사이트인 '망고플레이트'는 맛집에 대한 소개글과 이미지가 많은 검색기반 홈페이지이다.
사용자의 경험이 필요한 검색 기반의 홈페이지이기 때문에 SSR이 좀 더 효율적이지 않을까 싶다.

 

참고: https://velog.io/@vagabondms/%EA%B8%B0%EC%88%A0-%EC%8A%A4%ED%84%B0%EB%94%94-SSR%EA%B3%BC-CSR%EC%9D%98-%EC%B0%A8%EC%9D%B4

[ 기술 스터디 ] SSR과 CSR의 차이

참고:https://velog.io/@yu2jeong/TTV-Time-To-View-TTI-Time-To-Interact

TTV (Time To View) & TTI (Time To Interact)