역사로 알아보는 CSR vs SSR

본 글은 드림 코딩 엘리의 강의를 정리한 글입니다.

cf) https://www.youtube.com/watch?v=iZ9csAfU5Os&t=140s 

[ 역사로 알아보는 csr과 ssr ]
1990 중반 까지 - static sites ( 서버 내에 이미 배포되어 있는 html 문서를 받아와서 화면에 보여주는 형식)
 but 문제: 페이지 내 다른 링크 클릭 시 서버에서 다시 해당 html 문서를 받아와 페이지 전체가 업데이트 되는 문제.

1996 - 문서 내에서 또 다른 문서를 담을 수 있는 iframe 태그가 도입됨에 따라 페이지 내에서 부분적으로 문서를 받아와서 업데이트를 할 수 있게 되었다.

1998 이후 - XMLHttpRequest(fetch API의 원조)로 html 문서 전체가 아닌, json과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아올 수 있게 되었다. 이 데이터를 javascript를 사용해 동적으로 html 요소를 생성해 업데이트 할 수 있게 되었다.

2005 - 위와 같은 방식이 공식적으로 'AJAX'라는 이름을 갖게 됨, 이것이 SPA(Single Page Application). 사용자가 페이지 내에 머무르면서 필요한 데이터를 서버에서 받아와 부분적으로만 업데이트를 하는 방식, 하나의 어플리케이션을 사용하는 것 같이 사용자의 사용성을 증대하였다.

computer의 성능향상과 js의 표준화가 되며 강력한 community(angular, react, vue)가 생성되어 csr 시대로 접어들게 된다.

CSR(Client Side Rendering) - 클라이언트 측에서 다하는 것, 서버에서 index.html 파일을 보내주는데, 이 index.html 파일에는 빈 html 파일과 어플리케이션에서 필요한 js파일 링크만 있다. 이 js 파일에는 어플리케이션에서 필요한 로직들 뿐 아니라, 어플리케이션을 구동하는 라이브러리/프레임워크에 해당하는 소스코드들도 포함되어 있다. 따라서 굉장히 사이즈가 커 다운받는데 시간이 오래 걸린다. 이로 인한 문제점은 아래와 같다.
문제점 1: 사용자가 첫화면을 보기까지 시간이 오래 걸릴 수 있다는 것
문제점 2: 좋지 않은 SEO(Search Engine Optimization)

SSR(Server side Rendering) - 클라이언트에서 모든 것을 처리하는 것과는 다르게 웹 사이트에 접속했을 때, server에서 html파일을 만들고 이 파일에 조금 동적으로 제어할 수 있는 js파일을 넣어 client에 보내준다.
장점1: 초기 페이지 로딩이 빠르다.
장점2: 모든 컨텐츠가 html에 담겨져 있어 좋은 SEO, 

문제점 1: Blinking Issue(깜빡 거리는 현상) // 페이지 전체를 서버에서 다시 받아와 교체하는 방식. 이로 인해 페이지간 교체될 때 깜빡거리는 현상이 발생되고 이는 ux를 떨어뜨린다.
문제점 2: 서버 과부화(Server side overhead)
문제점 3: (가장 치명적) 빠르게 웹사이트를 확인할 수 있지만, 동적으로 데이터를 처리하는 js를 아직 다운로드 받지 못해 클릭해도 반응이 없을 수가 있다.
TTV(Time To View)
TTI(Time To Interact)

CSR의 경우 - TTV,TTI 동일(사용자가 화면을 볼 수 있는 동시에, 클릭을 하는 인터랙션이 가능하다)
SSR의 경우 - TTV(서버에서 이미 만들어 놓은 html 파일로, 화면은 바로 볼 수 있다)와 TTI 간에 시간차가 존재

=> TTV, TTI는 웹사이트 성능을 분석할 때 사용되는 메트릭이다.

CSR - 최종적으로 번들링해서 사용자에게 보내주는 js 파일을 어떻게 하면 효율적으로 분할해서 처음 사용자가 봐야하는 필수적인 요소만 담을 수 있도록 고민해야한다.
SSR - tti/ttv의 시간 단차를 줄이는 방법에 대해 고민

SSG (Static Site Generation) - React + Gatsby를 활용해 파일을 먼저 생성해서 서버에 배포해놓도록 하며 동적으로 필요한 부분도 이후 서버에서 가져올 수 있다.