🔗 참고 링크
렌더링은 요청받은 내용을 브라우저 화면에 표시하는 것입니다.
XMLHttpRequest
등장했습니다.클라이언트에서 렌더링 하는 방식입니다.
서버에서 인덱스라는 HTML 파일을 클라이언트에 보내고, JS가 동작하면서 데이터만을 주고 받아서 클라이언트에서 렌더링을 진행합니다.
request data
)해서 데이터 받아옵니다.이런 문제점 때문에 SSR이 도입됩니다.
클라이언트에서 모든걸 처리했던 방식과는 다르게 서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들게 되고 이렇게 잘 만들어진 HTML 파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에게 보내줍니다.
그러면 클라이언트측에서는 잘 만들어진 HTML문서를 받아와서 바로 사용자에게 보내줄 수 있습니다.
웹 서버에 요청할 때마다 브라우저에서 새로고침이 일어나고 서버에 새로운 페이지에 대한 요청을 하는 방식입니다.
화면 깜빡임 이슈가 여전히 존재합니다.
사용자가 클릭을 하면 전체적인 웹사이트를 다시 서버에서 받아 오늘 것은 동일하기 때문에 썩 좋지않은 사용자 experience를 겪을 수 있습니다.
서버에 과부하가 걸리기 쉽습니다.
특히 사용자가 많은 제품일수록 사용자가 클릭할 때마다 서버에서 필요한 데이터를 가져와서 HTML을 만들어야하기 때문이다.
상호 작용 전에 기다려야 합니다. (치명적 단점)
사용자가 빠르게 웹사이트 확인 가능하지만 동적으로 처리하는 JS를 다운로드 받지 못해서 여기저기 클릭했는데 반응이 없는 경우가 있습니다.
TTV = Time To View
사용자가 웹사이트를 볼 수 있다.
TTI = Time To Interact
사용자가 인터랙션을 할 수 있다.
CRS는 TTV (Time To View) 사용자가 웹사이트를 볼 수 있음과 동시에 TTI (Time To Interact) 클릭을 하거나 인터랙션을 가능하게 됩니다.
반대로 SSR(ServerSide Rendering)은 사이트에 접속하게 되면 서버에서 이미 잘 만들어진 인덱스 파일을 받아 오게 되고 사용자가 웹사이트를 볼 수 있지만 아직 동적으로 제어할 수 있는 자바스크립트 파일은 받아오지 않았으므로 사용자가 클릭을 해도 아무것도 처리할 수가 없게 됩니다.
최종적으로 자바스크립트 파일을 서버에서 받아 와야지만 그때부터 사용자의 클릭을 처리할 수 있는 인터랙션이 가능해집니다.
그래서 SSR은 사용자가 사이트를 볼 수 있는 시간과 실제로 인터렉션을 할 수 있는 시간의 공백 기간이 꽤 긴편입니다.
CSR을 정말 많이 사용하는 사람이라면 우리가 최종적으로 번들링 해서 사용자에게 보내주는 자바스크립트 파일을 어떻게 하면 효율적으로 많이 분할해서 첫 번째로 사용자가 보기 위해서 필요한 정말 필수적인 아이만 보낼 수 있는지 고민해보는게 좋을 것 같고,
SSR 같은 경우는 사용자가 보고, 인터렉션 하는 이 시간의 단차를 줄이기 위해서 어떤 노력을 할 수 있을지 , 우리가 어떻게 조금 더 매끄러운 UI와 UX를 제공할 수 있을지 고민해 보면 좋을 것 같습니다.
그리고 요즘에는 꼭 CSR 또는 SSR 만을 고집해서 사용기보다는 SSG도 있습니다.
리액트 같은 경우는 CSR에 특화된 라이브러리지만 개츠비 라이브러리와 함께 사용하면 리액트로 만든 웹 어플리케이션을 정적으로 웹페이지를 생성을 미리 해둬서 서버에 배포에 둘 수 있습니다.
그리고 이렇게 만들어진 웹사이트들은 모두 다 정적인건 아닙니다. 우리가 추가적으로 데이터를 서버에서 받아오거나 또는 동적으로 처리해야 되는 로직이 있다면 자바스크립트 파일을 함께 가지고 있을 수 있기 때문에 동적인 요소도 충분히 추가 할 수 있습니다.
개츠비 다음으로 리액트에서 많이 사용되는 것이 Next.js입니다.
Next.js는 강력한 SSR을 지원하는 라이브러리 였는데 요즘에는 SSG도 지원하고 CSR과 SSR을 잘 섞어서 조금 더 강력하고 유연하게 우리에 목적에 맞게 사용할 수 있도록 지원해주고 있습니다.