CSR (Client Side Rendering)
•
Client는 브라우저를 뜻한다
•
전에 작성한 웹 렌더링에 대한 내용을 토대로 말해보자면 DOM -> RenderTree -> Layout -> Paint -> Render 의 순서로 브라우저가 랜더링을 하는데 이때, DOM은 HTML을 파싱해서 나오게 되는 결과물이다. 이 HTML을 작게 가져가고 JS를 통해서 DOM 을 생성해서 DOM을 HTML에 그려주는게 CSR이다
•
이 특징의 대표적인건 HTML의 크기가 현저히 낮아진다. 대신에 JS의 크기가 커진다는 단점이 있다
•
HTML의 크기가 줄어들기 때문에 최초의 접속시 리소스를 다운받기 까지의 속도가 빠르기 때문에 로딩까지 접근하는 속도가 빠른 장점이 있다.
•
한편으로는 JS에서 DOM을 만들어주기 때문에 필요한 DOM을 그때 그때 만들어서 쓸 수 있다는 것에 전제하에 있다
◦
이때 History API를 사용해서 Route처리를 하고 DOM을 이용해서 Render를 수행한다
우리가 알고 있는 CSR?
•
대표적으로는 리엑트, 앵귤러, 뷰 가 있다
◦
기본적으로 CSR을 사용한다고 볼 수 있다
Client Side Rendering은 왜 나왔을까?
•
예전에는 페이지 A -> 페이지 B로 넘어가는 과정이 부자연스러웠다
◦
이유:
▪
흰색화면이 노출
▪
데이터를 갱신할때마다 새로고침을 해야함
◦
전통적인 웹방식이다
CSR은 현대의 프론트엔드에게는?
•
땔수 없는 관계이다
•
이때 가장 주의해야하는 점은 JS의 번들사이즈가 커진다는 단점을 꼭 주의해야한다.
◦
이 때문에 코드스플리팅, layout작업 최소화 등 여러 작업을 진행해야한다
•
그리고 번들사이즈가 커진다는건 브라우저의 컴퓨팅파워를 많이 쓰게 된다
◦
이 점에서 가장 유의깊게 생각해야하는건 브라우저의 컴퓨팅파워를 쓴다는 말은 곧 랜더링의 속도가 저하될 수 있다는 말인 것 같다
CSR의 장점은?
•
한번 렌더링을 완료했으면 필요한 부분만 다시 렌더링을 하면 된다
◦
그렇기 때문에 유저의 경험에 많은 영향을 끼치는 것 같다
CSR이 필요없는 경우?
•
Blog, Article(ex: News)과 같은 경우 실시간으로 보여줄 필요가 없는 경우가 많기 때문에 CSR이 꼭 필요한 건 아니라고 한다
반대로 CSR이 필요한 경우?
•
유저에게 실시간성으로 데이터를 제공해야하고, 상호작용을 해야하는 부분에 대해서는 CSR은 좋은 선택일 수 있다고 생각한다