이전에 React 프로젝트를 블로그를 개발하다가 기능을 더 확장시켜 다른 프로젝트로 변경하게 되어 개발을 멈추게 된 적이 있습니다. 멈추게 된 김에 이 React 프로젝트를 Next.js로 바꾸면서 간단하게 CSR과 SSR의 차이를 비교해 보았던 경험을 이야기하고자 합니다. 또한 개인 프로젝트 몇 개가 '실은 SSR이 더 적합한 사이트일 수도 있지 않을까?'라는 생각이 들게 되었고 그 차이에 대해 이번 기회에 알아보는 게 좋을 것 같다는 생각이 들었습니다.
물론 React로 SSR 구현이 가능하고, Next.js로도 CSR 구현이 가능합니다만, 간략하게나마 그 차이를 알아보고 싶어 작성하게 되었습니다.
🔍 CSR과 SSR의 이해
1. CSR(Client Side Rendering)
- 서버에서 빈 페이지를 최초로 렌더링 하고 사용자가 요청할 때마다 클라이언트에서 렌더링
- 서버와 완전히 분리
- 페이지 이동 시 깜박임이 없어 UX적으로 좋음
- JavaScript를 다운로드하고 해석하는 시간만큼 렌더링이 딜레이 됨
- CSR은 HTML이 JavaScript 로직에 연결된 상태라 TTV, TTI 사이 간극이 없음
- TTV(Time To View): 사용자가 콘텐츠를 볼 수 있는 시점
- TTI(Time To Interactive): 사용자가 페이지와 상호작용할 수 있는 시점
- CSR은 HTML이 JavaScript 로직에 연결된 상태라 TTV, TTI 사이 간극이 없음
- 초기 로딩 이후는 서버에 변경된 데이터만 요청하면 되기에 구동 속도가 빠름
- 서버는 빈 페이지만 전달하는 역할만 하면 되기에 서버 부하가 적음
- 클라이언트 측에서 연산, 라우팅을 직접 처리하여 반응속도가 빨라 UX가 좋음
- 서버 부하 분산
- SEO(검색엔진 최적화, Search Engine Optimization) 불리하여 검색 엔진에 노출이 필요 없는 페이지에 유리
- 웹 크롤러가 HTML을 읽어서 검색 가능한 색인을 뽑아내지만, CSR에서는 빈 페이지만 읽을 수 있기 때문에 검색 가능한 컨텐츠가 존재하지 않아 불리
2. SSR(Server Side Rendering)
- 서버에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식
- 웹 페이지 접속 시 바로 화면을 볼 수 있고 검색 엔진이 HTML 파일을 해석할 수 있어 SEO 유리
- JavaScript를 다운로드하고 실행하기 전에 사용자가 화면을 볼 수 있어 초기 구동 속도가 빠름
- HTML에 JavaScript 로직이 연결될 때까지 사용자 입력 응답 불가
- TTV, TTI 간극이 존재
- 페이지 이동 시 새로운 HTML 파일을 불러와 화면이 깜박거려 UX적으로 좋지 못 함
- 서버 부하가 CSR에 비해 많은 편
- 높은 트래픽 시 서버 부하 증가
- 누구에게나 동일한 페이지를 보여주고 내용이 자주 바뀐다면 유리
🔍 실제 프로젝트에서의 차이점
Network 탭으로 보는 렌더링 방식
1. CSR 방식의 특징
- 서버에서 빈 페이지(빈 html)를 최초로 렌더링
- 개발자모드 Network탭 Preview에서 확인 불가
- 빈 html에서 JavaScript 파일을 받아와서 실행시키면 그제서야 내용이 만들어짐
- main.chunk.js → App.js → index.js →
ReactDOM.render( <App />, document.getElementById('root')→ html의 root id를 가지고 와서 렌더링 해 줌
- main.chunk.js, bundle.js , 0.chunk.js : 여러 가지 설정 및 화면을 구성하는 코드를 담고 있는 덩어리(Chunk), 자바스크립트 파일 조각
- 비로소 화면이 그려지게 됨
document.createElement()로 태그를 만들어서 붙어 넣음
- 태그가 만들어지니 렌더링 될 수 있는 것
2. SSR 방식의 특징
1. html 파일에 이미 내용들이 들어있음
2. 개발자모드 Network 탭 Preview에서 확인 가능
3. 브라우저가 html 파일을 받자마자 볼 수 있게 됨
4. 렌더링이 서버 측에서 완료
5. 추가로 JavaScript 파일을 받아오면 interactable 해 짐