SSR, CSR, TTV, TTI

본 게시글은 유튜버 '드림코딩 by 엘리' 님의

'서버사이드 렌더링 (개발자라면 상식으로 알고 있어야 하는 개념 정리 ⭐️)'

영상을 요약해 적은 게시글 입니다.

---

• MPA (Multiple Page Application)

사용자가 페이지를 요청할 때마다, 웹 서버가 요청한 UI와 필요한 데이터를 HTML로 파싱해서 보여주는 방식의 웹 어플리케이션이다.

 

• SPA (Single Page Application)

하나의 HTML 파일을 기반으로 자바스크립트를 이용해 동적으로 화면의 컨텐츠를 바꾸는 방식의 웹 어플리케이션이다.

 

전통적인 방식을 이용한다면, SPA가 사용하는 렌더링 방식은 CSR이고, MPA가 사용하는 렌더링 방식은 SSR이다. 

---

웹의 역사 ⏲

 

🔍 1990년대 중반

 

모두 Static Sites였음.

서버에 이미 만들어진 html 문서가 있고 사용자가 url에 접속하면 서버에 이미 배포된 html 파일을 받아옴.

페이지 내에서 다른 링크를 클릭하면 다시 서버에서 해당 페이지의 HTML을 받아와서 페이지 전체가 업데이트 되어야 한다. 주소를 바꿀 때 마다 재렌더링 돼서 화면이 깜빡이는 불편을 안겨줌.

 

🔍 1996년

 

html 문서 내에 또 다른 문서를 담을 수 있는 <iframe>태그 도입.

페이지 내 에서 부분적으로 문서를 받아와 업데이트 할 수 있게 됨.

 

🔍 1998년~

 

fetch api 의 원조 XMLHttpRequest가 나옴.

문서 전체가 아닌 JSON과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아올 수 있게 함.

그 데이터를 JS로 동적으로 HTML요소 생성해 페이지에 업데이트함.

 

🔍 2005년~

 

AJAX 가 나와 SPA가 만들어짐.

하나의 앱을 사용하는 것 처럼 웹에서도 한 페이지에서 필요한 부분적인 정보들만 업데이트 하기 때문에 웹앱이라고 부름.

 

 

 

 

 

---

 

📡 CSR(Client Side Rendering)

 

출처

Client-side rendering vs. server-side rendering

CSR에선 브라우저가 서버에 HTML과 JS 파일을 요청한 후 로드되면 사용자의 상호작용에 따라 JS를 이용해서 동적으로 렌더링을 시킨다.

👍 장점

• 첫 로딩만 기다리면, 동적으로 빠르게 렌더링이 되기 때문에 사용자 경험(UX)이 좋다.
• 서버에게 요청하는 횟수가 훨씬 적기 때문에 서버의 부담이 덜하다.

👎 단점

• 모든 스크립트 파일이 로드될 때까지 기다려야 한다.
  • 리소스를 청크(Chunk) 단위로 묶어서 요청할 때만 다운받게 하는 방식으로 완화시킬 수 있지만 완벽히 해결할 수는 없다.
• 검색엔진의 검색 봇이 크롤링을 하는데 어려움을 겪기 때문에 검색엔진 최적화(Search Engine Optimization)의 문제가 있다.
  • 구글 봇의 경우는 JS를 지원하지만, 다른 검색엔진의 경우 그렇지 않기 때문에 문제가 된다.

---

클라이언트에서 다 해결하는 것.

서버에서 index라는 파일을 클라이언트에 보냄.

그 index 파일은 리액트의 index.html처럼 html 파일 자체는 텅 비어있고 App.js 등 연결된

js 파일로 다 해결하는 것.

 

html을 받고 링크된 JS 파일을 서버로부터 다운받는데 그 JS파일 내부에 모든 프레임워크 라이브러리의 소스코드도 포함 돼 있기 때문에 상당히 커서 다운로드 받는데 시간이 오래걸린다. 때문에 처음에 실행되기까지 사용자 경험이 좋지 않다.

 

또한 SEO가 좋지 않음. 구글이 아닌 다른 SEO 로봇은 html만 파싱하기 때문에 html은 텅 비어있고 JS로만 이루어진 SPA는 SEO가 좋지 않음.

 

TTV(사용자가 웹을 볼 수 있음)인 동시에 TTI(클릭 등 인터랙션)가 가능하게 함.

백지에서 사이트가 로딩이 되면 다 렌더링 된 것이기 때문임.

 

요약:

사이트에 접속함 -> 서버에서 텅 비어있는 html 파일 보내줌 -> 

받는 html파일에 있는 모든 필요한 코드가 담긴 JS 파일을 서버에 요청함 ->

최종적으로 동적으로 웹앱을 생성할 수 있는 코드가 담긴 JS파일을 받아옴 ->

로딩 후 뿅

 

어떻게 파일을 잘 분할해서 사용자가 처음으로 보는 화면에서 제일 필요한 화면만

빨리 내보낼 수 있는지 고민해야함.

 

 

 

📡 SSR(Server Side Rendering)

출처

 

SSR에선 브라우저가 페이지를 요청할 때마다 해당 페이지에 관련된 HTML, CSS, JS 파일 및 데이터를 받아와서 렌더링을 시킨다.

👍 장점

• 초기 로딩 속도가 빠르기 때문에 사용자가 컨텐츠를 빨리 볼 수 있다.
• JS를 이용한 렌더링이 아니기 때문에 검색엔진 최적화가 가능하다.

👎 단점

• 매번 페이지를 요청할 때마다 새로고침 되기 때문에 사용자 경험이 SPA에 비해서 좋지 않다.
• 서버에 매번 요청을 하기 때문에 서버의 부하가 커진다.

---

CSR의 문제점으로 인한 1990년대 Static Sites에 영감을 받아 나옴.

서버에서 필요한 데이터를 모두 가져와서 html파일을 만들고

동적으로 조금 제어할 수 있는 JS파일과 함께 클라이언트로 전송.

그러면 클라이언트는 바로 보여줄 수 있게 되는 것.

 

처음 페이지 로딩이 CSR보다 빨라짐.

모든 콘텐츠가 JS가 아닌 html에 담겨져 있어(Static Sites 처럼) SEO 가능.

 

그러나, 새 웹을 가져올 때 깜빡이는 Blinking issue 존재

서버에서 처리하므로 서버 과부하 사용자가 화면은 빨리 볼 수 있어도 자바스크립트 다운은 아직 받지 못해서 클릭에 반응이 없을 수 있다.

 

TTV(Time To View) 와 TTI(Time To Interact) 사이의 공백기간이 꽤 길다.

 

요약:

사이트 접속하면 이미 잘 만들어진 html 파일을 받아옴 -> TTV가능. ->

하지만 JS는 받아오지 않아서 TTI는 아님. -> 최종적으로 JS 받아옴 ->

TTI 가능

 

TTV와 TTI 사이의 간극을 어떻게 좁힐 수 있을지 고민해봐야함.

 

📡 SSG(Static Site Generation)

 

React + Gatsby

리액트로 만들어진 웹앱을 정적으로 먼저 HTML로 만들어둠.

서버에 배포해줌.

JS파일도 함께 가지고 있기 때문에 정적이지만은 않음.

 

📡 SSR in REACT

 

React + Next.js

- static generation

- no pre-rendering

- pre-rendering

 

다 적절히 섞어서 사용할 수 있게 해줌

 

---

 

출처: 

www.youtube.com/watch?v=iZ9csAfU5Os