SPA vs MPA, CSR vs SSR

예전에는 MPA 방식으로 사용자가 페이지를 이동하면 전체 컨텐츠를 로드하는 많은 정적 페이지를 연결하였으나 나중에는 많은 페이지가 연결된 웹 응용 프로그램이 속도가 느려지는 이슈가 있었다.

 

이로 인해 AJAX를 사용해 MPA를 개선했지만, 이것 역시 온라인 페이지의 복잡성 증가와 같은 역효과를 가져왔다.

이후 SPA 모델이 출시되었고, 이것은 MPA + AJAX의 업그레이드 버전이었다. SPA는 페이지 데이터와 레이아웃을 별도로 요청하고 결과를 브라우저에 직접 렌더링할 수 있다. 

 

SPA(Single Page Application)

SPA는 한 개(Single)의 Page로 구성된 Application

서버로부터 완전한 새로운 페이지를 불러오는 게 아니라 현재의 페이지를 동적으로 다시 작성.

SPA의 핵심 가치는 사용자 경험(UX) 향상에 있으며, 부가적으로 애플리케이션 속도의 향상도 기대할 수 있어서 모바일 퍼스트 전략에 부합함.

 

작동 방식

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

이후 새로운 페이지 요청 시, 페이지 갱신에 필요한 데이터만을 JSON으로 전달받아 페이지를 갱신함

  → 기존 페이지의 내부를 수정해서 보여주는 방식

SPA는 일반적으로 CSR 방식으로 렌더링함. (SPA를 쓰면서도 SSR이 되어야 하는 상황 존재. SSG 개념 참고)

 

장점

1. 속도 및 응답시간
   → 전체 페이지를 다시 렌더링하지 않고 변경되는 부분만 갱신하므로 새로고침 발생 ❌
2. 모바일 친화적
   → 모바일 앱도 SPA와 동일한 아키텍처에서 개발되므로 백엔드 코드를 재사용하도록 할 수 있다.
3. 개발 간소화
   → 서버에서 페이지를 렌더링하기 위해 코드를 작성할 필요가 없음.
   
4. 로컬 스토리지 캐시
   → SPA는 모든 로컬 스토리지를 효과적으로 캐시. 애플리케이션은 하나의 요청만 보내고 모든 데이터를 저장한 다음 이 데이터를 사용할 수 있으며 오프라인에서도 작동함.
   

단점

1. 초기 구동 속도
   → SPA는 모든 정적 리소스를 최초 접근 시 단 한 번 다운로드하기 때문에 초기 구동 속도가 상대적으로 느림
2. SEO 이슈
   → 자바스크립트를 읽지 못하는 검색엔진에 대해서 크롤링이 되지 않아 색인이 되지 않는 문제 발생 가능
3. 보안 문제
   → XSS로 인해 공격자가 다른 사용자가 웬 응용 프로그램에 클라이언트 측 스크립트를 삽입할 수 있음

 

MPA(Multi Page Application)

MPA는 웹 앱을 개발하는 전통적인 방법. 여러 개(Multiple)의 Page로 구성된 Application

 

작동 방식

새로운 페이지 요청할 대마다 서버에서 렌더링된 정적 리소스 다운.

페이지를 이동하거나 새로고침하면 전체 페이지 다시 렌더링.

MPA는 SSR 방식으로 렌더링.

 

장점

1. SEO 친화적
   → MPA를 사용하여 여러 페이지를 생성할 수 있기 때문에 훨씬 더 많은 수의 키워드를 타겟팅할 수 있음.
2. 확장성
   → 다중 페이지로 원하는 만큼 페이지를 추가할 수 있음.
   

단점

1. 페이지 이동 시 느린 속도
   → 사용자가 새로운 페이지를 이동하면 전체 페이지를 다시 렌더링하기 때문. 리소스들이 새로 고쳐져서 속도에 영향.
2. 복잡한 개발
   → 개발자는 클라이언트 측과 서버 측 모두에 프레임워크를 사용해야 함. 따라서 애플리케이션 개발 시간이 더 길어짐.
3. 보안 및 유지보수
   → 개발자는 모든 페이지가 안전한지 확인해야하는데 페이지가 많아서 지속적으로 유지보수하기 어려움.

출처: https://velog.io/@yejine2/SPASingle-Page-Application-VS-MPA

 

 

 

CSR(Client Side Rendering)

클라이언트 측에서 렌더링하는 방식.

작동 방식

1. 유저가 웹사이트에 방문하면, 브라우저가 서버에 콘텐츠 요청
2. 서버는 빈 뼈대만 있는 HTML을 응답으로 보내줌.
3. 브라우저가 연결된 JavaScript 링크를 통해 서버로부터 다시 JavaScript 파일을 다운로드
4. JavaScript를 통해 동적으로 페이지 만들어 브라우저에 띄워줌

장점

1. 서버 측 부하가 적음
   → 서버는 빈 뼈대만 있는 HTML을 넘겨주는 역할만 수행. 따라서 서버 측의 부하가 적음
2. 사용자 경험(UX) 우수
   → 클라이언트 측에서 연산, 라우팅을 직접 처리하기 때문에 반응속도가 빠르고 UX 우수

단점

1. 초기 로딩 속도 느림
   → CSR은 브라우저가 JavaScript 파일을 다운로드하고, 동적으로 DOM을 생성하는 시간을 기다려야 하기 때문에 초기 로딩 속도가 느림.
2. SEO 불리
   → 자바스크립트를 실행하지 못하는 크롤러일 경우, SEO가 어려움.

 

SSR(Server Side Rendering)

서버 측에서 렌더링하는 방식.

작동 방식

1. 유저가 웹사이트에 방문하면, 브라우저가 서버에 콘텐츠 요청
2. 서버는 페이지에 필요한 데이터를 즉시 얻어와 모두 삽입, CSS까지 모두 적용해 렌더링 준비를 마친 HTML과 JavaScript 코드를 브라우저에 응답으로 전달
3. 브라우저에서는 JavaScript 코드를 다운로드하고 HTML에 JavaScript 로직을 연결함.

장점

1. SEO에 유리
   → 크롤러 봇이 HTML을 무리 없이 읽을 수 있기 때문
2. 초기 구동 속도 빠름

단점

1. TTV(Time to View)와 TTI(Time to Interact) 간의 시간 간격 존재
   → 사용자가 버튼을 클릭하거나 이동하려고 할 때 아무 반응이 없을 수 있음. Interaction이 가능한 페이지처럼 보이지만 실제로는 내용과 스타일이 입혀진 껍데기에 불과하며, 실제로는 클라이언트 측 JavaScript가 실행되고 이벤트 핸들러가 첨부된 JavaScript 로직이 모두 연결될 때까지 사용자의 입력에 응답할 수 없기 때문.
2. 화면 깜빡임 및 서버 부하 발생

출처: https://dev-ellachoi.tistory.com/28

 

이를 공부하다 보니 CSR, SSR 말고도 SSG, Universal Rendering 방식이 있다는 걸 알게 됐으며, 브라우저 상에서의 JavaScript 동작 원리, Ajax의 역할, React의 동작 원리에 대해 공부해야 할 필요성을 느꼈다. 다음 글에서는 우선 SSG, Universal Rendering 방식에 대해 공부해보겠다.

 

 

참고:

- https://velog.io/@yejine2/SPASingle-Page-Application-VS-MPA

- https://dev-ellachoi.tistory.com/28