💻 CSR
Client-Side-Rendering
클라이언트가 입력한 것을 수신해서 HTML로 만들어서 크롬과 같은 어플리케이션에 해석해서 표시하는것이다. 대표적인 예로 자바스크립트가 있다.
리액트로 된 웹같은 경우는 페이지소스를 켰을때 아래처럼 뜬다.
즉, 브라우저가 HTML을 가져올 때 비어있는 div로 가져온다. 이후 브라우저가 모든 자바스크립트를 요청하여 브라우저가 자바스크립트와 리액트를 실행시키고 그 이후에야 앱이 유저에게 보이게된다.
🖤 예시
react로 만들어진 애플리케이션을 실행하고 개발자도구의 네트워크에서 disable cache를 체크하고 slow 3g로 바꾸어 새로고침해본다.
제일 처음으로 빈 흰색 화면이 뜨는데 이것은 HTML을 가져올때 텅텅 비어있는 div를 가져오기때문이다.
이후에 점차 애플리케이션이 로딩이되고 실행된다. 클라이언트단에서 애플리케이션을 실행시키고 완성된 UI를 보기까지 시간이 지체된다는 것이다.
💻 SSR
Sever-Side-Rendering
클라이언트에서 모든 것을 처리하지않고 웹사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들게 되고, 만들어진 HTML과 HTML파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에게 보낸다. 클라이언트는 잘 만들어진 HTML문서를 사용자에게 바로 보여주게 된다.
Next로 된 웹같은 경우 페이지소스를 켰을 때 아래처럼 뜬다.
즉, 만들어진 HTMl을 가져왔다는 것을 알 수있다. 그래서 사용자가 매우 느린 인터넷환경을 이용하거나 자바스크립트가 완전히 비활성화되어있어도 완성된 화면을 보일 수 있다.
🖤 단점
1) Blinking Issue
사용자가 새로고침을 하게 되면 웹사이트를 다시 서버에서 받아와야하기 때문에 화면이 없어졌다가 나타난다.
2) 서버 과부화
사용자가 많은 제품일수록 서버에 데이터를 요청하는 횟수가 많아지기 때문이다.
3) TTV(Time To View)와 TVI(Time To Interact)의 공백시간
SSR방식에는 서버에서 만들어진 HTML파일을 가져오게 되고 사용자는 바로 웹사이트를 동적으로 제어할 수 있는 자바스크립트 파일은 아직 받아오지 않았기 때문에 사용자가 클릭을 해도 아무런 처리를 할 수 없는 상태가 된다. 최종적으로 자바스크립트 파일을 받아와야만 원하는 것을 처리할 수 있는 인터렉션이 가능해진다.
즉, SSR은 사용자가 사이트를 볼 수 있는 시간(TTV)와 실게로 인터랙션이 가능한 시간(TVI)의 공백이 꽤 길다는 단점이 있다.
❗ 반대로 CSR은 HTML만 받아왔을 때는 아무것도 보여지지않고 링크되어 있는 모든 로직을 처리하는 자바스크립트 파일을 받아오게되면 웹사이트가 보여지는 동시에 인터랙션이 가능해진다. TTV와 TTI의 공백시간이 없는것이다.
