90년대
static sites
서버에 html 문서가 있는 상태.
브라우저에서 www.어쩌고.com 접속하면 서버에 이미 배포된 html 문서를 받아와서 배포 하는 방식
단점이 있다면 페이지에서 다른 링크를 클릭하면, 서버한테 다시 받아와야함.
그러다보니 페이지가 깜빡. 깜빡.
98년도
fetch Api 원조.. XMLHttpRequest이 생기면서
브라우저에서 나 00Data 필요해 하면 서버에선 Json 형태로 필요한 데이터만 가볍게 받아오기 가능해짐. 이렇게 받은 데이터를 자바스크립트를 이용해서 동적으로 HTML요소를 생성해서 페이지에 업데이트.
2005년도
이런 방식을 이용해서(AJAX라고 부르기 시작) 웹어플리케이션을 만들게 되는데 요 것이 SPA. Single Page Application.
사용자가 한 페이지에 머물면서 필요한 서버를 부분적으로 받아와 업데이트 한다. 사용성이 완전 좋아졌지.
요런 SPA 트렌드. 자스의 성장등등... CSR방식이 인기를 끌기 시작
Client Side Redering
클라에서 처리하겠다!
서버에서 인덱스라는 HTML 파일을 클라에 보내주는데 여기엔 id="root"랑 어플리케이션에서 필요한 자바스크립트의 링크(app.js)만 들어있다.
그래서 HTML은 비어진 상태라 처음에 접속하면 암 것도 없음.
서버로부터 다운 받은 app.js에 어플리케이션에 필요한 로직.. 소스 코드등등 다 있어. 사이즈가 커서 다운로드 하는데 오래 걸림.
그 다음은 아까 말한..98년도 부분처럼 하는거임.
www.어쩌구.com에 접속한다.
서버에서 index.html 파일을 보낸다.
이때 html엔 텅텅 비어있어.(root랑 자바스트립트 링크 app.js) 그래서 처음 접속하면 빈화면 보인다.
다시 링크된 어플리케이션 자바스크립트(app.js)를 서버로부터 다운 받게 되는데 여기 자바스크립트가 거대한거임..
app.js문제점: 사용자가 첫화면 볼 때 오래 걸리고. seo 문제.
아까 말한 것처럼 CSR에서 사용되어지고 있는 HTML 바디는 대부분 비어져있어서 검색 엔진들이 CSR로 작성된 웹페이지 분석하는데 어려움 겪는 중.
이런 문제로. 90년대 사용한 static 방식.
SSR.
서버사이드렌더링이 도입되게 된다.
웹사이트 접속 하면 서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들게 되고 이렇게 잘 만들어진 HTML 파일을 동적으로 제어할 수 있는 자바스크립트 소스 코드와 함께 클라이언트에게 보내주게 됩니다.
그럼 이제 클라는 잘 만들어진 HTML 문서를 바로 사용자한테 짠! 하고 보여주기 가능.
//앞에 말을 다시 요약 해보면.
www.어쩌구.com.에 접속 한다.
서버에서 필요한 데이터(index.html, Data)를 모두 가져와서 HTML 파일을 만든다.
이렇게 만들어진 index.html 파일을 동적으로 제어할 수 있는 소스코드를 함께 클라이언트에 보낸다.
페이지 로딩이 빠르고. 모든 콘텐츠가 HTML에 담겨져 있기 때문에 조금 더 표율적인 SEO 가능.
문제점: Blinking issue,깜빡이는 문제점. 사용자가 클릭하면 전체적인 웹사이트를 다시 서버에서 받아오는 것과 동일해서... 서버에 과부하 걸리기도 쉽다.
사용자가 웹사이트를 빨리 볼 수 있지만, 동적으로 데이터를 처리하는 자바스크립트를 아직 다운 받지 못해서 반응이 없는 경우가 있음...
이 것이 TTV TTL
다시 요약.
CSR
CSR은 사이트에 접속 > 서버에서 index.js 파일 받는다. (이 인덱스 파일엔 아무 것도 없어서 사용자에게도 보이지 않음)> 클라는 이 인덱스 파일에 링크되어있는 이 웹사이트에서 필요한 로직이 담긴 js 파일을 요청하게 된다. > 서버는 최종적으로 동적으로 HTML 생성할 수 있는 우리의 웹어플리케이션 로직이 담긴 자바스크립트 파일을 받아오게 된다. 바로 이 순간 부터 브라우저가 사용자에게 보여지게 되고 인터렉션 및 클릭이 가능하다.
즉 CSR은 TTV(Time To View), 사용자가 웹사이트를 볼 수 있음과 동시에 TTI(Time To Interact), 클릭을 하거나 인터렉션이 가능한 이 타임라인이 같음.
SSR은 사이트에 접속한다 > 서버에서 잘 만들어진 index파일을 받아오게 되고 바로 사용자가 웹사이트를 볼 수 있다. 그러나 이때 아직 동적으로 처리할 수 있는 자바스크립트 파일은 받아오지 않았기 때문에 뭔가 누를 수가 없어. 반응 안 하는거야. > 그래서 최종적으로 자바스크립트 파일을 받아와야 한다.이 때부터 인터렉션, 클릭이 가능하다. 즉. SSR은 사용자가 볼 수 있는 시간과 인터렉션 할 수 있는 시간이 다르다.
CSR 과제..
우리가 최종적으로 번들링해서 클라에 보내는 자스 파일을 어떻게 효율적으로 보낼 수 있냐.. 첫 번째 사용자가 필수적으로 사용할 것만 보낼 수 있는지 고민 해야 함.
SSR과제. . 보는 시간과 인터렉션 시간을 줄이기 위해 어떤 노력을 할 수 있는지..
참고: 드림코딩 - 서버사이드 렌더링 내용
