먼저 짚기: SPA와 MPA
SPA란 Single Page Application의 약자로,
하나의 페이지로 구성된 웹 어플리케이션을 말한다.
보통 자바스크립트로 앱을 개발한다고 하면
React, Angular, Vue 등의 프레임워크를 사용하여 SPA로 개발하게 된다.
SPA로 만들어진 사이트의 형태는 주로
고정되어 있는 헤더에서 메뉴탭 중 하나를 선택하면
하단의 메인 컨텐츠 부분만 샥샥 바뀌는 모습이다. (React)
원하는 부분만 클라이언트에서 동적으로 갈아끼우기 때문에
새로고침으로 인한 화면 깜박임이 없다.
반면, MPA는 Multi Page Application의 약자로
탭을 이동할 때마다 서버로부터 새로운 HTML을 받아와서
페이지 전체를 새로 렌더링하는 방식으로 화면 깜박임이 발생한다.
또한 전통적인 웹 페이지의 구성 방식이기 때문에,
자바스크립트로 비동기적 요청을 보낼 수 있는 AJAX가 등장한 후로는
SPA가 대세가 되었다.
CSR와 SSR
본론으로 들어가서 CSR과 SSR이 위에서 살펴본 SPA, MPA와 어떤 연관이 있는지 알아보자.
일반적인 렌더링 방식으로 SPA에서는 CSR을, MPA에서는 SSR을 사용한다.
SPA에서는 웹 어플리케이션에 필요한 정적 리소스를
초반 한번에 모두 다운로드하고,
이후 새로운 페이지 요청이 있을 때마다 필요한 데이터만 전달 받아서
클라이언트에서 페이지를 갱신하기 때문에
자연스럽게 CSR을 렌더링 방식으로 사용하게 된다.
MPA는 새로운 요청이 있을 때마다
서버에서 이미 렌더링된 정적 리소스를 받아오기 때문에
자연스럽게 SSR을 렌더링 방식으로 사용하게 된다.
💁♀️ 잠깐!
위와 같은 이유로 SPA === CSR,
또는 MPA === SSR로 오해할 수 있지만,
SPA와 MPA는 렌더링하는 페이지가 몇 개인지가 기준인 반면에
CSR과 SSR은 렌더링을 어디에서 하는지가 기준이라는 큰 차이점이 있다.
CSR의 동작과정과 특징
동작과정
- 유저가 방문하고 브라우저가 서버에 컨텐츠를 요청한다.
- 서버가 빈 뼈대만 있는 HTML을 응답으로 보내준다.
- 브라우저는 서버와 연결된 JS 링크를 통해 서버로부터 JS 파일을 받아서 동적으로 DOM을 생성한다.
특징
- 브라우저가 JS 파일을 다운받고 DOM을 생성하는 시간을 기다려야 해서 초기 로딩 속도가 느리다.
하지만 초기 로딩 이후에는 서버에 필요한 데이터만 요청하여 동적으로 페이지 일부만 리렌더링하기 때문에 이후의 구동 속도는 빠르다. - 또한, 초기 로딩 후에는 클라이언트 쪽에서 라우팅이나 연산을 모두 직접 처리하기 때문에 반응속도가 빨라 UX(사용자 경험)이 우수하다.
- 서버는 빈 HTML을 내려주는 역할만 하면 되기 때문에 서버 측의 부하가 적다.
CSR에서의 검색엔진최적화(SEO)
브라우저의 웹 크롤러는 초기 로딩 시의 HTML을 읽어서 검색 가능한 색인을 만들어낸다.
그런데 CSR 방식에서는 웹 크롤러가 보는 초기 HTML이 비어있는 상태이므로 검색 엔진이 색인을 할 만한 정보가 없다.
=> 따라서 CSR 방식은 검색 엔진 최적화(SEO)에는 불리하다.
구글봇의 경우, HTML 외에 JS 파일도 읽을 수 있어서
CSR 방식일 때도 웹 크롤링을 해내긴 하지만, 완벽하지는 않다고 한다.
또한, JS를 읽을 줄 모르는 나머지 브라우저 크롤러들도 있으므로
CSR만으로는 주로 SEO를 챙기기 힘들다고 보여진다.
SSR의 동작과정과 특징
동작과정
- 유저가 브라우저를 방문하고 브라우저가 서버에게 컨텐츠를 요청한다.
- 서버에서는 요청을 받자마자 즉시 필요한 데이터들을 넣어 HTML을 구성하고, 만들어진 HTML과 JS 코드를 브라우저에 넘긴다.
- 브라우저에서는 전달받은 HTML을 띄운 뒤 JS 코드를 다운로드하여 HTML에 JS 로직을 연결시켜서 구동한다.
특징
- 모든 데이터가 HTML에 담겨진 채로 브라우저에 전송되기 때문에
크롤러 봇이 초기 HTML에서 색인에 필요한 정보를 얻을 수 있어 검색 엔진 최적화(SEO)에 유리하다. - 초기 구동 속도가 빨라 JS 코드가 실행되기 전에도 사용자가 HTML을 통해 화면에서 뭔가를 볼 수 있다.
단점
- 매번 새로운 HTML을 서버로부터 받아오는 과정에서 전환 시마다 화면 깜빡임이 발생한다.
- 초기 로딩 시 화면은 눈에 보이지만, 버튼 클릭과 같은 인터랙션은 불가능해서 이 부분에서 사용자가 불편함을 느낄 수 있다.
처음에 로딩되는 HTML은 JS 로직이 연결되기 전이어서 그저 내용과 스타일만 입혀진 껍데기에 불과하기 때문에 사용자 인터랙션이 불가능하다.
이러한 현상을 'TTV(Time To View)와 TTI(Time To Interact) 사이에 시간 간격이 존재'한다고 말한다.
CSR 방식에서의 HTML은 JS가 모두 연결된 상태에서 렌더링되므로, 사용자가 보는 시점인 TTV와 이용할 수 있는 시점인 TTI가 동일하다.
CSR과 SSR의 장단점
CSR 단점 보완법
-
초기 로딩 속도 개선
* 자바스크립트 번들의 크기를 줄여서 초기 DOM 생성 속도를 높인다. -
검색 엔진 최적화(SEO) 개선
* Pre-rendering 방식을 사용한다.Pre-rendering 방식
웹 라이브러리나 웹팩 플러그인을 통해서 각 페이지에 대한 HTML 파일을 미리 생성해두고, 만약 서버에서 요청하는 작업이 '크롤링'이라면 크롤링에 필요한 파일인 사전 렌더링된 HTML을 보여주는 방식
SSG
SSG는 Static Site Generation의 약자로
정적 페이지 렌더링을 뜻하며, Static Rendering이라고도 한다.
서버에서 렌더링을 하지만 서버 사이드 렌더링(SSR)과는 차이가 있다.
=> 서버 사이드 렌더링은 HTML 파일을 요청을 받은 직후 생성하는 반면,
SSG는 HTML 파일을 미리 다 만들어 놓은 뒤 요청이 왔을 때 렌더링을 한다.
이러한 특징 때문에
서버 사이드 렌더링은 데이터가 매번 달라져서 미리 만들어두기 어려운 페이지에 적합하고, SSG는 바뀔 일이 거의 없는, 캐싱해두면 좋은 페이지에 적합하다.
CSR에 SSR/SSG 도입하기
1. 프레임워크 없이
- express로 별도의 서버를 직접 운영
- typescript 사용 시 typescript를 지원하는 nest.js를 사용할 수도 있음
=> 서버 환경 구성이나 빌드 작업이 생소한 프론트엔드 개발자들에겐 복잡한 작업일 수 있음
2. 프레임워크 써서 => 보다 쉽게 SSR/SSG 적용 가능
- Next.js - 페이지 별로 SSR, SSG 선택 가능
- Gatsby.js
* SSG에 최적화된 리액트 기반 정적 페이지 생성 프레임워크, CSR/SSR/lazy loading 등 지원, 다양한 플러그인 제공- 빌드 시점에 static HTML들을 만들어주는 것이기 때문에 페이지가 적고 작은 규모의 서비스에 적합
- Nuxt.js - Vue를 위한 프레임워크. Next.js에 영감을 받아서 만들어짐
- Angular Universal - Angular에서 SSR을 가능하게 해줌
(원래 프레임워크로 시작했지만 앵귤러 4부터는 앵귤러 자체의 코어 모듈에 포함 => 엄밀히 말하면 더 이상 프레임워크가 아님)
이러한 프레임워크들을 사용하면 SSR/SSG 도입을 훨씬 편하게 만들어주지만
일반 SPA(CSR)에 비해 코드 복잡도가 올라가고 개발자가 직접 제어할 수 없는 블랙박스 영역이 존재하게 된다. (근데 이건 프레임워크를 사용하면 당연히 감수하게 되는 부분)
Isomorphic App & Universal Rendering
Isomorphic App
초기 렌더링 방식으로 SSR을 사용하고, 그 이후에는 CSR을 사용하는 앱
Universal Rendering
이렇게 SSR과 CSR을 혼용해서 사용하는 렌더링 방식
단점
클라이언트와 서버가 모두 동일한(isomorphic) 코드로 돌아가기 때문에 예상과는 다른 결과를 마주할 가능성이 있다. (예: 'window is not defined', 'document is not defined', 'window is not available' 등)
장점
CSR의 단점인 초기 로딩속도를 보완하고 SEO를 개선하면서도, 이후 구동속도 빠름, TTV와 TTI 동일, 전환 시 화면 깜박임 없음, 서버에 부하 적음 등의 CSR의 장점은 그대로 가져갈 수 있는 좋은 대안이기 때문에 최근에 많이 사용되고 있는 추세이다.
그럼 CSR과 SSR 중에 무엇을 써야 할까?
둘 중에 무엇을 선택할지는 서비스의 성격에 따라 다르다.
-
사용자와 상호작용이 많거나, 대부분의 내용이 고객의 개인정보로 구성된 경우에는 검색 포털 상위에 노출되는 것보다는 고객의 정보를 보호하는 게 더 중요하므로 이런 경우에는 CSR이 더 적합하다.
-
반면에 회사의 메인 사이트여서 상위 노출이 필요하거나, 권한 구분 없이 누구에게나 노출 가능한 페이지라면 SSR이 더 적합할 수 있다.
이 중에서도 사이트 업데이트가 자주 있다면 서버 사이드 렌더링(SSR)이 좋고, 내용의 업데이트가 거의 없다면 SSG가 더 낫다.
- 만약 사용자에 따라 페이지 내용이 달라져야 하고, 사용자와의 빠른 인터랙션도 중요하다면(즉, 화면 깜빡임이 허용이 안 된다면) + 검색 포털 상위 노출까지 원한다면 CSR + SSR 혼용한 Universal Rendering 방식을 사용해야 할 것이다.
참고영상
