서버-사이드 렌더링(SSR, Server-Side Rendering) & 클라이언트-사이드 렌더링(CSR, Client-Side Rendering)

jae_s_a·2022년 9월 14일

TIL web

WEB

목록 보기

1/3

학습 주제

SSR(Server-Side Rendering) & MPA(Multi-Page Application)

CSR(Client-Side Rendering) & SPA(Single-Page Application)

MPA(Multi-Page Application)란?

말 그대로, 여러 페이지로 구성된 웹 어플리케이션
사용자의 클릭과 같이 인터렉션이 발생할 때마다 서버로부터 새로운 HTML을 받아와서, 해당 링크로 이동하여 페이지 전체를 새로 렌더링하는 전통적인 웹 페이지 구성 방식
쉽게 말해서, 기존의 웹서비스는 링크(앵커 <a href="#"> )를 클릭하면 해당 페이지로 이동
- 덧붙여서 설명하자면, 앵커 태그에 명시되어 있는 자원(일반적으로 html)을 서버에 요청하고, 응답으로 받은 내용을 브라우저에 표현하게 된다.
  이런식으로 매 페이지마다 서버에 문서(html)을 요청하고 응답받아서 표현하는 방식

<li><a href="index.html">main</a></li>
<li><a href="sub1.html">sub1</a></li>
<li><a href="sub2.html">sub2</a></li>

SPA(Single-Page Application)

하나의 페이지로 구성된 웹 어플리케이션
브라우저에 최초 단 한 번만 페이지 전체(HTML, CSS, JavaScript)를 로드하고, 이후부터는 특정 부분만 Ajax를 통해 서버와 통신해서 데이터를 받아오고 바인딩하는 방식
즉, 첫 요청시 딱 한 페이지만 불러오고 페이지 이동 시 기존 페이지의 내부를 수정해서 보여주는 방식
React, Vue, Angular와 같은 자바스크립트 프레임워크들이 SPA의 방식

밑에 그림처럼 MPA는 새로운 파일을 불러오지만, SPA는 특정 부분만 JSON데이터로 받아오게 된다.

SSR(Server Side Rendering)

SSR 방식은 MPA로 동작
서버로부터 렌더링된 HTML파일을 받아와 페이지를 렌더링 하는 방식

클라이언트가 초기 화면을 로드하기 위해 서버에 요청
서버는 화면에 표시하는데 필요한 데이터를 읽어온 다음, 렌더링 준비를 마친 HTML을 클라이언트에게 우선적으로 전달하고, 클라이언트에게 전달되는 순간 HTML 파일은 렌더링이 되어있기 때문에 사용자는 렌더링된 HTML을 보게 된다.
- 그러나, JS가 읽히기 전이기 때문에 사이트 조작이 불가능하다.
이후에, 클라이언트가 자바스크립트를 다운받는 동안에도 렌더링된 HTML 컨텐츠를 볼 수 있지만 사이트 조작이 불가능하다.
- 이때, 사용자 조작을 기억하고 있다.
브라우저가 JS 다운로드를 마치게 되면, 기억하고 있던 사용자 조작이 실행되게 되고, 웹 페이지는 상호작용 가능한 상태가 된다.

Q. 만약, 세모만 네모로 변경하게 되면 어떻게 되는가? SSR - MPA
A. 이전과 마찬가지로 서버 html 로 화면에 표시하는 데 필요한 완전한 리소스의 응답합니다.
다시 말해, 세모 뿐만 아니라 동그라미, 마름모까지 모두 서버로부터 다시 다운받아 옵니다. 이런 이유로 요청을 보내고 응답을 받으면 새로고침되어 화면이 깜빡인 후에 표시된다.

CSR(Client Side Rendering)

CSR 방식은 SPA로 동작
사용자의 요청에 따라 필요한 부분만 응답 받아 렌더링 하는 방식
Gmail, Twitter, Google 드라이브, Uber, …

클라이언트에서 초기화면을 로드하기 위해 서버에 요청
서버는 화면을 표시하는데 필요한 완전한 리소스의 응답이 와야 볼 수 있다.
- 즉, CSR의 경우에는 HTML, CSS와 모든 JS 파일을 다운받아야 하기 때문에 SSR에 비해 초기 로딩 시간의 더 걸린다.

