MPA (Multi-page Application)

여러 개의 페이지를 두고 인터랙션이 발생할 때 마다 해당 링크로 이동하여 앱이 다시 새로고침되는 전통적인 방식의 어플리케이션.

MPA는 대부분 서버 사이드 렌더링 방식으로 동작하며,PHP, JSP를 사용해서 구축한 웹사이트에서 많이 볼 수 있다.

SPA (Single-page Application)

하나의 페이지로 구성된 어플리케이션

SPA는 대부분 클라이언트 사이드 렌더링 방식으로 동작하며 대표적으로 React, Vue, Angular 등의 자바스크립트 프레임워크/라이브러리가 존재한다.

SSR (Server-Side Rendering)

서버로부터 완전하게 만들어진 HTML 파일을 받아와 전체 페이지를 렌더링하는 방식.

동작 방식

• 클라이언트에서 서버에게 요청을 전송한다.
• 서버는 즉시 렌더링 가능한 HTML 파일을 생성한 후 (Ready to Render) 클라이언트에게 전달한다.
• 클라이언트가 전달 받은 HTML 파일은 즉시 렌더링되지만, JavaScript가 읽히기 전이기 때문에 사이트 조작은 불가능하다.
• 클라이언트는 JavaScript를 다운로드 받는다. 이 과정에서도 역시 사이트 조작은 불가능하지만 사용자의 조작을 기억해둔다.
• 브라우저가 JavaScript 로직을 연결하여 실행한다.
• 기억해뒀던 사용자의 조작이 실행되고 사이트 조작이 가능해진다.

장단점

장점

SEO에 유리하다.

모든 데이터가 이미 HTML에 담겨져있는 채로 전달되기 때문에 SEO에 유리하다.

초기 로딩 속도가 빠르다.

렌더링이 준비된 HTML 파일을 바로 브라우저에 출력하기 때문에 초기 로딩 속도가 CSR에 비해 빠르다.

단점

TTV와 TTI가 다르다.

TTV (Time to View)
사용자가 웹 브라우저에서 내용을 볼 수 있는 시점

TTI (Time to Interact)
사용자가 웹 브라우저에서 상호작용 할 수 있는 시점

화면에는 출력되었지만 실제로는 JavaScript가 읽히지 않았기 때문에 이때 시도되는 인터랙션은 동작하지 않는다.

화면 깜빡임으로 인한 불편한 UX.

SSR은 서버로부터 필요한 부분만 받아오는 것이 아니라 전체 리소스를 다시 전달받고 렌더링하는 것이 특징이다. 따라서 앱 전체가 새로고침되므로 화면이 깜빡힌 후에 표시되므로 UX에 좋지 않은 영향을 끼친다.

서버 부하 증가.

서버에서 실질적으로 모든 작업을 도맡아 하므로 서버의 부하가 증가한다.

CSR (Client Side Rendering)

클라이언트에서 사용자의 요청에 따라 필요한 부분만 응답받아 렌더링하는 방식.

동작 방식

• 클라이언트에서 서버에게 초기 화면 로드를 위해 요청한다.
• 서버는 클라이언트에게 빈 HTML 파일과 레퍼런스된 JavaScript 링크를 응답한다.
• 클라이언트는 JavaScript 번들 파일을 다운로드한 후, AJAX를 통해 동적 컨텐츠를 받아와 파싱 및 렌더링한다.
• 화면의 일부 요소를 변경할 시, 클라이언트는 JavaScript를 통해 서버에게 필요한 데이터만을 요청한다.
• 서버는 변경된 일부 요소와 관련된 리소스만 응답한다.

장단점

장점

화면 깜빡임 없는 향상된 UX.

페이지 전체를 새로 받아와 렌더링 하는 것이 아니라 필요한 부분만을 변경하기 때문에 전체 화면이 깜빡이지 않고 수정된 데이터가 표시된다.

초기 로딩 이후부터 빠른 속도 및 서버 부하 감소.

CSR에서는 JavaScript를 다운로드받아 동적 DOM을 생성하기때문에 초기 로딩 속도가 오래걸린다. 하지만 그 이후부터는 필요한 데이터만을 요청하기 때문에 구동 속도가 빠르고 서버 부하 적다.

