SPA와 MPA (페이지에 따른 분류)

SPA란?

Single Page Application의 약자로 하나의 페이지로 구성된 웹 애플리케이션이다. 웹 애플리케이션에 필요한 모든 정적 리소스를 최초 한 번에 다운로드하고, 그 이후에 새로운 페이지 요청이 있을 때 페이지 갱신에 필요한 데이터만 전달받아 페이지를 구성한다.
클라이언트 관점에서, 최초의 페이지를 로딩한 시점부터는 페이지 리로딩 없이 필요한 부분만 서버로부터 받아 화면을 갱신하는 것이다. 필요한 부분만 갱신하기 때문에 페이지 이동이 깜빡임 없이 부드럽다는 장점이 있다.

MPA란?

Multi Page Application의 약자로 새로운 페이지를 요청할 때마다 서버에서 렌더링된 정적 리소스(HTML, CSS, JS)가 다운되는 전통적인 웹페이지 구성방식이다. 페이지를 이동하거나 새로고침하면 전체 페이지를 렌더링한다.

CSR, SSR (어디서 렌더링을 하는지에 따른 분류)

SPA에서는 렌더링 방식을 CSR을, MPA에서는 렌더링 방식으로 SSR을 사용하게 된다. SPA는 웹 애플리케이션에 필요한 정적 리소스를 초반 한 번에 모두 다운로드하고 그 이후 페이지 요청이 있을 때 페이지 갱신에 필요한 데이터만 전달받아 클라이언트에서 페이지를 갱신하기 때문에 자연스럽게 렌더링 방식으로 CSR을 사용한다.
MPA는 새로운 요청이 있을 때마다 서버에서 이미 렌더링된 정적 리소스를 받아오기 때문에 렌더링 방식으로 SSR을 사용한다.

브라우저 엔진은 HTML 구문을 해석해 DOM 트리를 구성하고, HTML에서 CSS 소스를 추출하여 CSSOM이라는 스타일링 객체를 구성한다. 두 객체가 잘 결합되어야 화면이 만들어진다. 이때 HTML 구문을 웹 서버가 전부 다 만들 수도 있고, HTML을 초기에 받은 후에 대부분의 내용을 브라우저가 동적으로 생성해 붙일 수도 있는데 전자가 SSR, 후자가 CSR인 것이다.

CSR(Client Side Rendering)이란?

클라이언트 측에서 렌더링을 하는 방식이다. 최초 한번 서버에서 전체 페이지를 로딩해 보여주고 사용자의 요청이 올 때마다 리소스를 서버에서 제공하면, 클라이언트가 해석하고 렌더링을 하는 방식이다.

동작 원리

사용자가 메인 페이지에 접속하마면, 브라우저가 웹 애플리케이션에 필요한 HTML과 정적 자원 (CSS, js, 이미지 리소스) 등을 서버에 요청한다. 서버에서 기초적인 HTML과 자원을 전송해주면 브라우저는 HTML을 해석하여 DOM을 생성하고 자원들을 로드한다. 이벤트 리스너도 이때, DOM이 생성될 때 부착된다. 이후 자바스크립트 엔진에 의해 js 파일들이 실행되고, 메인 페이지에서 보여줄 컴포넌트가 동적으로 생성되어 렌더링된다. 이를 Hydration이라고 한다. React나 Vue와 같은 프레임워크에서는 이때 가상 DOM이 최초로 만들어지는 것이다.
메인 페이지가 아닌 다른 페이지에 접속할 때는 클라이언트 사이드 라우팅으로 모든 페이지에 필요한 js 파일을 받아두고, 특정 페이지로 이동 시 페이지에 해당 페이지에 필요한 js 파일을 실행해 새로운 컴포넌트를 렌더링한다.

장점

자바스크립트 파일 만으로 완전히 페이지를 만들 수 있으며, 자바스크립트를 최대 한도로 활용하여 HTML, CSS를 동적으로 생성할 수 있다.
전체 페이지 로딩 없이 라우팅이 가능하다. 자바스크립트를 사용해 동적으로 돔을 그려내기 때문에 원하는 내용만 업데이트할 수 있다. 예를 들어, 링크를 이동했을 때 Header와 Footer 같은 중복되는 내용은 두고 안에 내용만 업데이트하는 것이다.

단점

HTML 파일 하나만 받아와 작동하다 보니 각 페이지에 대한 정보를 담기 힘들어 SEO에 취약하다.
첫 로드시 모든 로직이 담겨있는 자바스크립트를 다운로드하다보니 첫 진입 시 로딩 속도가 길다.

code splitting, tree-shaking chunk 분리를 통해 JS번들 크기를 줄여서 초기 DOM생성속도를 줄이면 초기로딩 속도를 개선할 수 있다.

SSR(Server Side Rendering)이란?

서버측에서 렌더링하는 방식이다. 웹페이지에 접근할 때 서버에 페이지에 대한 요청을 하면, 서버에서는 html, view와 같은 리소스를 어떻게 보여질지 해석해 렌더링을 마친 뒤 사용자에게 반환한다.

동작 원리

사용자가 웹 페이지에 접속하면 브라우저가 해당 URL을 서버에 요청하고, 서버는 이 URL을 기준으로 어떤 페이지를 렌더링할지 결정한다. 서버는 렌더링 엔진을 통해 페이지를 렌더링하고, 완성된 HTML을 브라우저에 응답한다. 이후 CSR과 마찬가지로 HTML을 해석하여 DOM을 생성하고 Hydration을 수행한다.

장점

SSR을 활용하여 페이지를 미리 빌드하면 크롤러에게 많은 정보를 줄 수 있기 때문에 SEO에 유리하다.
클라이언트에서 요청한 페이지의 HTML을 다운로드하기 때문에 CSR보다 초기 진입 시 로딩이 빠르다.

단점

클릭했을 때 새로운 HTML을 받아오기 때문에 요청 시마다 새로고침이 되어 깜빡임이 생긴다.
Header나 Footer처럼 중복되는 내용도 다시 렌더링하여 받아야하기 때문에 초기 진입은 CSR보다 빨라도, 페이지 이동은 SSR이 느리다.

SSG(Static Site Generation)이란?

클라이언트에서 필요한 페이지들을 사전에 준비해뒀다가 요청을 받으면 이미 완성된 파일을 단순히 반환하여 브라우저에서 보여지게 된다.

SSR과 SSG의 차이

SSR은 요청시 서버에서 즉시 HTML을 만들어 응답하기 때문에 데이터가 자주 변경되는 페이지에 적합하다. SSG는 미리 다 만들어두고 요청시에 페이지를 응답하기 때문에 캐싱해두면 좋은 페이지에 적합하다.

참고

https://yozm.wishket.com/magazine/detail/2330/
https://velog.io/@ka0son/%EB%A0%8C%EB%8D%94%EB%A7%81-%EC%82%BC%ED%98%95%EC%A0%9C-CSR-SSR-SSG-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0
https://www.youtube.com/watch?v=iZ9csAfU5Os