CSR / SSR, SPA / MPA, PWA

🍉effy·2022년 4월 12일

CSR(Client Side Rendering) vs SSR(Server Side Rendering)

렌더링(Rendering) 방식은 CSR(Client Side Rendering) 과 SSR(Server Side Rendering) 으로 나뉘게 된다.

<html>
  <head>
    <title>Title</title>
  </head>
  <body>
    <div id="app"></div>
  </body>
</html>

body 안에 div 하나만 존재한다. 이렇게 뼈대만 받고, 다양하게 존재하는 태그들은 html 파일과 함께 다운받은 js 파일의 로직을 통해서 동적으로 태그나 스타일들을 DOM 에 더해서 그린다.
이렇게 뼈대만 받고 브라우저 (client) 에서 동적으로 DOM 을 그리게 되면 CSR 이다.

<html>
  <head>
    <title>Title</title>
  </head>
  <body>
    <h1>Hello World!</h1>
    <p>이것이 최종적으로 화면에서 보고 있는 내용입니다.</p>
  </body>
</html>

최종적으로 보여지는 html 예시. 이렇게 이미 다 그려진 DOM 을 받게 되면 SSR 이다.

CSR의 과정

1️⃣ 서버가 브라우저에게 응답을 보낸다
2️⃣ 브라우저는 JS 파일을 다운받고 실행한다
3️⃣ JS 파일을 실행하면서 DOM 에 내용을 추가하면서 그리게 된다

CSR 특징

초기에 JS 를 읽기 때문에 판단하고 그리는 작업을 하는 동안 딜레이가 생기게 된다.
반면에 이후 작업에 있어서는 서버의 의존도 없이 클라이언트 혼자 그릴 수 있으므로, 빠른 화면 전환이나 인터랙션 (interaction) 이 가능하다.
index.html 에 단순히 뼈대만 있기 때문에, 검색 엔진의 봇들이 크롤링 할 때 아무 내용이 없어서 SEO에 취약하다.

SSR의 과정

1️⃣ 서버가 브라우저에게 HTML 응답, 렌더링 하기 위한 준비가 되었다고 보낸다
2️⃣ 브라우저는 페이지를 렌더링 하고, 페이지가 보여지면 브라우저는 JS 파일을 다운받는다
3️⃣ 파일을 실행하고 페이지 상호작용이 가능

SSR 특징

HTML, CSS, JS 를 직접 올리는 것이 아니라 해당 파일들을 만들어 낼 수 있는 로직을 올리고 서버에서 해당 로직을 실행해서 최종적으로 HTML, CSS, JS 를 만들어 브라우저에 전달한다.
만들어진 HTML 파일에는 이미 DOM 이 구성되어 있다.
브라우저에서 보는 파일을 올리는 것이 아닌, 브라우저에서 보는 파일을 만들어 낼 수 있는 로직을 포함한 파일을 서버에 올려서 해당 파일을 만들어 내는 것과 같다
이미 DOM 이 다 구성된 파일을 브라우저가 받기 때문에 바로 그릴 수 있어 초기 구동 속도가 빠르다
DOM 에 이미 내용이 다 차있기 때문에 검색 엔진들이 정보를 수집할 때 정확한 정보를 가져갈 수 있어 SEO 에 좋다.

CSR vs SSR

CSR은 SEO에 취약할까?

CSR 이 SEO 에 취약한 것은 사실.

하지만 그 전에 서비스 전체가 SEO 가 필요한 가?를 고민해봐야 한다. 예를 들어 고객의 데이터를 보호해야 하는 서비스를 제공한다면 데이터 보호를 위해 SEO가 일어나지 않게끔 해야 한다.
공개되어야 하는 퍼블릭 데이터만 SEO 가 필요할 뿐이지, 모든 데이터가 SEO 가 필요한 것은 아니다.

비용 문제

CSR 의 경우 S3 같은 단순 스토리지에 올리고 전면에 Cloud Front 로 구성하여 캐싱과 레이턴시를 줄여 트래픽 비용만 지불한다

SSR 의 경우 매번 서버에서 로직을 실행하는 비용을 지불해야 한다.

🧐 단순 비교 보다는...

CSR 과 SSR 을 단순 비교하여 어느 것이 더 좋다라기보다는, 프로젝트나 서비스 구성에 맞는 방법을 사용해야 한다.
고객의 데이터를 보호해야 할 경우나 비용에 민감할 경우 CSR 을 택할 수 있고, 정적 콘텐츠와 퍼블릭 데이터가 많은 경우에는 SSR 을 택할 수 있다.
두 방법을 섞어서 구성해야 하는 경우도.

SPA(Single Page Application) vs MPA(Multi Page Application)

