CSR (Client Side Rendering)
- 렌더링이 클라이언트쪽에서 발생하는 방식
- 클라이언트에서 화면을 구성하는 방식
- 서버가 요청을 받으면 클라이언트에 html, js를 보내줌, 클라이언트는 응답을 받아서 렌더링 시작
- 서버에서 처리하지 않고 클라이언트로 보내줌 → js가 모두 다운로드되고 실행이 끝나기 전까지는 사용자는 볼 수 있는게 없다
- SPA에서 쓰이는 기법 (react, vue 등)
- 첫 화면에 들어갈 때, 데이터를 제외한 화면을 그리는 코드가 프론트로 전달된다
- 데이터를 제외한 코드들이 js파일에 한번에 번들로 옴 → 처음 다운받는데 시간이 걸린다 ☹️
- 해결 방법 : code splitting
- 클라이언트 요청이 발생하면 필요한 데이터만 백엔드에서 요청해서 데이터만 받아옴
SSR (Server Side Rendering)
- 서버쪽에서 렌더링 준비를 끝낸 상태로 클라이언트에게 전달하는 방식
- 서버에서 이미 ‘렌더 가능한 상태’로 클라이언트에게 전달 → js가 다운로드되는 동안 사용자는 무언가를 볼 수 있음
차이점
- 웹페이지 로딩 시간
- 첫 페이지 로딩 시간
- CSR : html, css, 모든 스크립트를 한번에 불러옴
- SSR : 필요한 부분의 html, 스크립트만 불러옴 → 빠르다
- 나머지 페이지 로딩 시간
- CSR : 이미 첫 페이지 로딩할 때 나머지 코드를 받아둠 → 빠르다
- SSR : 첫 페이지 로딩 과정을 다시 실행함 → 느리다
- SEO 대응
- CSR : 자바스크립트를 실행시켜 동적으로 컨텐츠 생성 → 자바스크립트 실행돼야 metadata 변경됨
- SSR : 애초에 서버에서 컴파일되어 클라이언트로 넘어옴 → 크롤러에 대응하기 용이
- 서버 자원 사용
- CSR : 클라이언트가 더 부하 많음 → 서버 부하 적음
- SSR : 매번 서버 요청 → 서버 자원 더 많이 사용
해결 방안 → Next.js
- CSR, SSR의 단점을 해결하면서 장점도 살리고자 Next.js 프레임워크가 생김
- 첫 페이지는 백엔드 서버에서 렌더링 → 데이터가 채워진 html을 받아와서 SEO 문제 해결
- 다음 페이지부터는 CSR방식 → 필요한 데이터 부분만 갱신해서 서버의 부하를 덜어줌
