HTTP
SPA vs MPA
MPA란?
- 여러 개(Multiple)의 페이지로 구성된 애플리케이션입니다. (Multiple Page Application)
- 서버 사이드 렌더링(SSR) 방식으로 화면을 그립니다.
- 링크를 통해 페이지를 이동하는 전통적인 방식입니다.
- 페이지를 이동하거나 새로고침하면 전체 페이지를 다시 렌더링합니다.
장점
-
SEO(검색엔진 최적화)에 유리합니다. 웹 크롤러가 페이지를 읽는 방식과 같아서 검색엔진에 잘 노출됩니다.
-
첫 로딩이 SPA보다 빠릅니다. 서버에서 미리 렌더링한 화면을 받아오기 때문입니다. 다만 JavaScript 파일을 모두 내려받아 적용하기 전까지는 기능이 동작하지 않습니다.
단점
- 페이지를 이동할 때 화면이 깜빡입니다. (UX) 새 페이지를 요청할 때마다 전체 페이지를 다시 렌더링하기 때문입니다.
- 페이지를 이동할 때 공통 템플릿도 매번 다시 불러옵니다. (성능)
- 서버 렌더링에 따른 부하가 있습니다.
- 모바일 앱을 함께 개발하면 추가 백엔드 작업이 필요해 개발이 복잡해질 수 있습니다. (생산성)
- 프론트엔드와 백엔드가 밀접하게 연결됩니다. (생산성)
SPA란?
- 한 개(Single)의 페이지로 구성된 애플리케이션입니다. (Single Page Application)
- 서버 사이드 렌더링과 비교해 배포가 간단하고, 네이티브 앱과 비슷한 사용자 경험을 제공할 수 있습니다.
- 처음에 한 페이지만 불러오고, 페이지를 이동할 때는 기존 페이지의 내용만 바꿔서 보여 줍니다.
- Angular, React, Vue 같은 프론트엔드 기술과 함께 널리 쓰이고 있습니다.
장점
- 자연스러운 사용자 경험 (UX) 전체 페이지를 다시 그릴 필요가 없기 때문입니다.
- 필요한 리소스만 부분적으로 불러옴 (성능) 정적 리소스는 처음에 한 번만 요청하고, 받은 데이터는 캐시에 저장해 둡니다.
- 서버의 템플릿 연산을 클라이언트로 분산할 수 있음 (성능)
- 컴포넌트 단위로 개발하기 쉬움 (생산성)
- 모바일 앱과 같은 API를 사용하도록 설계할 수 있음 (생산성)
단점
- JavaScript 파일을 번들로 한 번에 받기 때문에 초기 구동 속도가 MPA보다 느립니다. (Webpack의 code splitting으로 개선 가능)
- 검색엔진 최적화(SEO)가 어렵습니다. (SSR로 해결 가능)
- 보안에 신경 써야 합니다. (프론트엔드의 비즈니스 로직 최소화) SSR에서는 사용자 정보를 서버 세션으로 관리하지만, CSR에서는 클라이언트의 쿠키 외에는 사용자 정보를 저장할 마땅한 공간이 없습니다.
장단점 비교
| 구분 | SPA | MPA |
|---|---|---|
| 페이지 수 | 한 개 | 여러개 |
| 초기 구동 속도 | 느림 | 빠름 |
| 트래픽 용량 | 적음(필요한 영역만 호출하기 때문) | 많음(불필요한 영역도 다시 호출하기 때문) |
| SEO 최적화 | 어려움(해결가능) | 유리함 |
| 사용자 경험 | 자연스러움 | 깜빡거림 |
| 새로운 페이지 요청 | 필요한 페이지만 렌더링 | 전체 페이지 렌더링 |
| 렌더링 방식 | 클라이언트 사이드 렌더링 (CSR) | 서버 사이드 렌더링 (SSR) |
댓글 0