사용하는 프레임워크나 아키텍처에 따라서 SPA, MPA 가 정해진다.
JS 기반 프레임워크를 쓰면 기본적으로 HTML, CSS, JS 파일이 각 하나씩 나오기 때문에 SPA 가 되면서 CSR 이 되는 것이고, 이를 SSR 로 구현하면 페이지 별로 렌더링을 따로 하기 때문에 MPA 가 된다.
SPA 와 MPA 의 차이에서 화면이 한번 깜빡이는 것 에 중점을 둘 수 있다.
MPA 는 페이지를 새로 로드하기 때문에 화면 깜빡임 현상을 막을 수 없다. SPA 는 이미 로드한 페이지에서 DOM 의 내용만 교체하기 때문에 깜빡임이 보이지 않는다.
모바일의 경우 적은 트래픽, 빠른 인터렉션이 중요하기 때문에 SPA 와 잘 맞는다.
초기 로딩은 살짝 느릴 수 있으나, 모바일 브라우저도 결국은 자체적으로 캐싱하기 때문에 이후에 네트워크 트래픽의 소모가 적고 PWA 를 적용하면 오프라인 상태에서도 인터렉션이 가능하다.

SPA 란?

SPA 는 기본적으로 단일 페이지로 구성.

기존의 SSR 와 비교할 때, 배포가 간단하며 네이티브 앱과 유사한 사용자 경험을 제공할 수 있다는 장점이 있다

모든 정적인 리소스를 최초 접근 시 단 한번만 다운로드.

이후 새로운 페이지 요청 시, 페이지 갱신에 필요한 데이터만을 JSON으로 전달받아 페이지를 갱신하므로 전체적인 트래픽을 감소시킬 수 있다. 전체 페이지를 다시 렌더링하지 않고 변경되는 부분만을 갱신하므로 새로 고침이 발생하지 않아 네이티브 앱과 유사한 사용자 경험을 제공할 수 있다.

SPA는 왜 쓸까?

사용자 경험(UX) 향상을 위해.

SPA 의 단점

1. SEO(검색엔진 최적화) 문제

SPA 로 빌드된 결과물을 보면, <body></body> 안은 텅 비어있고, javascript 가 body 를 바꾸기 때문에 검색엔진은 이 사이트를 텅 비어있는 사이트 로 인식하게 된다.
이는 검색엔진이 크롤링 할 때 javascript 를 실행하지 않고 긁어가기 때문에 생기는 문제이다.
(구글 제외)
MPA 의 경우 이미 완성된 형태의 템플릿을 서버로부터 전달받기 때문에 검색 엔진이 페이지를 크롤링하기에 적합

초기 구동 속도

SPA는 최초 접속 시 사이트 구성과 관련된 모든 리소스를 한번에 받아오기 때문에 초기 구동 속도가 상대적으로 느리다.
하나의 HTML 파일을 제외하고 모두 javascript 파일로 이루어지기 때문에 파일 자체 또한 무겁다.

화면이 변하는 모습

SPA는 데이터를 별도로 요청하고 받아와서 화면을 구성하기 때문에 설계에 따라 화면이 변하는 모습이 사용자에게 노출될 가능성이 있다.

SPA 의 단점을 극복할 수 있는 방법

lazy-loading

최초 접속 시 모든 리소스를 가져오기 때문에 느려지니까, 처음에 모든 리소스를 받아오는 것이 아니라 특정 URL 에 진입할 때 그에 해당하는 부분만을 받아올 수 있도록 하는 것

pre-rendering

페이지 이동 시 데이터 전송이 필요한 경우. SPA 에서는 데이터가 없는 화면이 먼저 표시된 후에 비동기 요청을 통해 데이터를 서버로부터 받아온 후, 화면을 재구성한다.
이런 경우 spinner 등으로 화면이 로드되고 있다는 사실을 보여주기도 한다.

스켈레톤 UI. 이미지 등 컨텐츠가 로딩 중 일 때 보여주는 골격 화면을 그려주기도 한다.

PWA(Progressive Web App)

프로그래시브 웹앱. 웹과 네이티브 앱의 기능을 모두 갖춘 형태.
웹처럼 URL로 접근하여 애플 스토어나 구글 스토어를 거치지 않고 모바일 디바이스 홈 화면에 바로 설치하여 사용이 가능하다.

📝 요약

서비스 특성상 고객 정보를 보호해야 하고 빠른 인터렉션이 필요하다면 기본적으로 웹은 SPA/CSR 을 사용

정적인 홈페이지나 퍼블릭 데이터로 SEO가 필요한 부분에서 SSR 을 이용

모바일은 SPA/PWA 형태를 패키징

출처 https://poiemaweb.com/js-spa

🍉effy

Je vais l'essayer

이전 포스트

[JS] - prototype

다음 포스트