들어가기 전에 알아둬야할 SPA, MPA
페이지 구성 방식
✅ SPA, MPA
-
SPA (Single Page Application) : 하나의 페이지로 구성된 웹 어플리케이션. 하나의 HTML 파일을 기반으로 자바스크립트를 이용해 동적으로 화면의 컨텐츠를 바꾸는 방식의 웹 어플리케이션이다.
-
MPA (Multi Page Application): 서버에 여러개의 페이지를 준비해놨다가 요청시 서버로부터 새로운 HTML파일을 받아와서 경로에 따라 적절한 페이지를 내보내주는 방식
> 단점: 매번 새로운 HTML을 서버로부터 받아오기 때문에 화면이 바뀔때마다 화면 깜빡임이 발생 ajax의 등장 이후, 원하는 부분만 동적으로 갈아끼울 수 있고 깜빡임없이 화면 전환이 되는 spa를 사용하게 되었다.
렌더링 방식
✅ CSR, SSR
> 주의!
일반적으로 아래와 같이 SPA -> CSR, MPA -> SSR이라고 생각할 수 있는데 페이지가 몇 개인지에 따라, 렌더링을 어디서 하느냐에 따라 달라지는 개념이기 때문에 무조건 연결된다는 생각은 버리자!
📓 CSR (Client Side Rendering)
장점
1. 첫 로딩만 기다리면, 후에 동적으로 빠르게 렌더링되기 때문에 사용자 경험(UX)이 좋다.
2. 서버가 빈 뼈대의 HTML과 JS 링크만 전달해주면 되기 때문에 서버측의 부하가 적다
3. 클라이언트 측에서 연산, 라우팅등을 모두 직접 처리하기 때문에 반응 속도가 빠르고 UX 우수.
4. TTV와 TTI 사이 간극이 없다.
- 상세 설명
브라우저는 js 파일을 다운받아 동적으로 페이지를 만들어서 띄우는데까지(동적으로 dom을 만든다) 시간을 기다려야하기 때문에 '초기 로딩 속도가 느리다' 그렇지만, 초기 로딩 속도만 지나면 후에 페이지 일부를 변경시키려 할때 서버에 해당 데이터만 요청하면 되기 때문에 사용자 경험이 좋다. - 상세 설명
TTV: Time to View, 사용자가 웹 브라우저에서 내용을 볼 수 있는 시점
TTI: Time To Interact, 사용자가 웹 브라우저에서 인터렉션 할 수 있는 시점
단점
1. 모든 스크립트 파일이 로드될 때까지 기다려야 한다.
2. 검색 엔진 최적화(Search Engine Optimization)에 불리하다.
- 상세설명
1의 단점을 보완하기 위해 리소스를 청크(Chunk)단위로 묶어서 요청 할때만 다운받게 하는 방법으로 어느정도는 보완할 수는 있지만 완벽하게 해결할 수는 없다. - 예시(웹 크롤러 봇 입장에서 본 html 이미지- 검색 엔진 색인할 것이 아무것도 없다...)
물론 구글 크롤러 봇은 js를 실행할 줄 알지만 완벽한 단계는 아니고 다른 크롤러 봇들은 아직 js를 실행하지 못한다.
📓 SSR (Server Side Rendering)
브라우저가 페이지를 요청할 때마다 해당 페이지에 관련된 HTML, CSS, JS 파일 및 데이터를 받아와서 렌더링 시킨다.
서버에서는 즉시 페이지에 필요한 데이터들을 얻어와 모두 삽입하고 CSS까지 모두 적용해 렌더링 준비를 마친 HTML과 JS code를 브라우저의 응답으로 전달한다. 브라우저는 전달받은 HTML을 띄우고 브라우저는 JS code를 다운로드하고 HTML에 JS 로직을 연결한다.
장점
1. 모든 데이터가 html에 담겨진 채로 브라우저에 응답하기 때문에(JS를 이용한 렌더링이 아니기 때문에) 검색엔진 최적화에 유리하다.
2. 자바스크립트 코드를 다운로드 받고 실행하기 전에 사용자가 화면을 볼 수 있다는 점에서 초기 로딩 속도가 빠르고 사용자가 컨텐츠를 빨리 볼 수 있다.
단점
1. 매번 페이지를 요청할 때마다 새로고침이 되기 때문에 사용자 경험이 SPA에 비해서 좋지 못하다.
2. TTV와 TTI 사이 간극이 발생할 수 있다.
3. 매번 서버에 요청을 하기 때문에 서버 부하가 커진다.
- 상세설명
SSR은 사용자가 컨텐츠를 빨리 볼 수 있지만, JS가 연결되기 전까지는 빈 껍데기에 불과하기 때문에, 만약 유저가 버튼과 같이 이벤트를 발생시키는것을 실행했을 시 아무런 반응이 없을 수 있다.
참고 자료
