이번 포스팅에서는 개발자라면 상식으로 알고 있어야 하는 TTV(Time To View), TTI(Time To Interact), SSG(Static Site Generation)의 개념에 대해서 정리해보려고 한다.
우선 앞의 세 가지 개념에 대해서 정리를 하기 전에 간단하게 웹의 변천사에 대해서 살펴보자.
1990년 중반까지의 웹 사이트는 static sites로, 서버에서 이미 만들어진 HTML 파일들을 받아오는 형태로 동작한다. 이 static sites의 단점은 주소를 요청할때마다 다시 서버로부터 새로운 html 파일을 받아서 re-rendering을 하기 때문에 화면이 blinking되어 사용감에 불편함을 준다.
이러한 전체 화면이 re-rendering이 되는 것을 개선하고자 1996년부터 html 문서 내에 또 다른 문서를 포함시킬 수 있는 <iframe>태그가 도입이 되었고, 이때부터는 페이지 내에서 부분적으로 문서를 받아와서 업데이트를 할 수 있게 되었다.
1998년이후부터는 현재 비동기 요청시에 사용되는 fetch API의 원조격인 XMLHttpRequest API가 등장을 하게 되는데, 이때부터 JSON 포멧으로 서버로부터 필요한 데이터만 받아 올 수 있게 되었다. 받아 온 데이터는 자바스크립트로 동적으로 HTML element를 생성해서 페이지에 로딩할 수 있게 되었다.
위의 방식이 2005년부터 공식적으로 ajax라는 이름으로 불려지면서, SPA의 방식이 본격적으로 도입이 되기 시작했다.
하나의 웹 페이지에서 필요한 부분의 일부만 렌더링하기 때문에 사용자에게 앱을 사용하는 것과 같은 사용감을 주기 때문에 웹 앱이라고 불리기 시작했다.
SSR과 CSR의 개념에 대해서는 이전에 별도로 블로그 포스팅을 해뒀기 때문에 아래 링크의 포스팅을 참고하도록 하자.
https://leehyungi0622.github.io/2021/04/26/202104/210426-SSR_and_CSR/
CSR의 문제를 보안하기 위한 SSR
CSR방식은 처음에는 서버로부터 빈 화면만 받아오게 되고, 이후에 서버로부터 필요한 자바스크립트 파일과 필요한 각종 라이브러리 및 소스코드를 받아오게 되는데 사이즈가 크기 때문에 초기의 긴 로딩 시간과 검색엔진 최적화(SEO) 문제라는 두 가지 문제점을 가지고 있다.
이러한 이유 때문에 1990년 중반부터 사용된 static sites에서 영감을 받은 SSR방식이 도입되었다.
하지만 SSR 방식의 도입이 앞의 두 가지 문제점은 어느정도 개선을 할 수 있었지만, 완벽한 솔루션이 되지는 못했다. 그 이유는 첫 페이지 로딩시에 blinking issue와 서버 과부화라는 두 가지 문제점 때문이었다. 또한 초기에 화면이 빠르게 로딩되더라도 사용자와 interact하기 위한 대기시간이 필요(화면이 로딩되어 클릭을 했는데 아무런 반응이 일어나지 않는 경우)했고, 이 부분을 이해하기 위해서는 이번 포스팅에서 다룰 TTV(Time To View)와 TTI(Time To Interact)의 개념에 대해서 알고 있어야 한다.
