MPA (with SSR)와 SPA (with CSR) 이해/장단점/동작과정

Notice

Recent Posts

Recent Comments

Link

« 2024/09 »
일	월	화	수	목	금	토
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Tags more

Archives

Today

Total

관리 메뉴

月亮

MPA (with SSR)와 SPA (with CSR) 이해/장단점/동작과정 본문

Next.js

MPA (with SSR)와 SPA (with CSR) 이해/장단점/동작과정

듀네 2023. 2. 5. 21:34

MPA

MPA(Multiple Page Application)는 여러 개(Single)의 Page로 구성된 Application
사용자의 클릭과 같이 인터렉션이 발생할 때마다 해당 링크로 이동하여 앱이 다시 새로고침되는 전통적인 방식(Traditional Page Lifecycle)으로 작동
기본 랜더링 방식 : SSR

MPA with SSR
서버에서 랜더링을 진행하고, 연산, 분석이 완료된 HTML 파일을 브라우저에게 전달하고 출력하는 방식

1. 클라이언트가 서버에게 Initial Request(GET Request)(초기화면-main page-을 로드하기 위해)를 하면 서버로부터 완전하게 만들어진 html파일을 받아와 페이지전체를 렌더링

2. 'page reload'를 요청하면(post 방식으로), 다시 HTML을 받는다.

- 새로운 페이지를 요청할 때마다 서버에서 렌더링된 정적 리소스(HTML, CSS, JavaScript)가 다운로드된다.
- 페이지 이동하거나 새로고침하면 전체 페이지를 다시 렌더링
- 요소일부 변경 시, 변경하는 요소뿐만 아니라 변경하지 않는 전체 요소들도 모조리 서버로부터 다시 다운로드

SSR 세부 동작 과정

1. 사용자가 웹사이트 방문

2. 브라우저가 콘텐츠 요청

3. 서버가 렌더링 준비를 마친 HTML, JS code를 전달함

4. 1). 브라우저는 HTML 렌더 (일단 화면은 보인다! => TTV(Time To View)와 TTI(Time To Interact) 간의 시간 간격이 존재)

5. 2). JS code 다운로드

6. 3). HTML에 JS 로직 연결 (수화 => 이 과정까지 와야 사용자가 인터렉션 가능)

- 사용자가 네비게이션의 링크를 클릭하여 페이지를 이동했을 때 해당 페이지의 html 파일을 다운로드하고 이어서 javascript 파일을 다운로드하는 일련의 과정이 반복된다!

👍 장점

1. SEO(검색엔진이 웹을 크롤링하면서 페이지에 콘텐츠 색인하는 과정)에 좋다.

1). 브라우저에서 JavaScript 코드가 동작하기 전에도 모든 데이터가 이미 HTML에 담겨진 채로 브라우저에 전달되기 때문에 `검색엔진 최적화에 유리`하다 (CSR은 서버에서 빈 뼈대 HTML와 JS 링크만 전달하기 때문에 크롤러봇이 읽을 게 없다)

2). 화면을 구성하는 각각의 페이지가 있기 때문에 유리

2. 초기 로딩 속도가 빠르다 - HTML렌더 때문에

1). js코드를 다운로드 받기 실행하기 전에 사용자가 화면을 볼 수 있다. `초기 구동속도가 빠르다`

(서버로부터 화면을 렌더 하기 위한 필수적인 요소를 먼저 가져 오기 때문에)

SSR의 경우에는 먼저 인덱스 페이지에 표시되어야 할 html 파일을 먼저 브라우저가 다운 받는다. 그러고 나서 javascript 파일도 다운로드한다. javascript 파일을 다운로드하는 동안에 이미 html 파일의 렌더링을 시작하기 때문에 웹페이지 표시가 빠르다. 그러나 컴퓨터의 속도가 느리다면 처음에 javascript가 다 다운이 받아지지 않아서 기능이 동작하지 않을 수도 있다.

js파일을 다운받는 중에는 사용자가 버튼을 클릭하거나 이동하려 해도 아무 반응이 없다. 인터렉션 가능한 페이지처럼 보이지만 그저 내용과 스타일이 입혀진 껍데기에 불가하고 1). 실제로 클라이언트 측 js 실행되고 2). 이벤트 핸들러가 첨부되어서 JS로직이 모두 연결될 때 까지 사용자의 입력에 응답할 수 없다

`TTV(Time To View)와 TTI(Time To Interact) 간의 시간 간격이 존재한다는 단점` 이 있다
(CSR은 js가 동적으로 dom을 생성하기 때문에 수화 과정(HTML-Js완전 연결)이 끝난 후라 사용자가 보는 시점과 이용할 수 있는 시점이 동일하다)

