CSR, SSR, SSG

소밍·2023년 2월 20일
0
post-thumbnail

초창기 웹 렌더링은 클라이언트가 서버에게 요청을 보내면 서버가 해당 요청에 맞는 HTML 문서를 클라이언트에게 전송하는 방식이다.
(MPA : Multi Page Application)
하지만 static한 정보만을 보여주는 웹의 초기 역할을 지나

  • 웹의 성능이 좋아지고,
  • JavaScript 등장에 따라 클라이언트와의 인터랙션이 증가하고,
  • 그에 따라 내려줘야하는 정보의 양이 늘어나면서
    페이지를 이동할 때마다 매번 새로운 정보를 보여줘야하는 서버 부하 문제가 커지게 되었다.
  • 클라이언트 입장에서도 서버에서 매번 HTML을 새로 받아 그리기 때문에
    페이지 깜빡임 현상이 빈번하게 발생한다는 불편함을 겪게 되었다.

JavaScript를 통해 서버와 브라우저가 비동기로 데이터를 주고 받을 수 있는 Ajax 기술이 등장하면서
매번 새로 HTML을 받는 것이 아닌, 필요한 부분의 데이터만 불러와서 동적으로 웹 사이트 화면을 변경할 수 있게 되었다. SPA(Single Page Application)를 구현하게 된것이다. 이 때 SPA를 구현하기 위해 사용하는 렌더링 방식이 CSR이다.

1. CSR (Client Side Rendering)

<body>
    <div id='root'></div>
    <script src='app.js'></script>
</body>

클라이언트가 body 내부에 번들링된 하나의 JavaScript 파일을 서버로부터 다운 받아
동적으로 HTML을 생성해 브라우저에 띄우는 렌더링 방식이다.

장점

초기 로딩 이후, 페이지 일부 변경시 해당하는 데이터만 요청하면 되기 때문에 이후 로딩이 빠르다.
서버 부하가 적다.

단점

HTML body가 비워져있기 때문에 SEO(검색 엔진 최적화) 측면에서 불리하다.
JavaScript 파일에 어플리케이션에 필요한 로직, 프레임워크, 라이브러리의 소스 코드가 포함되어 있기 때문에
→ 로드하는 시간이 오래걸려 사용자가 첫 화면 보는데 시간이 소요된다.

JavaScript 파일을 어떻게 하면 효율적으로 많이 분할하여
사용자가 첫 화면을 보기 위한 시간을 줄일 수 있을지 고민해보면 좋다.

해결 방법

  • code splitting, tree-shaking, chunk 분리를 통해
    JavaScript 번들 크기를 줄여 초기 DOM 생성 속도를 줄이면 초기 로딩 속도를 줄일 수 있다.
  • pre-rendering 을 통해 SEO를 개선할 수 있다.
  • 라이브러리나 웹팩 플러그인을 통해 각 페이지에 대한 HTML 파일을 미리 생성해둔 뒤
    서버에서 요청한 자가 크롤러라면 사전에 렌더링 된 HTML 버전 페이지를 보여주는 방식을 통해 개선할 수 있다.

2. SSR (Server Side Rendering)

웹사이트에 접속하면 '서버'측에서 필요한 데이터를 모두 가져와 HTML파일을 만들고,
잘 만들어진 HTML파일을 동적으로 제어할 수 있는 소스코드와 함께 클라이언트에게 보내주는 렌더링 방식이다.
클라이언트 측에서는 렌더링이 끝난 HTML을 바로 사용자에게 보여줄 수 있다.

장점

서버에서 렌더링이 끝난 HTML을 받아오기 때문에 첫번째 페이지 로딩이 빨라진다.
모든 컨텐츠가 HTML에 담겨있기 때문에 SEO 측면에서 효율적이다.

단점

사용자가 클릭하게 되면 전체적인 웹사이트를 다시 서버에서 받아오는 것과 동일하기 때문에
static site에서 발생했던 화면 깜빡임 (blinking) 이슈가 발생한다.
사용자가 많은 제품일 수록 사용자가 클릭할 때마다 서버에 요청해 서버에서 필요한 데이터를 가지고 와
HTML을 만들어야하므로 서버 과부하가 걸리기 쉽다.
사용자가 빠르게 웹사이트를 확인할 수 있지만, 동적으로 데이터를 처리하는 JavaScript를 아직 다운로드 받지 못해
여기 저기 클릭했지만 반응이 없는 경우가 발생할 수 있다. (* TTV와 TTI간의 차이)

사용자가 보고 인터랙션하는 시간의 공백을 줄이기 위해 어떤 노력을 할 수 있을지,
어떻게 더 매끄러운 UI와 UX를 제공할 수 있을지 고민해보면 좋다

TTV, TTI

TTV - Time to View
TTI - Time To Interact

CSR은 사용자가 웹사이트를 볼 수 있음과 동시에 클릭을 하거나 인터랙션이 가능하다.

SSR은 서버에서 이미 잘 만들어진 인덱스 파일을 받아와 사용자가 웹사이트를 볼 수 있다. 
하지만 JavaScript 파일을 서버에서 받아와야 인터랙션이 가능해지기 때문에 
사용자가 사이트를 볼 수 있는 시간(TTV)과 실제로 인터랙션 할 수 있는 시간(TTI)의 공백이 꽤 긴 편이다.

* 웹사이트의 성능을 분석할 때 TTV와 TTI도 중요한 매트릭으로 사용.

