SSR(Server Side Rendering)
클라이언트(브라우저)가 데이터를 요청하면 브라우저 => 프론트 서버 => 백엔드 서버 => 데이터베이스를 거쳐 데이터베이스에서 데이터를 가져온 후 다시 브라우저에 데이터가 그려지는 형식이다.
이 방식은 서버에서 데이터까지 모두 포함하여 페이지를 구성한 후 브라우저에 전달하는데 클라이언트가 페이지를 이동하다든가, 클릭으로 인한 다른 요청이 생길때마다 이 과정을 반복하기 때문에 화면에서 바뀌지 않아도 되는 부분도 계속 다시 렌더링되는 단점이 있다. 이는 곧 서버 부하 등의 문제를 일으킬 수 있다.
서버에서 이미 렌더 가능한 상태로 클라이언트에 전달되기 때문에 JS가 다운로드 되는 동안 사용자는 무언가를 보고 있을 수 있다.
CSR(Client Side Rendering)
CSR은 react, vue 등의 SPA(Single Page Application)에서 쓰이는 기법으로, 서버에서 화면을 구성했던 SSR 방식과 달리 클라이언트에서 화면을 구성한다.
SPA의 경우 첫 화면에 들어가게 되면, 데이터를 제외한 화면을 그리는 코드들이 프론트 서버에서 다운받아 진다.(데이터를 제외한 코드들은 js파일에 한번에 번들되어 오기때문에 번들된 이 파일을 처음에 다운받는데 시간이 꽤 걸릴 수 있다. CSR방식의 단점 => 초기 진입속도가 SSR에 비해 느리고 code splitting이라는 기능으로 어느정도 해결 가능)
화면을 그리는 코드는 다운받았지만 아직 데이터를 다운 받은 상태가 아니다. CSR의 경우 클라이언트의 요청이 발생하면 필요한 데이터만 백엔드 서버에 요청하여 데이터만 받아온다.
CSR은 초기 진입 속도가 느린 반면, 그 후론 필요한 데이터만 갱신하면 되기때문에 SSR방식에 비해 서버 부하가 덜하다는 장점이 있다.
하지만 초기에 html에 데이터가 없다보니 검색 봇이 해당페이지를 빈페이지로 착각하여 SEO(Search Engine Optimization) 검색엔진 최적화에 취약하다.
어떤 것을 사용해야 하는가?
SSR
- 네트워크가 느릴 때(CSR은 한번에 모든 것을 불러오지만 SSR은 각 페이지마다 나눠서 불러오기 때문)
- SEO가 필요할 때
- 최초 로딩이 빨라야하는 사이트를 개발할 때
- 메인 스크립트가 크고 로딩이 매우 느릴때 CSR은 메인스크립트가 로딩이 끝나면 API로 데이터 요청을 보낸다. 하지만 SSR은 한번에 요청에 아예 렌더가 가능한 페이지로 돌아온다.
- 웹 사이트가 상호작용이 별로 없을 때
CSR
- 네트워크가 빠를 때
- 서버의 성능이 좋지 않을 때
- 사용자에게 보여줘야 하는 데이터의 양이 많을 때
- 메인 스크립트가 가벼울 때
- SEO에 관심이 없을 때
- 웹 어플리케이션에 사용자와 상호작용할 것들이 많을 때
두 방식의 문제를 해결
Next.js
CSR과 SSR의 단점을 해결하면서 두 방식의 장점을 살리고자 Next.js라는 프레임워크가 생겼다.
Next.js를 사용하여 첫 페이지는 백엔드 서버에서 렌더링하여 빈 html이 아닌 데이터가 채워진 html을 받아 검색최적화 문제를 해결하고 그 다음 페이지부턴 CSR방식을 적용하여 필요한 데이터 부분만 갱신해 서버의 부하도 줄였다.