3). Static sites에 좋다.

👎 단점
1. 서버에서 전체 앱을 미리 렌더링 하기 때문에 컴포넌트 로딩이 오래 걸리면 유저는 빈 화면을 볼 수도 있다.
2. 서버에 매번 요청하기 때문에 서버 부하가 크다. (view 변경 시 요청-페이지를 요청할 때마다 서버에서 페이지를 구성하는 모든 리소스를 준비해서 응답)

3. 페이지 이동시 불필요한 템플릿도 중복해서 로딩 (성능)
4. 페이지를 요청할 때마다 새로고침되어 UX가 다소 떨어진다.('깜빡'인다)

5. 모바일 앱 개발 시 추가적인 백엔드 작업 필요 (생산성) 개발이 복잡해질 수 있다.

(프런트엔드와 백엔드가 강하게 결합되어 있다.

프런트엔드에서 요청을 보내면, 서버 측에서 HTML 파일을 완성하고 완성된 HTML 파일을 응답하는 식이기 때문에, 백엔드의 응답이 없으면 사실상 아무것도 보여줄 수 없게 된다)

SPA

한 개(Single)의 Page로 구성된 Application이다.
SPA는 웹 애플리케이션에 필요한 모든 정적 리소스(HTML, CSS, JavaScript)를 최초 한 번에 다운로드한다.
그 이후 새로운 페이지 요청이 있을 때, 페이지 갱신에 필요한 데이터만 전달받아서 페이지를 갱신한다.(최초에 한번 서버에서 응답받고 이후는 변경된 사항(데이터)을 받아올 때만 서버와 통신한다.)
즉, 첫 요청 시 딱 한 페이지만 불러오고 페이지 이동 시 기존 페이지의 내부를 수정해서 보여주는 방식이다.
클라이언트 관점에서 말하자면 최초 페이지를 로딩한 시점부터는 페이지 리로딩 없이 필요한 부분만 서버로부터 받아서 화면을 갱신하는 것이다.
즉, 브라우저가 javascript 코드를 가지고 있지 않거나, 요청 중인 상태라면 UI를 구성할 수 없고, 유저는 빈 화면을 보게 된다. 코드가 실행되기 전까지는 유저 화면에 아무것도 보이지 않는 것이다. 이렇게 클라이언트 측에서 UI를 빌드하는 것 을 CSR 방식이라 한다.
기본 랜더링 : CSR

SPA with CSR
사용자의 요청에 따라 필요한 부분만 응답받아 랜더링 하는 방식

JavaScript를 사용하여 브라우저에서 페이지를 직접 렌더링 하는 것을 말한다.

미리 완성된 페이지를 그대로 보여주는 게 아닌 Client 즉, 브라우저에서 직접 html과 JavaScript을 조합해서 페이지를 렌더링 하는 것을 말한다.

1. 클라이언트가 서버에게 Initial Request(초기화면을 요청하기 위해)를 하면 웹페이지를 구성하는 HTML+CSS+JavaScript 같은 리소스를 한 번에 다 내려받는다. (CSR는 SSR과 달리 모든 JS 파일을 다운로드하여야 하기 때문에 초기 로딩 시간이 더 오래 걸린다)
2. 다만, 추가적인 요청은 AJAX를 통해 필요한 데이터만 JSON, XML 형식으로 받아서 업데이트할 뿐이다!(서버는 변경된 부분인 요소가 관련된 리소스만 응답 - 화면이 깜빡이지 않고 바로 수정된 데이터가 표시됨)

💁🏻‍♀️ AJAX?
AJAX는 JavaScript의 라이브러리 중 하나로, Asynchronous Javascript And Xml(비동기식 자바스크립트와 xml)의 약자이다.
브라우저가 가지고 있는 XMLHttpRequest 객체를 이용해서 전체 페이지를 새로 고치지 않고도 페이지의 일부만을 위한 데이터를 로드하는 기법인데,
말이 너무 어려우니까 쉽게 말하면, HTML 페이지 전체가 아닌 일부분만 갱신할 수 있도록 필요한 데이터만 받아서 JavaScript를 통해 필요한 부분만 갱신하는 방법이다!

CSR 세부 동작과정

1. 사용자가 웹사이트 방문

2. 브라우저가 콘텐츠 요청

3. 1). 서버가 빈 뼈대 HTML와 연결된 JS 링크 전달 (react의 index.html페이지 생각하면 됨-html코드+js 스크립트 링크)
4. 2). 브라우저가 JS 다운로드

