SPA vs MPA SSR vs CSR

MPA

• 여러 개의 page로 구성된 application
• MPA SSR(server side Rendering) 방식으로 랜더링 새로운 페이지를 요청할 때마다 서버에서 랜더링 된 정적 리소스 다운
  페이지 이동하거나 새로고침 하면 전체페이지를 다시 랜더링

MPA 장점

1. seo관점 (검색엔진 최적화)에서 유리하다. - MPA 완성된 형태의 html파일을 서버로부터 전달받기 때문. 따라서 검색엔진이 페이지를 크롤링하기에 적합.
2. 첫 로딩 매우 짧다 서버에서 이미 랜더링해 그 파일을 가져오기 때문에 랜더링 시간이 없음 그러나 js 파일을 모두 다운로드하고 적용하지 않은 시점이라 각각의 기능은 동작하지 않음.

MPA 단점

1. 새로운 페이지를 이동하면 깜빡인다 매 페이지 요청마다 리로딩(새로고침)발생. 새로운 페이지를 요청할 때마다 전체 페이지를 다시 랜더링.
2. 페이지 이동시 불필요한 템플릿도 중복해서 로딩.
3. 당연히 이렇게 많은 서버를 랜더링 하면 부하가 일어남.

SPA

한 개의 page로 구성된 application
CSR(client side rendering) 방식으로 랜더링
단 한 번만 리소스를 로딩 그 후에는 데이터를 받아올 때만 서버와 통신
즉, 첫 요청시 딱 한페이지만 불러오고 페이지 이동 시 기존 페이지의 내부를 수정해서 보여주는 방식
이를 클라이언트 관점에서 말하자면 최초 페이지를 로딩한 시점부터는 페이지 리로딩 없이 필요한 부분만 서버로 부터 받아서 화면을 갱신하는 것이다.
필요한 부분만 갱신하기 때문에 네이티브 앱에 가까운 자연스러운 페이지 이동과 사용자 경험(UX)을 제공할 수 있다.
Angular, React, Vue 등 프론트엔드 기술들이 나오면서 크게 유행하고 있다.

SPA 장점

1. 자연스러운 사용자 경험(ux) 전체 page를 업데이트 할 필요가 없기 때문 빠르고 깜빡 거림 없음.
2. 필요한 리소스만 부분적으로 로딩 SPA의 application은 서버에게 정적리소스를 한 번만 요청
   받은 데이터는 전부 저장.(캐시=cache)
3. 서버의 탬플릿 연산?을 클라이언트로 분산(성능)
4. 컴포넌트별 개발 용이(생산성)

SPA 단점

1.자바스크립 파일을 번들링 해서 한 번에 받기 때문에 초기 구동 속도 느림.
2.검색엔진최적화(seo)가 어려움
3.보완 이슈 (ssr에서는 사용자에 대한 정보를 서버측에서 세션으로 관리 csr 방식에서는 클라이언트측의 쿠키말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않음.

• 번들링 : 사용자에게 웹 애플리케이션을 제공하기 위해 여러 코드와 프로그램을 묶는 행위

SPA vs MPA

• SPA(single page Application) 한 개의 페이지로 구성된 Application
• MPA(multipe page Application) 여러 개의 페이지로 구성된 Application
• SPA는 웹 애플리케이션에 필요한 모든 정적 리소스를 최초 한 번에 다운. 그 이후 새로운 페이지 요청이 있을 때, 페이지 갱신에 필요한 데이터만 전달 받아서 페이지 갱신.
• MPA는 새로운 페이지를 요청할 때마다 정적 리소스 다운 매번 전체 페이지가 다시 랜더링
• SPA는 CSR 방식으로 랜더링 MPA는 SSR 방식으로 랜더링

SSR(server side rendering)

서버쪽에서 랜더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식.

랜더링 과정 설명

1. 유저가 웹사이트에 요청을 보낸다.
2. server는 즉시 랜더링 가능한 html파일을 만든다.
3. 클라이언트에 전달되는 순간, 이미 랜더링 준비가 되어있기 때문에 html은 즉시 랜더링 된다. 그러나 사이트 자체 조작은 불가능하다 (Javascript가 읽히기 전)
4. 클라이언트가 자바스크립트 다운
5. 다운 받아지고 있는 사이에 유저는 컨턴츠는 볼 수 있지만 사이트를 조작 할 수 없음 이때의 사용자 조작을 기억하고 있다.
6. 브라우저가 javascript 프레임워크 실행
7. js까지 성공적으로 컴파일 기억하고 있던 사용자 조작이 실행 이제 웹페이지 상호작용 가능.

CSR(cilent side rendering)

랜더링이 서버가 아닌 클라이언트 쪽에 일어남. 즉, 서버는 요청을 받으면 클라이언트에 html과 js를 보내준다. 클라이언트는 그것을 받아 랜더링 시작.

랜더링 과정 설명

1. 유저가 웹사이트에 요청을 보낸다.
2. CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트로 보낸다.
   CDN: aws의 cloudflare를 생각하면 됨. 엔드 유저의 요청에 물리적으로 가까운 서버에서 요청에 응답하는 방식
3. 클라이언트는 html과 js를 다운로드 받는다.(이때 SSR과 달리 유저는 아무것도 볼 수 없다.)
4. 다운이 완료된 js가 실행 데이터를 위한 API가 호출
5. 서버가 API로부터의 요청에 응답.
6. API로부터 받아온 data를 넣어준다. 이제 페이지는 상호작용 가능.

CSR vs SSR

1. 웹페이지 로딩 시간
   웹 페이지 로딩의 종류는 두 가지로 나눌 수 있음. 하나는 웹 사이트의 가장 첫페이지 로딩 다른 하나는 나머지를 로딩

• 첫 페이지 로딩시간
  CSR의 경우 HTML, CSS와 모든 스크립트들을 한 번에 불러온다. 반면 SSR은 필요한 부분의 HTML과 스크립트만 불러온다. 따라서 평균적으로 SSR이 빠르다.
• 나머지 로딩시간
  첫 페이지 로딩 후, 사이트의 다른 곳으로 이동하는 식의 동작 가정시 CSR은 이미 첫 페이지 로딩시 나머지 부분을 구성하는 코드를 받아왔기 때문에 빠르다 반면, SSR은 첫페이지를 로딩한 과정을 정확하게 다시 실행한다. 그래서 더 느리다.

2. SEO 대응
   검색 엔진은 자동화된 로봇인 '크롤러'로 웹 사이트들을 읽는다. CSR은 자바스크립트를 실행시켜 동적으로 컨텐츠가 생성되기 때문에 자바스크립트가 실행 되어야 metadata가 바뀜.
   SSR은 애초에 서버 사이드에서 컴파일 되어 클라이언트로 넘어오기 때문에 크롤러에 대응하기 용이.
3. 서버 자원 사용
   SSR이 서버 자원을 더 많이 사용 매번 서버에 요청을 하기 때문.