3. SSG (Static Site Generation)

모든 유저에게 항상 동일한 화면이 보이기 때문에 매번 동적으로 생성할 필요가 없을 때 적합한 방식이다.
리액트는 CSR에 특화된 라이브러리지만 Gatsby와 함께 사용하면 리액트로 만든 웹어플리케이션을 정적으로 웹페이지를 미리 생성해두어 서버에 배포해 놓을 수 있다. 이 때 이렇게 만들어둔 웹사이트는 모두 정적인 것은 아니다. 데이터를 서버에서 받아오거나 동적으로 처리해야하는 로직이 있다면 JavaScript 파일을 함께 가지고 있을 수 있기 때문에 동적인 요소도 추가할 수 있다.

단점

수정하거나 웹사이트에 변화가 있으면 매번 다시 빌드해줘야하기 때문에
자주 업데이트 되는 웹사이트인 경우 좋지 못하다.

4. CSR에 SSR이나 SSG를 도입하는 방법

4-1. 프레임워크 없이 도입하는 방법

  • Express.js로 별도의 서버를 직접 운영하는 방법
  • Nest.js - 기본적으로 타입스크립트 지원
    (서버 환경 구성이나 빌드 등의 작업이 생소한 프론트엔드 개발자에게는 복잡하고 헷갈리는 부분이 많다.)

4-2. 프레임 워크 사용하는 방법

  • Next.js (SSR, SSG)
    • CSR과 SSR을 잘 섞어 강력하고 유연하게, 목적에 맞게 사용할 수 있도록 지원한다.
    • 페이지 성격별로 SSR을 사용할 것인지 SSG를 사용할 것인지 미리 정해둘 수 있다.
      (업데이트가 자주 일어나는 렌더링에 적합하다.)
  • Gatsby (SSG)
    • SSG에 최적화된 리액트 기반 정적 페이지 생성 프레임 워크.
    • 서버에서 웹사이트를 빌드할 때 다 만들어 두고 사용자가 요청하면 준비한 걸 바로 보여준다.
    • SSG에 최적화 되어 있긴 하지만 CSR, SSR, lazy loading 등도 지원하고 다양한 플러그인 제공한다.
    • 빌드 시점에 static HTML들을 만들어주기 때문에 페이지가 적고 작은 서비스에 적합한 수단이다.
  • 앵귤러 유니버셜 (앵귤러 프레임워크)
    • 앵귤러에서 SSR 가능하게 해주는 프레임워크.
    • 현재는 앵귤러 자체에 포함되어 있기 때문에 더이상 프레임워크로 보지 않는다.
  • NuxtJS (Vue.js 프레임워크)

→ 이러한 프레임워크를 사용하더라도 일반 SPA, 즉 CSR 개발에 비해 코드 복잡도는 올라가고,
프레임워크 사용으로 인한, 직접 제어할수 없는 블랙박스 영역이 생긴다는 단점 존재한다.

초기 렌더링 방식으로 SSR을 사용하고 
그 이후에는 CSR을 사용하는 앱이나 그 렌더링 방식을 부르는 용어

* Universal Rendering
    - Next.js, NuxtJS, angular universal 등이 이를 지원한다.
* Isomorphic App
    - 서버와 클라이언트에서 동일한 코드가 동작하는 어플리케이션.
    - 클라이언트와 서버가 모두 같은 코드로 돌아가기 때문에 
      예상과는 다른 결과를 마주할 가능성도 있지만 
      초기 로딩 속도와 SEO를 개선하면서도 CSR의 장점을 그대로 가져갈 수 있는 좋은 대안이다.

5. 그럼 CSR, SSR, SSG 중 뭐가 가장 좋은가?

→ 서비스 성격에 따라 다르다

  • 사용자와의 상호작용이 많고 대부분의 페이지가 고객의 개인정보 데이터를 기준으로 구성되는 서비스라면
    검색 포털 상위에 노출되는 것보다 고객의 데이터를 보호하는 것이 더 중요할 수 있다.
    즉, 모든 서비스에 SEO를 고려할 필요는 없다는 것으로 이 경우 CSR 방식이 적합하다.

  • 회사 홈페이지이기 때문에 검색시 상위 노출이 되어야하고, 누구에게나 동일한 내용을 노출하고 있으며,

    • 페이지 데이터가 자주 바뀐다면 SSR 방식이 적합하다.
      (SSR은 요청할 때 즉시 만드니까 데이터가 달라져서 미리 만들기 어려운 페이지에 적합)
    • 페이지 데이터 업데이트 할 일이 거의 없다면 SSG 방식이 적합하다.
      (SSG는 페이지들을 서버에 모두 만들어둔 뒤에 요청시 해당 페이지를 응답하는 것이기 때문에 바뀔일이 거의 없는 페이지에 적합)

  • 사용자에 따라 페이지 내용이 달라지고, 빠른 인터랙션이 중요하며 검색엔진 최적화도 포기할 수 없다면
    유니버셜 렌더링을 고려하는 것이 좋다.



출처 :
드림코딩 - 서버 사이드 렌더링 https://youtu.be/iZ9csAfU5Os
우아한테크 - [10분 테코톡] 신세한탄의 CSR&SSR https://youtu.be/YuqB8D6eCKE

profile
소밍
생각이 길면 용기는 사라진다.
이전 포스트

react-redux의 connect

다음 포스트

CSR, SSR, SSG

0개의 댓글