5. 3). 동적 DOM 생성 (빈뼈대인 HTML에 JS코드 동작하며 화면구성, 그전까지는 빈 화면만 보임)

- 사용자 입장에서는 페이지 1에서 페이지 2로 부드럽게 이동한 것 같은 느낌을 받는데, 사실 페이지는 이동하지 않았다. 하나의 HTML 파일에 JavaScript를 이용해서 페이지 2에 해당하는 웹 페이지의 DOM 구조만 바꾸고 리렌더링 되는 것!

👍 장점

- 빠른 속도 및 서버 부하 감소 : 변경된 부분과 관련된 데이터만 가져와서 SSR 보다 빠른 속도, 변경된 부분만 요청해서 서버 부담 낮춤 - 초기로딩 이후에 페이지 일부를 변경할 때는 서버에 해당 데이터만 요청하면 되기 때문에

(서버 요청 횟수가 적어 서버에 부담이 적다)

(일단 로드가 되고 나면 사이트 내에서 돌아다닐 때 로드되는 과정이 없어지므로 사용성이 좋아진다.)

(페이스북과 같은 대형 플랫폼들의 화면이 많은 사진과 정보가 있음에도 페이지를 이동할 때 화면 깜박임이 없는 이유는 바로 이 때문이다)

서버가 빈뼈대와 링크만 넘겨주는 역할만 수행하면 되기 때문에 서버부하 적음
서버에 요청할 것이 거의 없어 서버 부담이 적다. (data 필요할 때만 요청) (필요한 데이터만 백엔드에서 가져와 서버 부하가 덜하다.)
클라이언트 측에서 연산, 라우팅 등을 모두 직접 처리하기 때문에 반응속도 빠름

- 사용자 친화적/자연스러운 사용자 경험 (UX) : 페이지 갱신에 필요한 데이터만을 전달받고, 갱신하기 때문에 사용자 입장에서 페이지가 굉장히 부드럽게 이동하는 것처럼 보인다.

- 필요한 리소스만 부분적으로 로딩 (성능) : SPA의 Application은 서버에게 정적리소스를 한 번만 요청한다. 그리고 받은 데이터는 전부 저장해 놓는다. (캐시=Cache)

- 서버의 템플릿 연산을 클라이언트로 분산 (성능)

- 컴포넌트별 개발 용이 (생산성)

- 모바일 앱 개발을 염두에 둔다면 동일한 API를 사용하도록 설계 가능 (생산성) Web Applications에 좋다.

👎 단점

일반적인 SPA 앱을 검색로봇 입장에서 보면 모든 페이지의 소스가 아래와 같이 보이다.
초기 HTML 파일이 비어있기 때문에 검색엔진이 색인을 할 만한 콘텐츠가 존재하지 않는 것이다.

<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>

- SEO에 불리 : 자바스크립트를 사용하여 사용자와 상호작용 후에 페이지 내용을 로드하기 때문에 웹크롤러가 페이지를 색인화 하려고 하면 내용의 빈 페이지처럼 보이게 된다 (브라우저의 웹 크롤러는 html을 읽어서 검색 가능한 색인을 만들어 내는데 CSR의 경우에는 텅 빈 빈 뼈대 HTML만 있어서 SEO에 불리하다.(검색 사이트에 노출이 안된다))

- 처음 웹페이지를 구성하는데 필요한 HTML+CSS+JavaScript 같은 정적 리소스를 한 번에 다 내려받기 때문에

- JavaScript 파일을 번들링 해서 한 번에 받기 때문에 초기 구동 속도가 느리다. 맨 처음 url 요청에 웹문서가 가지고 있는 모든 정보, 링크페이지까지도 한 번에 다 받아온다. (Webpack의 code splitting, Chunking으로 해결 가능) - 브라우저가 js파일을 다운로드하고 동적으로 dom을 생성하는 시간을 기다려야 하기 때문에 (js파일 다운로드로 초기 진입속도가 느릴 수 있다.)

- 검색엔진최적화(SEO)가 어려움 (SSR로 해결 가능)

- 보안 이슈 (프런트엔드에 비즈니스 로직 최소화) : SSR에서는 사용자에 대한 정보를 서버 측에서 세션으로 관리를 하지만 CSR 방식에서는 클라이언트 측의 쿠키 말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않다.(쿠키나 localstorage에서 사용자에 대한 정보를 저장해야 하기 때문에 XSS 공격에 취약하다.)

- 외부 라이브러리가 필요한 경우가 많다.