SPA & MPA

Ock Ju Won·2023년 4월 4일

MPA ajax frontend next.js react.js spa 개인프로젝트 컴공 프론트엔드

프론트엔드

목록 보기

1/1

SPA (Single Page Application)

사용자가 한 페이지 내에서 머무르면서 필요한 데이터를 서버에서 받아 와서 부분적으로만 업데이트 하는 모던 웹 패러다임

SPA

MPA (Multi Page Application)

사용자가 페이지를 이동할 때마다 서버에서 필요한 정적 리소스들 다운로드 후 전체 페이지를 렌더링하는 방식 (SPA가 등장하기 전까지 통용되던 방식)

MPA

SPA로의 역사 및 개념

기존 Web pages들은 1990년대 중반까지, Static sites였다.

→ 서버에 이미 만들어진 HTML documents들이 있으며, 사용자가 브라우저에서 특정 주소로 접속하면, 서버에 이미 배포되어있는 HTML 문서를 받아와서 보여주는 형식임.

이 기법은 치명적인 단점이 있었는데, 페이지 내에서 다른 링크를 클릭하면, 다시 서버에서 해당페이지의 HTML을 받아와서 페이지 전체가 업데이트 되어야함.

MPA의 장점으로는:

SEO 관점에서 유리하며,

→ 완성된 형태의 HTML 파일을 서버로 부터 전달받기 때문에, 검색엔진이 페이지를 크롤링하기 적합하다.
첫 로딩이 매우 짧다는 특징이 있으나,

→ 서버에서 이미 리소스들을 렌더링해서 가져오기 때문이다.

Weaknesses:

새로운 페이지를 이동하면 페이지 전체가 업데이트되기위한 새로고침(Refresh)가 이루어지므로, 깜빡임 현상(Blinking issue)가 발생한다. UX 관점에서 불편하다.
페이지 이동 시, 불필요한 템플릿도 중복해서 로딩되므로 성능적으로 불이익이 있다.
서버 렌더링이 수시로 이루어지므로, 서버에도 부담이 간다.
모바일 웹 개발시, 추가적인 백엔드 작업 개발이 요구되므로, 생산성적으로도 뒤떨어진다.

1996년, HTML에 <iframe> 태그가 도입이 되었음.

<iframe>을 통해 문서내에서 또 다른 문서를 담을 수 있도록 되었고, 페이지 내에서 부분적으로 문서를 받아와, 업데이트 할 수 있게 됨.

1998년, XMLHttpRequest API가 개발됨.

기존 Static web page 방식대로, HTML 문서 전체가 아니라, JSON과 같은 포멧으로 서버에서 가볍게 필요한 데이터만 받아와, 동적으로 HTML Elements들을 생성해 페이지에 업데이트하는 방식이다.

→ 이 방식을 응용하여 2005년, AJAX 기법이 도입되었다.

💡 XMLHttpRequest는 Fetch API의 원조격 API이다.

💡 Fetch API : HTTP 파이프라인을 구성하는 요청과 응답 등의 요소를 JS에서 접근하고 조작할 수 있는 인터페이스를 제공하는 API (Refer to MDN)

💡 AJAX : Asynchronous JavaScript And XML
AJAX로 개발된 application들의 대표적 예시로는: 구글맵과 Gmail이 있다.

현재는, Angular, React, Vue와 같은 프론트엔드 기술들을 사용함으로써, SPA 방식으로 개발이 가능하다.

모던 웹 애플리케이션 개발에서의 SPA

SPA는 기본적으로 웹 애플리케이션에 필요한 모든 정적(Static) 리소스를 최초 접근시 단 한번만 다운로드한다.

이후 새로운 페이지 요청 시, 페이지 갱신에 필요한 데이터만을 JSON으로 전달받아 페이지를 갱신하므로 1) 필요한 리소스만 부분적으로 로딩하여, 전체적인 트래픽을 감소(성능 증가)시킬 수 있고, 2) 전체 페이지를 다시 렌더링하지 않고 변경되는 부분만을 갱신하므로 새로고침이 발생하지 않아 기존보다 더 나은 UX를 제공할 수 있다.

이외에도:

컴포넌트별로 개발이 가능하며 (생산성 증가)
모바일 앱 개발 시 동일한 API를 사용하도록 설계 가능하고, (생산성)

→ SPA는 웹페이지보다 애플리케이션에 적합한 기술이므로…
서버의 템플릿 연산을 클라이언트로 분산하여 성능의 증대를 노릴 수 있다.

SPA의 단점 :

1. 초기 구동 속도

SPA는 웹 애플리케이션에 필요한 모든 정적 리소스를 최초 접근시 단 한번 다운로드하기 때문에 초기 구동 속도가 상대적으로 느리다.

2. SEO(검색엔진 최적화) 이슈

SPA는 일반적으로 서버 사이드 렌더링(SSR) 방식이 아닌 자바스크립트 기반 비동기 모델의 클라이언트 사이드 렌더링(CSR) 방식으로 동작한다. 클라이언트 사이드 렌더링(CSR)은 일반적으로 데이터 패치 요청을 통해 서버로부터 데이터를 응답받아 뷰를 동적으로 생성하는데 이때 브라우저 주소창의 URL이 변경되지 않는다. 이는 사용자 방문 history를 관리할 수 없음을 의미하며 SEO 이슈의 발생 원인이기도 하다. SPA의 SEO 이슈는 언제나 단점으로 부각되어 왔다. SPA는 정보 제공을 위한 웹페이지보다는 애플리케이션에 적합한 기술이므로 SEO 이슈는 심각한 문제로 취급할 수 없다고 생각할 수도 있지만 블로그와 같이 애플리케이션의 경우 SEO는 무시할 수 없는 중요한 의미를 갖는다. Angular나 React 등의 SPA 프레임워크는 서버 사이드 렌더링(SSR)을 지원하는 기능이 이미 존재하고 있고 크롬 등의 모던 브라우저는 SPA의 SEO 문제를 해결하고 있는 것으로 알려져 있다.