[FE] SPA, CSR, SSR, TTI, TTV
SPA로 오기까지
Static Sites (~1990년 중반)
서버에 완성된 HTML 문서들이 있고, 사용자가 접속하면 서버에 배포된 HTML를 받아와서 보여주는 형식.
문제점은 페이지 내 다른 링크를 클릭하면 서버에서 HTML를 다시 받아와야 해서 페이지 전체가 업데이트되어야 했다. (사용성 ↓ )
iframe (1996)
문서 내에서 또 다른 문서를 담을 수 있는 태그. 페이지 내에서 부분적으로 업데이트 가능하게 되었다.
XMLHttpRequest API (~1998, fetch API의 원조)
HTML 문서 전체가 아닌 JSON과 같은 포맷으로 서버에서 필요한 데이터만 받아올 수 있게 되었다.
데이터를 JS를 이용해서 동적으로 HTML요소를 생성해서 페이지에 업데이트하는 방식.
이러한 방식이 공식적으로 AJAX (2005) 라는 이름을 가지게 되었고,
구글에서도 Gmail, Google Maps 등 AJAX를 이용해 웹 애플리케이션을 만들기 시작했다.
이것이 현재 사용하는 SPA이다.
SPA (Single Page Application)
사용자가 한 페이지 내에서 머무르면서 필요한 데이터를 서버로부터 받아와서 부분적으로 업데이트하는 방식.
하나의 어플리케이션을 사용하듯 사용성이 좋다.
CSR (Client Side Rendering)
서버가 클라이언트에 보여주면 처음 HTML은 텅 비어져 있다.
로직, 프레임워크, 라이브러리 소스 등이 포함된 파일을 서버로부터 다운로드하여 동적으로 HTML을 생성해 사용자에게 최종적인 애플리케이션을 보여주게 된다.
그러나 CSR에게는 이러한 문제점이 있다.
- 첫 화면을 보는데 시간이 오래 걸릴 수 있다
- SEO*가 좋지 못하다
*SEO(Search Engine Optimization)
서버에 등록된 웹사이트를 돌아다니며 HTML를 분석해 이용자가 웹사이트를 빠르게 검색할 수 있도록 하는 검색 엔진
이러한 문제점들을 보완하기 위해, Static Sites 에서 영감을 받아 SSR이 도입되게 되었다.
SSR (Server Side Rendering)
사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML를 만들게 되고,
잘 만들어진 HTML 파일을 동적으로 제어할수있는 소스와 함께 클라이언트에 전달하고, 바로 보여주게 된다.
CSR보다 첫 페이지 로딩이 빠르고 효율적인 SEO가 가능하다.
그러나 SSR에도 문제점이 존재하는데,
- 깜박임 이슈 (좋지않은 UX)
- 서버 과부하가 걸리기 쉽다
- TTV와 TTI의 공백 기간이 길다.
TTV (Time To View)
사용자가 웹 브라우저를 볼 수 있는 시점
TTI (Time To Interect)
사용자가 웹 브라우저를 인터랙션 할 수 있는 시점을 말한다. 사용자 경험과 밀접하게 연결되어 있다.
스크립트가 많을 수록 지연이 커지고, 스크립트 성능이 장치마다 다르기 때문에 영향 측면에서 장치마다 다를 수 있다.
CSR은 사이트가 사용자에게 보이게 되고 동시에 인터랙션이 가능하다.
CSR을 사용하는 개발자라면?
최종적으로 번들링에서 사용자에게 보내주는 JS를 어떻게 하면 효율적으로 많이 분할해서,
어떻게 하면 첫번째로 사용자가 보기 위해 필요한 필수적인 요소만 보낼 수 있을지 고민이 필요.
SSR을 사용하는 개발자라면?
TTV, TTI의 단차를 줄이기 위해 어떤 노력을 할 수 있을지, 매끄러운 UX/UI를 어떻게 제공할 수 있을지 고민이 필요.
요즘은 꼭 하나만 고집하기보다는, 정적으로 미리 HTML을 생성해서 배포해 두는 SSG( static site generation )
방식도 React + Gatsby 나 Next.js 를 사용해서 개발하고 있으니, 상황과 목적에 맞게 사용해 나가면 좋을 것 같다.
reference
https://www.youtube.com/watch?v=iZ9csAfU5Os&t=1s