클라이언트 사이드 렌더링(CSR)과 서버 사이드 렌더링(SSR)
어떤 회사는 CSR을 사용하고, 어떤 회사는 SSR을 사용한다. 또 어떤 회사는 둘의 방식을 섞어서 사용하기도 한다. 각기 다른 방식을 사용하는 이유와 장단점들 그리고 어떻게 하면 더 좋게 개선할 수 있을까 등을 알아보자.
먼저 웹 트렌드와 역사(SPA 시대까지)를 살펴보면서 해당 방식이 등장하게 된 이유를 살펴보자.
웹의 역사(SPA 시대까지)
1990년대 중반 - 정적 웹 사이트들
1990년대 중반까지는 모두 정적 웹 사이트들(Static Sites)이었다. 이미 잘 만들어진 HTML 문서들이 만들어져 있고, 사용자가 브라우저에서 해당 사이트에 접속하면 서버에 이미 배포되어져 있는 HTML 문서를 받아와서 보여주는 방식이다. 예를 들어 페이지 내에서 다른 링크를 클릭하면, 다시 서버에서 해당 페이지의 HTML 문서를 받아온 후 페이지 전체가 업데이트 되어야 한다. 사용성이 떨어지고 페이지마다 전체가 업데이트 되어야하는 단점이 있다.
1996년 - iframe 태그 도입
문서 내에서 또 다른 문서를 담을 수 있는 iframe 태그가 도입이 되었고 이후 페이지 내에서 부분적으로 문서를 받아와서 업데이트 할 수가 있게 된다. 지금도 간혹 쓰이고 있는 태그이다.
예컨대 블로그 내 영상이나 지도를 불러올 때 쓰이기도 한다.
1998년 ~ing - XMLHttpRequest
프론트엔드 개발 시 자주 쓰이는 Fetch API의 원조 XHR Web API가 개발이 되어 이제는 HTML 문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아올 수 있게 된다.
해당 데이터를 자바스크립트를 이용해서 동적으로 HTML 요소를 생성한 후 페이지에 업데이트 하는 방식이다.
2005년 - AJAX
2005년 XHR과 같은 방식이 공식적인 AJAX라는 이름을 가지게 되고 AJAX를 이용해서 카카오맵, Gmail과 같은 웹 앱들이 만들어지기 시작한다.
이것이 현재 널리 쓰이고 있는 SPA(Single Page Application)이다. 사용자가 한 페이지 내에 머무르면서 필요한 데이터만 서버에서 받아와 부분적으로 업데이트 된다. 이런 방식으로 하나의 어플리케이션을 사용하듯 웹 사이트에서도 앱과 같은 사용자 경험을 느끼게 되어 사용성이 굉장히 좋아지게 된다.
CSR(Client Side Rendering)
SPA가 트렌드가 되고 사용자의 PC 성능이 점차 좋아지면서 많은 것들을 무리 없이 처리할 수 있게 되었다. 또한 자바스크립트도 표준화가 잘 되어짐에 따라 강력한 커뮤니티를 바탕으로 Angular, React, Vue.js와 같은 프레임워크, 라이브러리가 생겨 CSR의 시대가 오게 된다.
CSR은 쉽게 말해 모든 렌더링을 클라이언트 측(브라우저)에 위임하는 것을 의미한다. CSR에서 사용되는 가장 추상적이고 간단한 HTML 예제를 살펴보자.
<!DOCTYPE html>
<html lang="ko">
<head>
<meta charset="utf-8" />
<meta
name="description"
content="Web site"
/>
<title>App</title>
</head>
<body>
<div id="root"></div>
<script src="app.js"></script>
</body>
</html>예제의 body 안에는 고작 하나의 id가 root인 <div id="root"></div> 태그와 앱에 필요한 자바스크립트 파일의 링크만 들어있다. 따라서 HTML은 텅텅 비어져 있기 때문에 첫화면은 빈화면만 보이고 그 후 링크된 app.js를 서버로부터 다운로드 받게 된다.
이 때, app.js에선 앱에서 필요한 로직 뿐만 아니라 앱을 구동하는 프레임워크 또는 라이브러리의 소스 코드들도 다 포함이 되어져 있다. 추가로 필요한 데이터가 있다면 서버에 요청해서 받아온 데이터를 기반으로 동적으로 HTML을 생성한다. 이런 과정들을 거쳐 최종적으로 사용자에게 어플리케이션을 보여주게 된다.
CSR의 문제점 ⚠️
이런 과정들만 보아도 비교적 사용자가 첫화면을 보기까지 오래 걸린다는 것을 알 수 있다. 그리고 브라우저가 서버에서 받아오는 최초의 HTML은 고작 <div id="root"></div> 태그 하나이기 때문에 검색엔진이 사이트의 내용을 파악하기 어렵다는 점이다.
검색엔진은 서버에 등록된 웹 사이트들을 돌아다니면서 HTML 문서를 분석하고 판단해서 사용자가 검색할 시 해당 웹 사이트를 빠르게 찾을 수 있도록 도와주는데, CSR에서 사용되어지는 HTML 문서는 대부분 텅텅 비어져있기 때문에 검색엔진이 분석하기 어렵다.
- 첫화면을 초기화하는데 오랜 시간이 걸린다 -> 첫화면이 보여지기까지 오래 걸린다.
- 낮은 SEO(Search Engine Optimization) -> 검색엔진 최적화의 어려움, 낮은 검색 순위
언제 필요할까?
- 색인이 비교적 중요하지 않은 경우
- 관리자 페이지나 사용자 경험이 중요한 카카오맵과 같은 웹 앱
SSR(Server Side Rendering)
이러한 CSR의 문제점들 때문에 1990년대 중반에 사용했던 정적 웹 사이트에 영감을 받은 SSR이 도입되게 된다. 이젠 클라이언트에서 모든 렌더링을 처리하는 것과 다르게 웹 사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들게 되고 이렇게 만들어진 파일을 동적으로 제어할 수 있는 약간의 자바스크립트 소스 코드와 함께 클라이언트에게 보내준다.
이렇게 되면 클라이언트는 잘 만들어진 HTML 문서를 받아와서 바로 사용자에게 보여줄 수 있게 된다. 따라서 CSR을 사용했을 때보다 첫번째 페이지의 로딩이 빠르다는 장점이 있다. 또한 모든 콘텐츠가 문서 안에 담겨져 있기 때문에 좀 더 효율적인 SEO를 기대할 수가 있다.
SSR의 문제점 ⚠️
하지만 그렇다고 SSR은 문제점이 없을까? SSR은 정적 웹 사이트에서 발생했던 깜빡임 이슈(blinking issue)가 존재한다. 사용자가 클릭을 하게 되면 전체적인 웹 페이지를 다시 서버에서 받아오는 것과 동일하기 때문에 CSR에 비해 좋지 않은 사용자 경험을 겪을 수 있다. 특히 사용자가 많은 서비스일수록 서버에 과부하가 걸리기 쉽다. 사용자가 클릭할 때마다 서버에 요청해서 서버에 필요한 데이터를 가져온 후 HTML을 만들기 때문이다.
마지막으로 사용자가 웹 사이트를 빠르게 확인할 수는 있다. 하지만 동적으로 데이터를 처리하는 자바스크립트 파일을 아직 다운로드 받지 못해서 클릭해도 반응이 없는식과 같은 사용자와의 상호작용을 하지 못할 수도 있다. 이것이 무슨 말일까?
언제 필요할까?
- 검색 엔진의 색인이 필요한 경우
- 콘텐츠가 주를 이루는 뉴스나 강의 페이지 같은 경우
TTV와 TTI
CSR의 TTV와 TTI
먼저 CSR이 사용자에게 웹 사이트를 보여주기까지의 모든 과정을 시간 순서대로 나열해보자.
- 클라이언트가 사이트에 접속한다
- 서버에게서 index 파일을 받아온다 -> 텅텅 비어진 태그와 JS파일 링크 -> 빈화면
- 해당 웹 앱에 필요한 모든 로직이 담긴 링크된 JS파일 요청 -> 빈화면
- 동적으로 HTML을 생성할 수 있는 웹 앱 로직이 담긴 JS파일을 받아옴 -> 웹 사이트 노출, 상호작용
CSR은 4번부터 웹 사이트가 사용자에게 보여짐과 동시에 사용자와의 상호작용이 가능해진다.
즉 CSR은 TTV(Time To View)와 TTI(Time To Interact)가 동시에 이뤄진다.
SSR의 TTV와 TTI
이제 SSR의 과정을 시간 순서대로 나열해보자.
- 클라이언트가 사이트에 접속한다
- 서버에서 이미 잘 만들어진 index 파일을 받아온다 -> 웹 사이트 노출
- 동적으로 제어할 수 있는 로직이 담긴 링크된 JS파일 요청 -> 웹 사이트 노출
- 사용자와 상호작용이 가능한 JS 파일을 받아옴 -> 웹 사이트 노출, 상호작용
SSR은 2번부터 웹 사이트가 사용자에게 보여지지만 4번부터 사용자와의 상호작용이 가능해진다. 따라서 사용자가 웹 사이트를 볼 수 있는 시간과 상호작용 할 수 있는 공백 시간이 꽤 있는편이다.
즉 SSR은 TTV(Time To View)와 TTI(Time To Interact) 사이의 공백 시간이 존재한다.
어떻게 개선할 수 있을까?
웹 사이트의 성능을 분석할 때 TTV와 TTI도 좋은 중요한 기준치가 될 수 있다.
CSR의 비중이 높은 경우, 최종적으로 번들링해서 클라이언트에게 보내주는 JS파일을 어떻게 하면 효율적으로 분할해서 사용자가 첫화면을 볼 때 필수적인 것들만 보낼 수 있을지 고민해봐야 한다.
SSR의 비중이 높은 경우, 사용자가 보고 상호작용 할 수 있는 이 시간의 차이를 줄일 수 있는 방법에 대해 고민하거나 어떻게 하면 매끄러운 UI/UX를 제공할 수 있을지 고민해봐야 한다.
마무리
결국 어떤 방식이 최고라기보단 상황에 따라 달리 적용하고, TTV와 TTI를 고려해서 조금 더 유연하게 둘의 방식을 섞어서 사용하면 웹 사이트의 성능을 높일 수 있다.
나는 해당 개념에 대해 무지했었고, 이런 방식이 트렌드라서 따라하기 바빴던 것 같다. 그래서 SPA과 같은 앱처럼 동작하는 CSR 웹 사이트들이 마냥 좋은 것인줄 알았고 다른 사이트들은 트렌드에 뒤처진다고 생각했었다. 나의 무지함에서 나온 잘못된 생각이었고 이제는 두 방식의 개념을 알고 차이점을 알게 되었기 때문에 해당 방식을 채택한 이유에 대해서 생각해볼 수 있게 되었다.
참고
서버사이드 렌더링 (개발자라면 상식으로 알고 있어야 하는 개념 정리 ⭐️)
'Web' 카테고리의 다른 글
| 배포 자동화? CI/CD가 무엇일까? (0) | 2021.12.09 |
|---|---|
| Image Lazy Loading 기법으로 웹 성능 최적화하기 (0) | 2021.10.30 |
| HTTP 이해하기 (0) | 2021.09.13 |
| 304 Not Modified 이해하기 (0) | 2021.09.09 |
| 포스트맨(Postman) 사용법과 다운로드(feat. 유튜브 API) (0) | 2021.08.08 |