CSR vs SSR 원리
CSR(클라이언트 사이드 렌더링)
- 브라우저에서 /blog를 요청하면 프론트 서버에서 html, js를 받아오고 데이터가 없으니 로딩창을 띄워주고 그 사이 백엔드에서 데이터를 받아와 보여주게 된다.
브라우저 -> /blog 요청 -> 프론트 서버
브라우저 <- js, html, css, img <- 프론트 서버
- 한번 더 백엔드 서버로 /posts(게시글) 요청을 보낸다. 브라우저에서는 로딩창을 없애고 백엔드 서버에서 받은 데이터를 화면에 그려준다.
브라우저 -> /posts 요청 -> 백엔드 서버 -> 데이터베이스
브라우저에서 렌더링을 수행하는 방식으로 서버에서 전체 페이지를 한번 렌더링하여 보여주고 백엔드 서버로 요청을 보내 백엔드 서버에서 받은 데이터를 화면에 렌더링해준다.
SSR(클라이언트 사이드 렌더링)
- 전통적인 방식은 (SSR) 브라우저에서 페이지 요청을 보내면 프론트 서버 -> 백엔드 서버로 바로 데이터를 요청하고, 데이터베이스에서 데이터를 받아와서 프론트서버로 보내주고, 프론트 서버는 Html, 데이터를 합쳐서 브라우저로 보내준다.
첫 방문만 서버에서 데이터까지 모두 포함해 페이지를 구성해 브라우저(클라이언트)에게 전달하게 된다. 첫 방문 후에는 백엔드에서 데이터만 받아오게 된다.
브라우저 -> /blog 요청 -> 프론트 서버 -> /posts 요청 -> 백엔드 서버 -> 데이터 베이스
CSR VS SSR 장단점
CSR 단점
- CSR은 사용자가 첫 화면을 보기까지 시간이 오래 걸리고 SEO 문제가 있는데, 구글, 네이버 같은 검색 엔진은 웹사이트의 HTML문서를 분석해서 웹사이트를 빠르게 검색할 수 있게 해주는데 구글은 구별이 가능하지만, 네이버와 같은 검색사이트에서는 구별하지 못해 분석하는데 어려움이 있다.
이러한 문제점으로 SSR을 도입하게 된다.
SSR 단점
- SSR은 사용자가 새로고침 하게 되면 전체 웹사이트를 다시 서버에서 받아와야 하므로 화면이 없어졌다 사라지는 단점이 있고, 사용자가 많은 제품일수로 서버에 데이터를 요청하는 횟수가 많아 과부화에 걸리기 쉽다.
NEXT
- 첫 페이지만 데이터까지 모두 받아오고, 이후에는 CSR 방식으로 동작하게 된다. CSR 방식으로 동작할 때, 방문하지 않은 페이지까지 모두 가져오는 것은 비효율 적이므로
코드 스플릿팅기술(js파일을 쪼개서 해당하는 페이지만 받아오게)로 방문한 페이지에 대한 코드만 보내주게끔 해준다. - 사용자가 링크를 통해 들어갈 경우는 로딩창이 보이게 된다.
- 검색엔진이 필요하고 고객들이 접근하는 페이지를 리액트로 만드는 경우는 NEXT가 유리하다.
Next를 사용하지 않아도 될 경우
- 어드민 페이지
프론트엔드 개발자