CSR과 SSR

YuJin Lee·2021년 11월 2일

TIL

목록 보기

3/3

출처: https://www.youtube.com/watch?v=iZ9csAfU5Os
엘리의 드림코딩 - 서버사이드 렌더링 (개발자라면 상식으로 알고 있어야 하는 개념 정리 ⭐️)

static site

1990년 중반까지는 모두다 static 사이트였다. 서버에 만들어진 HTML문서가 있고 사용자가 주소에 접속하면 서버에 배포된 HTML 문서를 받아와서 보여주는 방식이다. 페이지에서 다른 링크를 클릭하면 HTML을 서버에서 다시 받아와서 페이지 전체가 업데이트 되어 사용성이 매우 떨어졌다.

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

1998년, XMLHttpRequest API가 개발되어 HTTP문서 전체가 아니라 json과 같은 포멧으로 서버에서 필요한 데이터만 받아올 수 있게 되었다. 그 데이터를 JavaScript를 이용해서 동적으로 HTML요소를 생성해서 페이지에 업데이트 하는 방식이다.

2005년에 이러한 방식이 AJAX라는 공식적인 이름을 가지게 되었고, 구글에서도 AJAX를 이용해 Gmail, Google Map과 같은 웹어플리케이션을 만들기 시작했다. 이것이 현재 많이 쓰이고 있는 SPA(Single Page Application) 이다. 사용자가 한 페이지에서 필요한 데이터만 받아와서 부분적으로 업데이트하는 방식이다. SPA 방식으로 어플리케이션을 사용하듯 웹에서도 사용성이 조금씩 좋아지게 되었다.

이런 SPA 트랜드와 PC 성능 향상으로 많은 작업을 무리없이 처리하게 되었고 JavaScript 표준화가 이루어지면서 React, Angular, Vue와 같은 프레임워크가 등장하게 된다.

SPA (Single Page Application)

사용자가 한 페이지에 머물면서 필요한 데이터를 서버에서 받아와서 부분적으로 업데이트 하는 것.

문서 내에 또 다른 문서를 담을 수 있는 iframe 태그가 도입되어 페이지 내에서 부분적으로 업데이트를 할 수 있게 되었다. 또한 우리가 많이 쓰고있는 fetch API의 원조인 XMLHttpRequest API가 개발되어서 서버에서 필요한 데이터만 받아올 수 있게 되었다. 그 데이터를 자바스크립트를 이용해서 동적으로 HTML 요소를 생성해서 페이지에 업데이트 하는 방식이다.

이러한 방식이 2005년에 공식적인 AJAX라는 이름을 가지게 되고 구글에서도 AJAX를 이용해서 Gmial, Google Maps와 같은 우리가 많이 쓰는 웹 애플리케이션을 만들기 시작했다.

CSR (Client Side Rendering)

body 안에 아이디 루트만 하나 들어있고, 어플리케이션에서 필요한 자바스크립트의 링크만 들어져 있다. HTML은 텅텅 비어있기 때문에 처음에 접속하면 빈 화면만 보이고 링크된 어플리케이션 자바 스크립트를 서버로부터 다운로드 받게 된다. 이 자바스크립트에는 어플리케이션에 필요한 로직들 뿐만 아니라 어플리케이션을 구동하는 프레임워크와 라이브러리의 소스 코드들도 다 포함되어 있다. 그렇기 때문에 사이즈가 굉장히 커서 다운로드 받는 데 시간이 걸린다.

추가로 필요한 데이터가 있다면 서버에 요청해서 데이터를 받아온 다음에 이것들을 기반으로 해서 동적으로 HTML을 생성한다. 추가로 필요한 데이터가 있다면 서버에 요청해서 데이터를 받아온 다음에 이것들을 기반으로 해서 동적으로 HTML을 생성해 사용자에게 최종적인 어플리케이션을 보여주게 된다.

큰 문제점으로는 사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수 있다는 점과, 썩 좋지 않은 SEO를 꼽을 수 있다. CSR에서 사용되어지는 HTML 바디는 대부분 텅 비어져 있기 때문에 검색 엔진들이 CSR로 작성된 웹페이지를 분석하는데 많은 어려움을 겪고 있다.

CSR은 TTV와 TTI가 같다. 즉 사용자가 웹사이트를 볼 수 있음과 동시에 클릭하거나 인터랙션이 가능하게 된다.

SSR (Server Side Rendering)

이런 SEO 문제를 해결하기 위해 서버 사이드 렌더링이 도입되게 된다. 클라이언트에서 모든 것을 처리하는 방식과 다르게 웹사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들게 되고, 이렇게 만들어진 HTML 파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에게 보내주게 된다. 그러면 클라이언트 측에서는 잘 만들어진 HTML 문서를 받아와서 바로 사용자에게 보여줄 수 있게 된다.

이런 SSR을 사용하게 되면, CSR을 사용했을 때보다 페이지 로딩이 빨라진다는 장점이 있고, 좀 더 효율적인 SEO를 할 수 있다.

하지만 SSR에서도 큰 문제점이 발생하는데, 바로 static site에서 발생했던 blinking issue가 다시 발생하는 것이다. 새로운 링크를 클릭하면 전체적인 웹사이트를 다시 서버에서 받아오는 것과 동일하기 때문에 좋지 않는 UX를 겪을 수 있고, 서버에 과부하가 걸리기 쉽다. 가장 치명적인 단점으로는, 동적으로 데이터를 처리하는 자바스크립트를 불러오지 못했기 때문에 사용자가 여기저기 클릭해도 반응이 없는 경우가 발생할 수 있다. TTV와 TTI 사이의 공백 시간이 꽤 긴 편이다.

TTV 와 TTI

TTV (Time To View) : 사용자가 화면을 볼 수 있는 시점
TTI (Time To Interact) : 사용자가 화면을 조작할 수 있게 되는 시점

웹사이트를 분석할 때 TTV와 TTI도 중요한 매트릭으로 사용할 수 있다.

CSR을 많이 사용한다면, 우리가 최종적으로 번들링해서 사용자에게 보내주는 자바스크립트 파일을 어떻게 하면 효율적으로 많이 분할해서 사용자가 첫 번째로 보기 위해 필요한 필수적인 요소만 보낼 수 있을지 고민하면 좋다.

SSR을 많이 사용한다면, 사용자가 화며을 보고 조작하는 시간의 차이를 줄이기 위해 어떤 노력을 할 수 있을지 고민하면 좋다.

SSG (Static Site Generation)

React 같은 경우는 클라이언트 사이드 렌더링에 특화된 라이브러리지만 Gatsby라는 라이브러리와 함께 사용하면 리액트로 만든 웹어플리케이션을 정적으로 미리 생성해두어서 서버에 배포해 놓을 수 있다. 이렇게 만들어진 웹사이트들이 모두 정적인 것은 아니다. 추가적으로 데이터를 받아오거나 동적으로 처리해야 되는 로직이 있다면 자바스크립트 파일을 함께 가지고 있을 수 있다.