.png)
설정이 필요없는 데다가 라우팅이 자동으로 되고 쿼리값을 숨길수도 프로퍼티를 추가할 수도 있다는 점, 특유의 정갈하고 깔끔한 분위기 등등...🤩
일단 그 차이점에는 정확히 알아야하니 정리해보는 과거와 현재의 렌더링 방식들✨
1990s static sites
서버에 이미 배포되어있는 HTML 문서를 받아와 렌더링하는 방식, 페이지를 이동할 때 다시 서버에서 해당페이지의 HTML을 받아와서 페이지전체가 업데이트해야 하는 문제점이 있었다.
1996 i-frame
문서를 부분적으로 업데이트하는 것이 가능해졌다.
1998~ XMLHttpRequest
서버에서 필요한 데이터만 JSON 형태로 받아와서 동적으로 html을 생성하여 페이지에 업데이트하는 방식으로 사용할 수 있게 되었다.
2005~ AJAX
사용자가 한 페이지 내에서 머무르면서 필요한 정보만 부분적으로 업데이트하는 싱글페이지 어플리케이션SPA가 널리 사용되게 되었다.
클라이언트 사이드 렌더링(CSR)
클라이언트에서 페이지를 모두 구성해 보여주는 방식으로 유저는 루트에 구성된 전체화면을 본다. 실질적으로는 비어있는 디브<div id="root"> 이기 때문에 초기접속시 빈 화면만 보게 되고, 링크된 자바스크립트 어플리케이션을 서버로부터 다운받게 되는데 여기에는 어플리케이션에 필요한 로직 뿐 아니라 프레임워크와 라이브러리의 소스코드가 모두 포함되어있어 전체화면이 구성되는 데 시간이 걸리게 된다. 또, 추가로 필요한 데이터가 있다면 서버에 요청해서 데이터를 받아온 다음 이것을 기반으로 동적으로 html을 생성해서 최종적인 화면을 보여주게 된다. 때문에 사용자가 최종적인 화면을 보기까지 시간이 오래걸린 다는 점과 비어져있는 html body로 SEO에 최적화되어 있지 않다는 점이 단점이 된다. 그래서 90년대의 static 사이트에서 영감을 받은 서버사이드 렌더링(SSR)이 등장하게 된다.
서버사이드 렌더링(SSR)
서버에서 필요한 데이터를 모두 가져와서 html을 만들고 html을 동적으로 제어할 수 있는 소스코드와 함께 클라이언트로 보내주고, 클라이언트에서는 구성된 html을 바로 화면에 렌더링한다. 때문에 CSR보다 초기화면 로딩이 빨라지고 SEO를 효율적으로 사용할 수 있게 된다. 다만 90년대 정적인 사이트와 같이 화면이 전환되면서 깜빡임이 발생하고 사용자가 서버에 요청할 때마다 필요한 데이터를 가져와서 html을 만들어야 하기 때문에 과부하가 발생하기 쉽다. 또 동적으로 데이터를 처리하는 자바스크립트 코드가 다운로드 되는 시간과 간격이 생겨서 사용자가 빠르게 렌더링된 화면을 클릭해도 반응이 없는 경우가 있을 수 있다. (실질적으로 유저와 인터렉팅을 하는 데 까지 시간이 걸린다.)
TTV Time To View
TTI Time To Interact
CSR의 경우 TTV가 되면서 TTI가 동시에 가능한 한편
SSR의 경우 TTV가 빠르게 되지만 TTI가 되는 데에 시간이 걸리는 것이다. 그래서 CSR의 경우 코드스프릿 방법을 이용해서 필요한 데이터만 빠르게 내보낼 수 있는 방법에 대해 고민해보고 SSR의 경우 TTI 가능한 시간의 간격을 어떻게 해야 줄일 수 있을 지에 대한 고민이 어플리케이션의 성능과 사용자 UI/UX를 향상시킬 수 있는 방향이 될 것이다.
스태틱사이트 제너레이션(SSG)
개츠비, Next.js와 같은 라이브러리를 사용하여 리액트로 만든 웹 어플리케이션을 정적으로 미리 생성해두고 서버에 배포하고 동적인 요소를 추가하는 방식이다. 특히 Next.js는 하이브리드 방식으로 데이터를 가져오는 방법을 여러가지 방법으로 지원하고 있다.
드림코딩 엘리 서버사이드 렌더링
https://www.youtube.com/watch?v=iZ9csAfU5Os
