[20장] 서버 사이드 렌더링

서버 사이드 렌더링이란 UI를 서버측에서 렌더링한 후 사용자에게 페이지를 보여주는 것을 말한다.

1. SSR 장단점
1) 장점

• High SEO (Serach Engine Optimization) : 구글, 네이버, 다음 같은 검색 엔진들은 html 파일의 타이틀, 메타태그, 링크 등등을 분석하면서 페이지 정보 수집과 검색엔진 등록을 수행한다. 그런데 CSR의 경우 html은 공허한 무언가일뿐 본체는 JS파일이라 검색 엔진들이 이 페이지가 대체 뭔지 제대로 알아먹질 못한다(물론 구글신께선 일정부분까지 가능하긴 함)
• 유저경험 : 사용자가 페이지에 접속했는데 로딩창만 한 세월 처다보고있으면 불-편할 것이다. CSR의 경우 JS파일까지 전부 보내야 화면이 나타나므로 초기 로딩시간이 길어지나, SSR은 당장에 화면은 보이므로 유저 경험이 더 좋은 편

2) 단점

• 서버 과부하 : 원래라면 브라우저가 해야했을 일을 서버가 하다보니 부하가 커진다. 특히 유저가 많을수록 서버가 감당해야할 부하가 급격히 늘어나므로 캐싱과 로드 밸런싱이 매우 중요해진다.
• 코드 스플리팅 충돌(bliking issue) : SSR은 JS가 다 로드가 안돼도 적당히 읽어서 html파일을 채워주는데 막상 JS파일을 받을때가 되고나니 JS가 '어? lazy하게 로드할거니까 이 컴포넌트는 null임 ㅅㄱ' 해버리니 갑자기 보이던 화면이 null로 바뀌면서 안보이게 된다.
• TTV와 TTI 간극 : 사용자가 뭔가 상호작용하는 일이 엄청 중요한 페이지인데 보이기만 보이고 정작 눌리지 않는다면 차라리 상호작용이 가능한 순간까지 안보이고 마는게 낫다.

사실 SSG(Static Site Generation)도 있는데, 대강 리액트로 만든 파일들중 일부를 정적인 html파일로 만들어서 배포하고, 동적인 부분은 JS파일로 남겨두는 흐름이다. React와 Gatsby를 함께 쓰면 가능한데 요새는 NEXT.js도 이 기능을 지원한다.

실제 서버 사이드 렌더링을 진행하는 과정은 정리하지 않았다. 웹팩과 express라이브러리 사용에 능하지 않다면 책의 내용만으로는 그저 무의미한 받아쓰기가 되는 형국이라 이 장은 여기까지만 정리하도록 한다.