TTV와 TTI 사이에 간극이 없다.

일단 브라우저에 출력하고나서 JavaScript를 읽어오는 SSR 방식과는 달리, CSR은 백지 HTML에서 JavaScript를 통해 동적으로 렌더링하므로, 화면이 출력되는 시점 (TTV)에서는 이미 JavaScript와 연결이 되어있어 상호작용이 가능하다. (TTI)

단점

SEO에 불리하다.

처음에는 빈 HTML만을 두고 JavaScript를 통해 동적으로 페이지를 렌더링하기 때문에 웹 크롤러가 페이지를 색인화하려고 살펴 보면 빈 페이지로 보인다.

초기 로딩 속도가 느리다.

번들링된 JavaScript 파일을 받아서 동적 렌더링을 하는데, 이 방식은 어플리케이션의 규모가 커지면 번들링된 JavaScript 파일의 크기도 덩달아 커질 수 있다.

따라서 크기가 커진 JavaScript 번들을 다운로드 받는 시간이 길어져 초기 로딩 속도가 길어질 수 있다.

SPA, MPA !== CSR, SSR

SPA와 MPA, CSR과 SSR은 페이지의 개수, 렌더링의 위치에 따라 달라지는 상이한 개념이다.

CSR과 SSR은 각각 클라이언트, 서버에서 렌더링하는 방식이다.
즉, 클라이언트와 서버 중 어느 쪽 (Side)에서 렌더링을 준비하느냐의 차이이다.

반면 SPA와 MPA는 각각 페이지를 한 개 (Single) 또는 여러 개 (Multi) 두고 동작하는 어플리케이션이다.

SSG

Static Site Generation (Static Rendering)
클라이언트에서 필요한 페이지들을 사전에 미리 준비해뒀다가, 요청을 받으면 이미 완성된 파일을 단순히 반환받아 출력하는 방식

어떤 방식을 선택할지는 만들고자 하는 어플리케이션의 성격에 따라 달라진다.

SSR은 요청하는 즉시 서버에서 페이지를 생성하므로, 미리 만들어두기 어려운 페이지에 적합하다.
SSG는 미리 다 만들어두니까 바뀔 일이 거의 없는 페이지에 적합

CSR 단점 개선

Code Splitting, Three Shaking, Chunk 분리 등으로 JavaScript 번들의 크기를 줄이면 CSR의 초기 로딩 속도를 보완할 수 있다.

또한 Pre-Rendering을 통해 SEO 개선이 가능하다.
라이브러리나 웹팩 플러그인을 통해 각 페이지의 HTML을 미리 생성해두면, 크롤러가 사전에 렌더링 된 HTML 버전 페이지를 읽을 수 있다.

또는 CSR에 SSR, SSG를 도입하는 것도 방법이다.

대표적으로 React, Vue, Angular에는 이러한 방식을 지원하는 프레임워크가 출시되어있다.
React - Next.js, Gatsby
Vue - Nuxt.js
Angular - Angular Universal

이처럼 초기 렌더링 방식으로 SSR, 그 이후부터는 CSR을 사용하는 앱이나 그 렌더링 방식을 부르는 용어가 있다.

Isomorphic App

Isomorphic : 같은 모양의, 동일 구조의, 등정형의
서버와 클라이언트에서 동일한 코드가 동작하는 구조의 어플리케이션.

초기 로딩 속보를 보완하면서 SEO도 개선되기 때문에 CSR의 장점을 모두 챙길 수 있어서 최근에 각광받고 있다.

Universal Rendering

CSR과 SSR을 동시에 지원하는 방식.

서비스의 성격에 따라 CSR, SSR 등을 구분해서 써야한다.

사용자와 상호작용이 많고 검색 엔진에 노출될 필요가 없다면 (대부분이 고객 개인 정보로 이루어져있어서) 고객 데이터 보호가 더 우선시되기 때문에 CSR을 선택할 수 있다.

반면 회사 홈페이지같이 자주 업데이트되지 않고 상위에 노출되어야한다면 SSG를,
동일한 조건에서 자주 업데이트된다면 SSR를 선택할 수 있다.

만약 CSR과 SSR이 전부 필요하다고 판단된다면 CSR+SSR 즉 Universal Rendering을 고려할 수 있다.