참고
CSR (Client Side Rendering)
NOTE
말 그대로 클라이언트 측에서 어플리케이션 렌더링이 이루어진다.
1.
웹 브라우저 → 서버 : HTML을 요청한다
웹 브라우저 ← 서버 : 골격만 있는 HTML(index.html)과 애플리케이션을 구동하는 자바스크립트 링크를 리턴한다.
다음과 같이 매우적은 HTML과, JS주소가 담겨있음
2.
웹 브라우저 → 서버 : HTML에서 필요로하는 자바스크립트를 서버에 요청한다 (app.js)
웹 브라우저 ← 서버 : HTMl에서 필요로하는 자바스크립트(app.js)를 내려주는데 이때,
자바스크립트에는 프레임워크나 라이브러리도 포함되어 있다(용량이 커서 시간이 오래 걸린다)
3.
웹 브라우저 → 서버 : 추가로 필요한 데이터 HTTP API로 요청(추가 데이터 요청)
웹 브라우저 ← 서버 : 데이터를 JSON 형태로 가공하여 HTTP로 응답해준다.
•
[문제점]
◦
사용자가 첫 화면을 보기까지 오래 걸릴 수 있다
◦
썩 좋지 않은 SEO(Search Engine Optimization)
▪
검색엔진들은 서버에 등록된 웹사이트를 하나씩 돌아다니며 웹사이트의 HTML을 분석해서 검색에 도움을주는데, SCR의 HTML은 텅텅 비어져있어 분석하는데 어려움이 존재함
SSR(Server Side Rendering)
NOTE
서버에서 최종 HTML을 생성해서 클라이언트에 전달
•
CSR의 문제점으로 인해 이전의 Static Sites에 영감을 받은 SSR이 도입됨
•
SSR은 웹사이트에 접속하면 서버에서 미리 필요한 데이터들을 모두 가져와 만든 HTML 파일을 보내주어, 사용자가 웹사이트를 볼 수 있게 한다.
•
이후 서버에서 HTML 파일을 동적으로 제어할 수 있는 JS파일을 요청해 받아오게 되면
이때부터 사용자의 클릭과 같은 인터렉션을 처리할 수 있음
•
[장점]
◦
페이지 로딩 시간이 빨라진다
◦
모든 컨텐츠가 HTML에 담겨있기 때문에 SEO를 좀 더 효율적으로 할 수 있음
•
[단점]
◦
Static Sites에서 발생했던 것과 동일하게 blinking(깜빡임)이 존재함
◦
사용자가 무언가 클릭하게 되면 다시 서버에서 받아와야 해서 UX적으로 안좋음
◦
서버 과부하 걸리기 쉬움
◦
웹사이트를 확인할 수는 있지만, 동적으로 처리해야하는 JS다운이 아직 안되서 반응이 없는 경우가 발생할 수 있음
CSR과 SSR의 시간에 따른 분석
NOTE
•
웹사이트 성능 분석시 TTV와 TTI가 사용된다
◦
TTV(Time To View) : 사용자가 웹 사이트를 보는데 까지 걸리는 시간
◦
TTI(Time To Interact) : 사용자가 클릭을 하거나 인터렉션이 가능하게 되는데 걸리는 시간
CSR은 사용자가 웹 사이트를 볼 수 있음과 동시에 인터렉션이 가능하다
•
그러므로 최종적으로 번들링해서 사용자에게 보내주는 자바스크립트 파일을 어떻게 하면 효율적으로 분할할 수 있을지, 어떻게 하면 사용자가 첫 페이지를 보기위해 필수적으로 필요한 것만 보낼 수 있을지 고민해야한다.
SSR은 사용자가 웹 사이트를 볼 수 있는 시간과 인터렉션이 가능한 시간의 공백기간이
존재한다
•
이 시간의 단차를 어떻게 줄일지 고민해봐야 한다.