[개발일기] SPA 그리고 CSR, SSR, SSG

웹 랜더링에 대한 방식은 정말로 다양하다. 프론트엔드 개발을 하다보면 이에 대한 약어들을 많이 들을 수 있는데, 이번 포스팅에는 이러한 웹 랜더링의 트랜드를 잡고 있는 랜더링 기술에 대해 알아보겠다.

CSR(Client Side Rendering)

서버에서 HTML을 받아와서 JS주소를 서버로 요청해 동적으로 사용자에게 최종적인 어플리케이션을 보여준다. 대표적으로 SPA가 있다. 

출처 : https://www.solutelabs.com/blog/client-side-vs-server-side-rendering-what-to-choose-when

위 그림은 CSR의 순서를 나타낸다.
1. User는 Website에 요청을 보낸다.
2. Edge Caching은 HTML파일과 JS에 접근할 수 있는 링크를 빠르게 보낸다.
3. 브라우저는 HTML, JS를 다운로드받는다. 
(이 때, User는 SSR처럼 페이지 조회를 할 수 없다.)
4. 브라우저는 JS를 다운받는다.
5. 다 다운로드가 되고 나면 JS가 실행되고, 데이터를 불러오기 위한 API가 호출된다. User는 placeholder를 바라본다.
6. 서버는 API로부터 온 요청을 받아 응답한다.
7. API로부터 받은 데이터를 placeholder에 채워준 뒤, 페이지를 상호 작용 할 수 있게 된다.

SPA(Single Page Application)

SPA. 이를 직역한다면 단일 웹 페이지에서 사용자가 필요한 부분만 업데이트해서 보여주는 애플리케이션을 말한다. 즉, CSR(Client Side Rendering) 방식으로 작동하는 애플리케이션이다. 그렇다고 페이지 하나로만 이루어진 웹 사이트를 말하는 것이 아닌, JS를 이용해 텅 빈 HTML 문서 하나에서 브라우저가 비동기로 모든 일을 처리하는 애플리케이션을 말한다. 따라서 서버는 오직 Ajax를 통해 필요한 데이터를 주고 받는 역할만 수행한다. 객체에 대한 이벤트 발생 > API호출 > HTML 문서로 데이터를 가져와 랜더링하기까지의 모든 과정이 브라우저상에서 JS를 통해 일어나게 되는 것이다. 요즘에는 React, Vue.js 등과 같은 라이브러리 또는 프레임워크를 이용해 개발을 할 수 있다. 
<장점>
-  클라이언트에서 최초로 한 번 JS 코드를 내려받으면 그 이후에는 서버와 네트워크 통신을 할 필요가 없기 때문에 일반적인 웹사이트처럼 페이지마다 끊김 현상이 발생할 일은 거의 없다.
- 이 때문에 UX측면에서는 매우 용이하다.
<단점>
- 지나친 JS 의존성을 갖고 있다.
- JS가 작동하지 않는 브라우징 환경에서 아예 실행이 불가능할 수 있다.
- 웹사이트 최초 로딩시 받아야 할 JS 코드 양이 많은 경우에 비교적 시간이 오래 걸린다.
- 크롤링을 할 수 있는 요소가 <div>외에 없기 때문에 SEO(검색 엔진 최적화) 측면에서 불리하다. (Low SEO)
- 단순한 웹 페이지를 제작할 경우 오버 엔지니어링으로 볼 수 있는 방식이다.

 

SSR(Server Side Rendering)

말 그대로 사이트 주소를 요청할 때, 서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하면 필요한 데이터를 받아서 바로 사용자에게 보여주는 방식이다.

출처 : https://www.solutelabs.com/blog/client-side-vs-server-side-rendering-what-to-choose-when

위 그림은 SSR의 순서를 나타낸다.
1. User는 Website에 요청을 보낸다.
2. Server는 렌더가 준비된 상태의 HTML 파일을 만든다.
3. 브라우저는 빠르게 HTML을 렌더할 수 있지만, 사이트와의 상호 작용은 할 수 없다.
(클라이언트에게 보여지는 화면이 있다는 말씀!)
4. 브라우저는 JS를 다운받는다.
5. User는 콘텐츠를 볼 수 있으며, 상호 작용을 기억하고 있는다.(사용자가 조작한 내용을 기록한다는 의미이다)
6. 브라우저가 JS 프레임워크를 실행한다.
7. JS가 컴파일이 되고 나면, 기록해둔 상호 작용을 실행하고, 웹 페이지 자체에서도 상호 작용이 가능하게 된다.

<장점>
- HTML에 모든 정보가 담아져 있어 좀 더 효율적인 SEO가 가능하다.
- CSR보다 빠르게 화면을 viewing 할 수 있다.
<장점>
- 대신 클릭을 할 때마다 서버에 데이터를 요청하기 때문에 서버에 과부하가 걸릴 수 있다. 
- 사용자에게 화면 제공이 되지만 동적인 JS를 받아오는데 시간이 걸려 동작이 멈춰있는 경우가 있다.

 

SSG(Static Site Generatior)

CSR과 SSR의 단점을 보완하기 위해 나왔으며, 좀 더 매끄러운 서비스 제공을 위해 미리 서버에 화면을 저장했다 꺼내서 사용하는 방식이다.

출처 : https://www.techradiant.com/2020/02/05/best-static-site-generator-to-use-in-2020/static-site-generator/

위 그림은 SSG의 순서를 나타낸다.
1. User가 Website 방문시(request), Edge Caching된 HTML로 보여준다(response).
2. 브라우저가 HTML 코드를 다운로드 받은 뒤 User는 사이트를 볼 수 있게 된다.

<장점>
- 단순한 웹 페이지를 제작할 경우 SPA 방식보다 SSG방식을 사용하는 것이 더 효율적이다.
- 이미 생성된 HTML을 받기 때문에 SEO에 친화적이다.
<단점>
- 모든 URL마다 각각 HTML 파일을 생성해야하며, 이 때문에 URL을 미리 정하지 않으면 적용이 어렵다. 

SSR vs CSR 간단비교

 

* SPA와 MPA의 라이프사이클은 이렇게 보시면 될 것 같습니다