Q. SSR과 마찬가지로 세모만 네모로 변경하게 되면 어떻게 되는가?
A. 클라이언트는 이전과 같이 서버에 요청하게 되면, 서버는 변경된 부분인 네모와 관련된 리소스만 응답하게 된다.
또한, CSR 방식은 SSR 방식과 다르게 화면이 깜빡이지 않고, 수정된 데이터가 바로 표시됩니다.

SSR (Server-Side Rendering)

장점

검색 엔진 최적화(SEO, Search Engine Optimization) 관점에서 유리하다.
- SEO란 검색엔진이 웹을 크롤링 하면서 페이지에 컨텐츠 색인을 생성하는 과정
- SSR을 채택하는 멀티 페이지 어플리케이션은 화면을 구성하는 각각의 페이지가 있기 때문에 SEO에 유리하다.
  - 모든 데이터가 이미 HTML에 담겨진채로 브라우저에 전달되기 때문에
빠른 초기 로딩
- 서버로부터 화면을 렌더 하기 위한 필수적인 요소를 먼저 가져오기 때문에 모든 요소를 가져오는 클라이언트 사이드 렌더링보다 초기 로딩 속도가 빠르다.

단점

초기 로딩속도가 빠른 만큼 동시에 이것이 치명적인 단점
- TTV(Time To View)와 TTI(Time To Interact)간에 시간 간격이 존재하게 된다.
  즉, 클라이언트가 JS 파일을 모두 다운로드하고 적용하기전까지 사용자가 버튼을 클릭하거나 이동하려고 해도 아무런 반응이 없을 수 있다.
서버측 부하가 증가
- 페이지를 요청할 때마다 서버에서 페이지를 구성하는 모든 리소스를 준비해서 응답하므로 서버의 부담이 증가

CSR

장점

빠른 속도와 서버 부하 감소
- 변경된 부분과 관련된 데이터만 가져오므로 서버사이드 랜더링 보다 빠른 속도를 보인다.
  또한, 변경된 부분만 요청함으로써 서버의 부담을 줄일 수 있다.
사용자 친화적
- 페이지 안에 컨텐츠를 클릭하여 다음 단계로 전환 하는 과정에서 링크가 없기 때문에 깜빡임 없이 부드러운 이동을 경험할 수 있다.

단점

캐시하기 어렵다
SEO는 불리하다는 단점이 있다.
- CSR을 채택한 싱글 페이지 어플리케이션은 자바스크립트를 사용하여 사용자와 상호 작용 후에 페이지 내용을 로드하기 때문에 웹 크롤러 가 페이지를 색인화 하려고 하면 내용의 빈 페이지 처럼 보이게 된다.
- 구글의 크롤러 봇은 자바 스크립트를 실행할 줄 압니다. 그래서 CSR 웹 크롤링도 가능하다고 하는데요. 하지만 아직 완벽한 단계가 아니기도 하고 구글 측에서도 여전히 크롤러봇이 JS를 실행하기전에 더욱 빠르게 크롤링을 할 수 있도록 또, 자바 스크립트를 실행할 수 없는 다른 크롤러 봇들을 위해서 SSR을 고려해 보라는 말을 덧붙이고 있다.

<html>
  <head>
    <title>Single Page Application</title>
    <link rel="stylesheet" href="app.css" type="text/css">
  </head>
  <body>
    <div id="app"></div>
    <script src="app.js"></script>
  </body>
</html>

초기 로딩 속도가 느리다.
- 클라이언트 사이드 렌더링은 초기에 모든 js 파일을 다운받아 와야 하기 때문에 초기 로딩 시간이 오래걸린다.

Q> 초기 로딩 속도가 아닌 첫 페이지를 로딩한 후 사이트의 다른 곳으로 이동하는 식의 방식으로는(이하 나머지 로딩 시간)은 어떤가?
A> CSR 방식은 첫 페이지를 로딩할 때 이미 나머지 부분을 구성하는 코드를 받아왔기 때문에 첫 페이지를 로딩한 과정을 다시 실행하는 SSR 방식에 비해 더 빠르다.