SPA와 MPA 그리고 SSR, CSR, SSG

김승ㅈIT·2023년 2월 10일

SSR과 CSR, SSG를 알아가기 앞서 SPA와 MPA가 무엇인지 간단하게 개념을 알아보자.

SPA(Single page Application)

: 한 개의 페이지로 구성된 어플리케이션

어플리케이션에서 필요한 모든 정적 리소스를 최초 한 번에 다운로드한다.
그 이후 새로운 페이지 요청이 있을 때, 클라이언트 입장에서 페이지 갱신에 필요한 데이터만 전달 받아서 페이지를 생성한다.
이것을 CSR(Client Side Renfering) 방식으로 랜더링 한다고 말한다.

MPA(Multiple Page Application)

: 여러 개의 페이지로 구성된 어플리케이션

새로운 페이지를 요청할 때마다 정적 리소스가 다운로드 된다. 매번 페이지가 다시 랜더링 된다. 이것을 SSR(Server Side Rendering) 방식으로 랜더링 한다고 말한다.

Wen Trends의 역사를 통해 SSR, CSR, SSR을 알아보자

static Sites

1990년 중반까지 모두 static sites 였다.
서버에 이미 잘 만들어진 HTML 문서들이 있고 사용자 브라우저에서 서버에 접속하면 서버에 이미 배포되어져 있는 HTML 문서를 받아와서 보여주는 형식
이였다.
여기서 한 가지 문제점은 페이지내에서 다른 링크를 클릭하면 다시 서버에서 해당페이지의 HTML을 받아와서 페이지 전체가 업데이트 되어야 했기에 사용성이 떨어졌다.

`<iframe>`

1996년 문서내에서 또 다른 문서를 담을 수 있는 iframe 태그가 도입이 되었고 이제는 페이제내에서 부분적으로 문서를 받아와서 업데이트 할 수 있게 되었다.

AJAX (XMLHttpRequest)

1998년 fetch API의 원조 XmlHttpRequest API가 개발이 되어서 HTML문서 전체가 아니라 JSON과 같은 포맷으로 서버에서 가볍게 필요한 데이터만 받아 올 수 있게 되었다. 그 데이터를 자바스크립트를 이용해서 동적으로 HTML 요소를 생성해서 페이지에 업데이트하는 방식이다.
2005년 이러한 방식이 공식적인 AJAX 라는 이름을 가지게 되고 구글에서도 AJAX를 이용해서 Gmail, google Maps과 같은 웝 어플리케이션을 만들기 시작했다.
이것이 현재 널리 쓰이고 있는 SPA(Single Page Application)이다.
사용자가 한 페이지 내에서 머무르면서 필요한 데이터를 서버에서 받아와서 부분적으로만 업데이트하게된다. 이런 방식으로 하나의 어플리케이션을 사용하듯 웹사이트에서도 사용성이 조금씩 좋아지게 된다.

SPA(Single Page Application) 트렌드와 사용자들의 PC 성능이 발달하면서 많은 것들이 무리 없이 처리할 수 있게 되었고 자바스크립트도 표준화가 잘 되어짐에 따라서 강력한 커뮤니티를 바탕으로 Angualr, React, Vue와 같은 프레임워크가 등장하며 CSR(Client Side Rendering)등장

CSR(Client Side Rendering)

클라이언트가 특정 주소에 접속시 서버에서 HTML 파일을 클라이언트에게 보내주는데 HTML 파일 안에는 아이디 루트와 어플리케이션에서 필요한 자바스크립트의 링크만 들어가있다.

<!DOCYPE html>
<html lang="en">
	<head>
    	<meta charset="utf-8"/>
        <meta name="description"
        	  content="Amazing web site"/>
    <title>App</title>
    </head>
    <body>
    	<div id="root"></div> 
        <script src="app.js"></script> 
    </body>
</html>

이와 같이 HTML은 비어져 있기 때문에 처음 접속시 빈 화면만 보이고 다시 링크된 어플리케이션 자바스크립트를 서버로부터 다운로드 받게 되는데 여기 자바스크립트에는 어플리케이션에서 필요한 로직들 뿐만 아니라 어플리케이션을 구동하는 프레임워크와 라이브러리의 소스 코드들도 다 포함이 되어져있다. 이로인해 많은 양을 다운로드 받게 되므로 시간이 소요된다.
추가로 필요한 데이터가 있다면 서버에 요청해서 데이터를 받아온 다음 동적으로 HTML를 생성해 사용자에게 어플리케이션을 보여주게 된다.

🔥 CSR(Client Side Rendering)의 문제점

사용자가 첫 화면을 보기까지 시간이 오래 걸릴 수 있다.

