210510 TTV, TTI, SSG의 개념


이번 포스팅에서는 개발자라면 상식으로 알고 있어야 하는 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)의 개념에 대해서 알고 있어야 한다.

  • TTV(Time To View)와 TTI(Time To Interact)

    TTV란 사용자에게 페이지가 보여지기 위한 시간을 의미하며, TTI란 사용자와 상호작용이 가능(Interactable)하기까지의 시간을 의미한다.
    CSR의 경우에는 처음에 서버로부터 빈 html파일을 받아오고, 이후에 별도의 서버 요청에 의해 웹 페이지에서 필요한 모든 로직들이 담긴 자바스크립트 파일들(동적으로 html을 생성할 수 있는 웹 어플리케이션 로직이 담겨져 있는 자바스크립트 파일들)을 받아오게 된다. 바로 이 시점에서 사용자는 페이지를 볼 수 있게 되고 동시에 상호작용이 가능하게 된다.
    이처럼 CSR은 TTV와 TTI의 시점이 일치한다.

    반면에 SSR의 경우에는 초반에 서버 사이드에서 완성된 html 파일을 받아와서 화면에 렌더링을 해주기 때문에 사용자는 바로 페이지를 확인할 수 있다.(TTV) 하지만 아직 동적으로 제어할 수 있는 자바스크립트 파일은 받아오지 않았기 때문에 렌더링된 페이지를 클릭해도 사용자와 아무런 상호작용이 일어나지 않게 된다. 따라서 이후에 동적으로 처리하기 위한 별도의 자바스크립트 파일을 서버에 요청을 해서 받아온 이후에 비로소 사용자와 상호작용이 가능한 웹 페이지가 구성이 된다.(TTI)
    이처럼 SSR은 TTV와 TTI의 시점이 다르다.(공백시간이 존재)

    • 웹 사이트 성능분석을 위한 TTI와 TTV

      CSR 방식으로 웹 어플리케이션을 개발을 할때에는 사용자에게 최종적으로 번들링해서 보내주는 자바스크립트 파일들을 효율적으로 분할(code splitting)해서 첫 페이지 로딩시에 필요한 자바스크립트 파일들만 보내도록 구성하는 작업이 필요하다.
      반면에 SSR은 TTV와 TTI 간에 존재하는 시간 공백을 어떻게 하면 효율적으로 줄일 수 있는지 고민해야 한다.

SSG (Static Site Generation)

요즘에는 SSR, CSR만을 고집하지 않고 SSG 방식으로 개발을 한다. 예를들어 React를 SSR에 최적화된 Gatsby 라이브러리와 함께 개발을 하게 되면, 정적으로 웹 페이지를 생성을 해서 서버에 미리 배포해 둘 수 있다.
하지만 모든 페이지가 정적인 것이 아닌, 추가적으로 데이터를 서버로부터 받아오거나 동적으로 처리해야 되는 부분이 있다면, 페이지와 함께 자바스크립트 파일을 별도로 받아올 수 있기 때문에 동적이 페이지의 처리도 가능하다.
React와 Gatsby 라이브러리의 조합 이외에도 React와 NextJS의 조합으로도 개발이 많이 되고 있다. NextJS는 SSR이외에도 static generation, no pre-rendering, pre-rendering을 지원을 하기 때문에 SSR과 CSR을 적절히 조합을 해서 웹 어플리케이션을 개발을 할 수 있다.

웹 어플리케이션을 개발을 할 때, TTV와 TTI를 고려해서 적절하게 SSR, CSR, SSG의 방식을 조합해서 개발을 한다면 사용자에게 좋은 사용감을 주는 웹 어플리케이션을 개발할 수 있다.
앞으로 개인적으로 하는 사이드 프로젝트도 이러한 사용자의 편의성을 염두해두고 진행을 해봐야겠다.

참고 :https://huspi.com/blog-open/definitive-guide-to-spa-why-do-we-need-single-page-applications