22.11.09 : SSR, CSR (TTV, TTI)

본문은 드림코딩 강의를 정리한 내용입니다.

 

1990년 중반까지는 모두다 Static site였다.

서버에 잘 만들어진 html 문서들이 있고 사용자가 브라우저를 통해 도메인에 접속하면 서버에 이미 배포되어있는  html 문서들을 가져와서 보여주는 형식을 사용해왔다. 문제점은 클라이언트가 페이지 내에서 다른 링크를 클릭하면 서버에서 해당 페이지의 html을 다시받아와서 페이지 전체가 업데이트 되어야 했다. 

 

1996년, 문서 내에서 또 다른 문서를 담을 수 있는 iframe 태그가 도입되었고, 페이지 내에서 부분적으로 문서를 받아와 업데이트가 가능해졌다. 

 

1998년, fetch API의 원조, XMLHttpRequest가 개발되어 html이 아니라 jason 같은 포맷으로 필요한 데이터만 받아올 수 있게 되었다. 그 데이터를 자바스크립트를 이용해 동적으로 HTML 요소를 생성해 페이지 업데이트를 하는 방식이다. 

 

2005년, AJAX 라는 공식적인 이름을 가지게 된 이러한 방식으로 Google에서 gmail, google map 등의 웹 어플리케이션을 만들기 시작. 이것이 현재 널리 쓰이는 SPA 싱글 페이지 어플리케이션이다. 

SPA - 사용자가 한 페이지 내에서 머물며 필요한 데이터를 서버에서 받아와 부분적으로 업데이트 하게 된다. 하나의 어플리케이션을 사용 하듯, 웹사이트에서도 사용성이 좋아지게 됨. 

 

SPA 트렌드 + 사용자들의 PC성능이 점차 좋아지면서 많은 것들을 무리없이 처리 -> 자바스크립트 표준화 잘 되어 감에 따라 Angular, Vue, React 와 같은 프레임워크의 등장과 함께 Client Side Rendering (CSR)시대로 접어들게됨. 

CSR

 

서버에서 index.html 을 클라이언트에 보내주면 CSR은 첫 html을 빈 화면으로 받고 추가적인 js 파일을 가져와서 화면에 그리는 과정까지 완료되어야 첫 화면이 사용자에게 보여지게 된다. 이 js파일은 어플리케이션에 필요한 로직 뿐만 아니라 어플리케이션을 구동하는 라이브러리, 프레임워크의 소스코드들도 다 포함되어있기 때문에 사이즈가 커서 다운로드 받는데 시간이 소요 될 수 있다. 추가로 필요한 데이터가 있다면 서버에 요청해 데이터를 받아와 이것들을 기반으로 해 동적으로 html을 생성해 사용자에게 화면을 보여주게 됨

 

단점

1. 첫 화면 보기까지 시간이 오래 걸릴 수 있다.

2 Low SEO(Search Engine Optimization) 

 

Search Engine Optimization, SEO란?

 

서버에 등록된 웹사이트들의 html을 분석해 검색할 때 웹사이트를 빠르게 검색할 수 있게 도와줌. CSR의 바디는 대부분 비어져있어 검색엔진들이 CSR로 작성된 웹페이지를 분석하는것이 어렵다.

 

 

 

이 때문에, 1990년 중반에 사용하던 static sties에서 영감을 받아

SSR (Server Side Rendering)을 도입.

 

SSR

 

서버에서 필요한 데이터를 모두 가져와 html 파일을 만들게되고, 이것을 동적으로 제어할수잇는 소스코드와 함께 클라이언트에 보냄,

바로 사용자에게 보여줄 수 있음.

 

장점

1. 첫번째 페이지 로딩이 빨라짐

2. 모든 컨텐츠가 html에 담겨져 있어 효율적인 SEO가 가능

 

단점

1. Blinking 이슈가 있음. 좋지 않은 UX

2. 서버에 과부하가 걸리기 쉽다. 사용자가 많을 수록 클릭 시 마다 서버에서 필요한 데이터 받아와서 html만들어야 함. 

3. 사용자가 웹사이트 빠르게 확인 가능하나 동적으로 데이터 처리하는 자바스크립트를 아직 다운받지 못해서 클릭해도 반응 없을 경우 발생할 수도 있다. TTV 와 TTI 의 공백시간이 길다.

 

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

CSR 작동 원리 :

사이트에 접속 -> 서버에서 index.html 받아옴 -> 파일이 비어있어 사용자에게 안보임 -> html 파일에 있는 웹사이트에 필요한 모든 로직이 담겨있는 자바스크립트를 요청 -> 동적으로 html을 생성할 수 있는 웹어플리케이션 로직이 담긴 자바스크립트 파일을 서버로부터 받아옴 -> 사용자에게 웹사이트 보여짐  =  TTV 와 TTI 가 동시에 가능함

 

SSR 작동 원리:

사이트 접속 -> 서버에서 이미 잘 만들어진 인덱스 파일을 받아옴 -> 사용자가 웹사이트 볼 수 있음 (TTV) -> 동적으로 제어가능한 자바스크립트 파일을 서버에서 받아옴 -> 사용자 인터렉션이 가능 해짐 (TTI) -> TTV 와 TTI 사이의 공백이 꽤 길다.

 

성능 분석시 TTV, TTI 도 중요한 매트릭으로 사용 가능하다.

 

CSR은 최종적으로 번들링해서 사용자에게 보내주는 자바스크립트 파일을 어떻게 하면 효율적으로 분할해서 첫번째로 사용자가 봐야 할 필수 요소만 보내 줄 수 있을지 고민해 보아야 함.

 

SSR은 사용자가 보고, 인터렉션 하는 시간의 단차를 줄이기 위해 어떤 노력을 할 수 있을지, 어떻게 좀 더 매끄러운 UX를 제공 할 수 있을지 고민해봐야함.

 

 

SSG (Static Site Generation) 

 

React + Gatsby
CSR방식으로 동작하는 React를 Gatsby라는 라이브러리와 함께 사용하면 리액트로 만든 웹어플리케이션을 정적으로 웹페이지 생성을 미리 해두어 서버에 배포해 놓을 수 있다. 이 웹사이트들은 모두 정적이진 않음. 추가적으로 데이터 받아오거나 동적으로 처리해야하는 로직있으면 자바스크립트 파일을 함께 가지고있기 때문에 동적인 요소 추가 가능. (React + Next.js 또한 가능)