검색 엔진 최적화 (SEO: Search Engine Optimization)의 어려움
서버에 등록된 웹사이트를 들오다니며 웹사이트의 HTML 문서를 분석하고 판단하여서 우리가 검색할 때 웹사이트를 빠르게 검색할 수 있도록 도와주는데 CSR에서 사용되어지고 있는 HTML 바디는 비어져있기 때문에 검색엔진들이 CSR로 작성된 웹페이지를 분석하는데 어려움을 겪고있다.

위와 같은 문제점으로 인해 static sites에서 영감을 받은 SSR(Server Side Rendering)이 등장한다.

SSR(Server Side Rendering)

클라이언트에서 모든 것을 처리하는 방식과는 다르게 웹사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML파일을 만들게 되고 만들어진 HTML파일을 동적으로 동적으로 제어할 수 있는 소스코드와 함께 클라이언테에게 보내 주게 된다. 그러면 클라이언트는 HTML문서를 받아와 바로 사용할 수 있게 되는 것이다.

CSR를 사용할 때보다 SSR(Server Side Rendering)을 사용했을 때 첫 번째 로딩이 빨라진다는 것과 모든 컨텐츠가 HTML에 담겨져 있기 때문에 더욱 효울적인 SEO를 할 수 있다는 장점이 있다.

🔥 SSR(Server Side Rendering)의 문제점

Blinking issue : 사용자가 클릭을 하게 되면 전체적인 웹사이트를 다시 서버에서 받아 오는 것과 동일하기 때문에 좋지 않은 User experience를 겪을 수 있다.

서버에 과부하가 걸리기 쉽다 : 사용자가 클릭을 할 때마다 서버에 요청을 하고 서버에서 필요한 데이터를 가지고와 HTML을 만들어야 하므로 사용자가 많다면 서버에 과부하가 걸리기 쉽다

사용자가 빠르게 웹사이트를 확인할 수는 있지만 동적으로 데이터를 처리하는 자바스크립트를 아직 다운로드 받지 못해 클릭이벤트가 발생하지 않는 경우가 있을 수 있다.

흐름으로 보는 TTV(Time To View)와 TTI(Time To Interact)

CSR(Client Side Rendering)의 순서 흐름

서버 주소에 접속

서버에게서 인덱스 파일을 받아온다.
⇒ 인덱스 파일은 비어져 있기 때문에 사용자에게 보여지지 않는다.

인덱스 HTML 파일에 링크 되어 있는 이 웹사이트에서 필요한 모든 로직이 담겨져 있는 자바스크립트를 요청

최종적으로 클라이언트는 동적으로 HTML을 생성할 수 있는 웹어플리케이션 로직이 담긴 자바스크립트를 받아오개 된다.
⇒ TTV(Time To View), TTI(Time To Interact)
이 때 웹사이트가 사용자에게 보여지게 되고 상호작용이 가능하게 된다.

SSR(Server Side Rendering)의 순서 흐름

서버 주소에 접속

서버에서 만들어진 인덱스 파일을 받아온다.
⇒ TTV(Time To View)
사용자가 웹사이트를 볼 수 있게 된지만 동적인 제어가 필요한 자바스크립트 파일을 받오아지는 않았기 떄문에 상호작용이 불가능하다.

클라이언트는 자바스크립트 파일을 요청하여 서버에서 받아온다.
⇒ TTI(Time To Interact)
상호작용이 가능해진다.

웹사이트의 성능을 분석할 때 TTV와 TTI 또한 중요한 매트릭으로 사용할 수 있다.
CSR을 많이 사용한다면 최종적으로 번들링해서 사용자에게 보내주는 자바스크립트 파일을 어떻게 하면 효울적으로 많이 분할하여 처음 웹사이트 접속 시 사용자가 필요한 필수적인 것만 보낼 수 있을지 고민해봐야 한다.

SSR 같은 경우는 사용자가 보고 인터렉션하는 시간의 단차를 줄이기 위해 노력하여 조금 더 매끄러운 UI와 UX를 제공할 수 있을지 고민해봐야 한다.

SSG(Static Site Generation)

React 같은 경우는 CSR에 특화된 라이브러리이지만 Gatsby라는 라이브러리와 함께 사용하면 React로 만든 웹 어플리케이션을 정적으로 웹페이지를 생성하여 서버에 배포해 놓을 수 있다. 이렇게 만든 웹사이트들은 모두 정적인 것은 아니다.
추가적으로 데이터를 서버에서 받아오거나 또는 동적으로 처리해야하는 로직이 있다면 자바스크립트 파일을 함께 가지고 있을 수 있기 때문에 동적인 요소도 추가할 수 있다.

NEXT.JS는 SSR를 지원하는 라이브러리지만 현재는 SSG도 지원을 하고 Universal Rendering(CSR + SSR)을 이용해 목적에 따른 유연하게 사용할 수 있도록 지원하고 있다.

참고 자료
https://lvivity.com/single-page-app-vs-multi-page-app
https://www.youtube.com/watch?v=iZ9csAfU5Os&list=WL&index=13&t=115s
https://www.youtube.com/watch?v=YuqB8D6eCKE