SPA와 MPA
최근 웹 어플리케이션의 개발은 대부분 react, angular, vue와 같은 js기반 프레임워크를 사용해서 SPA를 개발하게 된다. SPA는 Single Page Application의 약자로 하나의 페이지로 구성된 웹 어플리케이션을 말하며 하나의 페이지 안에서 데이터에 따라 컴포넌트가 변하는 것을 말한다. 어플리케이션을 이용할 떄 헤더는 고정되어 있고 메뉴를 선택하면 메인화면 부분 혹은 클릭한 부분만 바뀌는 웹사이트를 많이 봤을텐데 이런 웹사이트들이 SPA이다 !😀
반면 MPA란 Multi Page Application의 약자로 탭을 이동할 떄마다 서버로부터 새로운 html을 받아와서 페이지 전체를 새로 렌더링하는 전통적인 웹페이지 구성방식이다.
MPA를 사용하는 사이트들이 있긴하지만 다음과 같은 단점이 있다 !
- 매번 새로운 HTML을 서버로부터 받아옴
- 전환 시마다 화면 깜빡임
위와 같은 단점 때문에 AJAX가 등장하면서부터 원하는 부분만 클라이언트에서 동적으로 갈아끼울수 있고 화면 깜빡임도 없는 SPA를 사용하게 되었다.
SPA와 MPA를 설명한 이유는 CSR, SSR과 밀접한 관련이 있기 떄문 !
일반적으로 SPA에서는 렌더링 방식을 CSR을 ! MPA에서는 SSR을 사용한다.
SPA는 웹 어플리케이션에 필요한 정적 리소스를 초반 한번에 모두 다운로드하고 그 이후 새로운 페이지 요청이 있을 때 페이지 갱신에 필요한 데이터만 전달받아서 클라이언트에서 페이지를 갱신하기 떄문에 자연스럽게 렌더링 방식으로 CSR을 사용하게 된다.
MPA는 새로운 요청이 있을 떄마다 서버에서 이미 렌더링 된 정적 리소스를 받아오기 때문에 렌더링 방식으로 SSR을 사용하게 된다 !
react, vue, angular를 사용해서 SPA를 만들고 특별한 목적을 가지고 렌더링 방식을 변경하지 않는다면 자연스럽게 CSR을 사용하게 되고 php, JSP 등과 같은 웹 서버 언어로 구축된 웹사이트들은 MPA를 만들면 자연스럽게 SSR을 사용하게 된다는 것 !
이러한 특징 때문에
SPA === CSR ?
MPA === SSR ?
이라는 오해가 생기긴 했지만 이 두 개념은 페이지가 몇개냐 렌더링을 어디서 하느냐에 따라 달라지는 다른 개념이다 !
그렇다면 CSR이 가장 좋은 렌더링 방식일까 ?
최근 대부분의 웹 어플리케이션이 SPA를 사용하는데 가장 많이 사용되는 렌더링 방식도 CSR일 것이다. 그렇다면 가장 좋은 렌더링 방식일까..?
그럴지 알아보기 전에 CSR, SSR 개념부터 잡아보자 !😉
CSR-ClientSideRendering
SSR-ServerSIdeRendering
CSR&SSR: Client와 Server 중 어느 쪽(Side)에서 rendering을 준비하는냐의 차이
SSG-StaticSideGeneration(Static Rendering)
SSR&SSG: 서버에서 html텍스트을 보내준다는 측면에서는 SSR과 비슷하지만 언제 만들어졌느냐의 차이가 있는 것 !
SSR은 요청시 Server에서 즉시 HTML을 만들어서 응답하기 때문에 데이터가 달라지거나 자주 바뀌어서 미리 만들어두기 어려운 페이지에 적합 !
SSG는 페이지를 서버에 미리 모두 만들어 둔 뒤에 요청시 해당 페이지를 응답하는 것이기 떄문에 바뀔일이 거의 없어서 캐싱해두면 좋은 페이지에 사용하면 적합 !
CSR과 SSR
CSR
1. JS파일을 다운로드 받아 동적으로 DOM 생성하여 브라우저에 페이지를 띄우는 부분이 중요한데 CSR은 브라우저가 JS 파일을 다운받고 동적으로 DOM을 생성하는 시간을 기다려야 하기 떄문에 초기 로딩 속도가 느리다 !
하지만 초기 로딩 이후 서버에 해당 데이터만 요청하면 되기 떄문에 이후 구동 속도는 빠르다는 특징이 있다.
2. Server가 빈 뼈대만 있는 HTML을 넘겨주는 역할만 수행하면 되기 떄문에 서버측에 부하가 적다. 이 밖에도 Client측에서 연산, 라우팅 등을 모두 직접 처리하기 떄문에 반응 속도가 빠르고 UX도 우수하다는 장점이 있다.
브라우저들이 가진 웹 크롤러는 html을 읽어서 검색 가능한 색인을 만들어내는데 웹 크롤러 봇 입장에서 본 HTML은 위와 같이 텅텅 비어져 있다 !
검색엔진(SEO)이 색인을 할만한 컨텐츠가 존재하지 않다.. 이 떄문에 CSR은 검색엔진 최적화에 불리하다는 치명적인 단점이 있다.
물론 Google의 크롤러 봇은 JS를 실행할 줄 알아서 CSR 웹사이트의 크롤링도 가능하지만 아직 완벽한 단계가 아니기도 하고 Google측에서도 여전히 크롤러 봇이 JS를 실행하기 전에 더욱 빠르게 크롤링 할 수 있도록 또한 JS를 실행할 수 없는 다른 크롤러 봇들을 위해서 SSR을 고려해보란 말을 덧붙이고 있다고 한다 !
SSR
1. 서버에서 렌더링 준비를 마친 html을 브라우저에 응답으로 전달하는 부분에서, 모든 데이터가 이미 HTML에 담겨진 채로 브라우저에 전달되기 때문에 SEO(검색엔진 최적화)에 유리 ! JS를 실행할 줄 모르는 크롤러 봇도 HTML을 읽을 수 있다 !
2. JS code를 다운로드 받고 실행하기 전에 사용자가 화면을 볼 수 있다는 점 ! JS 다운로드를 기다려야 헀던 CSR보다 초기 구동 속도가 빠를 수 밖에 없다 ! 그러나 이것은 동시에 치명적인 단점이 된다. JS code가 없으므로 이 시점에는 사용자가 버튼을 클릭하거나 이동하려고 해도 아무런 반응이 없을 수 있다, interaction 가능한 페이지처럼 보이지만 그저 내용과 style이 입혀진 껍데기에 불과하고 실제로 Client 측 JS가 실행되고 이벤트 헨들러가 첨부되서 JS 로직이 모두 연결 될 떄까지 사용자의 입력에 응답할 수 없기 때문이다.
사용자 입장에서는 렌더링된 페이지에서 뭔가를 눌렀는데 아무런 반응이 없다면 당황활 것이다..🤔
이렇게 SSR에는 TTV(TimeToView) !== TTI(TimeToInteract), 시간 간격이 존재.. 반면에 CSR은 TTV === TTI, JS가 동적으로 DOM을 생성하기 떄문에 HTML은 JS 로직이 완전히 연결된 상태라 사용자가 이용할 수 있는 시점과 보는 시점이 동일하다 !
CSR과 SSR의 장단점
CSR의 단점 보완 방법
CSR + SSR/SSG..without 프레임워크
express JS로 별도의 서버를 직접 운영하는 방법, Typescript 설정이 걱정된다면 기본적으로 Typescipt를 지원하는 NestJS를 사용할 수 있다.
하지만 이 방법들은 서버 환경구성이나 빌드 등의 작업을 별도로 해주어야 한다.
CSR + SSR/SSG..with 프레임워크
이런 프레임워크들이 CSR에 SSR/SSG 도입을 도와주지만, CSR에 비해 코드 복잡도가 올라가며, 또 프레임워크 사용으로 직접 제어할 수 없는 블랙박스 영역 존재 !
lazy loading ? 🙄
lazy loading은 페이지 내에서 실제로 필요로 할 때까지 리소스의 로딩을 미루는 것이다. 페이지를 로드하자마자 리소스를 로딩하는 일반적인 방식 대신, 실제로 사용자 화면에 보여질 필요가 있을 때까지 이러한 로딩을 지연하는 것이다.
laze loading을 다루는 방식은 페이지 내의 거의 모든 리소스에 적용할 수 있다. 예를 들어, SPA(Single Page Application) 내에서 JS 파일이 나중에까지 필요하지 않으면 초기에 로드해서 가져오지 않는 것이 가장 좋다. 이 처럼 이미지도 바로 보여질 필요가 없다가, 실제로 보여질 필요가 있을 때 로딩을 하는 것.
CSR + SSR...Univeral Rendering
초기 렌더링 방식으로 SSR을 사용하고 그 이후에는 CSR을 사용하는 App이나 그 렌더링 방식을 부르는 용어가 있다.
Isomorphic App 혹은 Univeral Rendering: Server와 Client에서 동일한 코드가 동작하는 어플리케이션이라는 의미로 해석, 클라이언트와 서버가 모두 같은 코드로 돌아가기 떄문에 예상과는 다른 결과를 맞이 할 가능성도 있지만 초기 로딩 속도 보완, SEO 개선, CSR의 장점을 그대로 가져갈 수 있는 대안이 되기 떄문에 최근 많이 사용되는 추세이다.
CSR, SSR, SSG, Universal - 무엇을 써야하나
CSR도 단점이 있고 SSR도 단점이 있고 그것을 보완하려고 조합해서 사용해도 단점이 있다.. 그러면 어떤 방식을 사용하는 것이 좋을까?
정답은 서비스의 성격에 따라 달라진다 !
- 만약 사용자와의 상호작용이 많고 대부분 페이지가 사용자의 개인정보 데이터를 기준으로 구성되는 서비스라면 검색포털 상위에 노출되는 것보다 오히려 사용자의 데이터를 보호하는 것이 더 중요할 수 있다. 모든 서비스의 SEO가 필요하지 않다. 이런 서비스의 경우, SSR보다 CSR이 더 적합 !
- 만약 회사 홈페이지이기 떄문에 상위 노출되어야 하고 누구에게나 동일한 내용을 노출하고 있다면, 그리고 만약 그 페이지 데이터가 자주 바뀐다면 SSR이 더 적합할 것이고 내용을 업데이트하는 일이 거의 없다면 SSG가 더 적합할 것이다. 만약 사용자에 따라 페이지 내용도 달라지고 빠른 interaction도 중요하고 검색엔진 최적화도 포기할 수 없다면 그 때는 (CSR+SSR)Universal Rendering을 고려해보면 좋을 것이다.
참고자료: https://www.youtube.com/watch?v=YuqB8D6eCKE&list=LL&index=1
