SSR
server side rendering 의약자
서버 쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식
User가 Website 요청 보냄 → Server는 ‘Ready to Render’ 즉시 렌더링 가능한 html 파일을 만든다.
→ 클라이언트에 전달되는 순간 이미 렌더링 준비가 완료 되어있기 때문에 html은 즉시 렌더링 된다.(javascript가 읽히기 전) → 클라이언트가 자바스크립트를 다운받는다. → 브라우저가 Js 프레임워크를 실행 → JS가 컴파일 되면 사용자 조작과 웹페이지 상호작용이 가능
- 클라이언트가 페이지를 이동한다든가, 클릭으로 인한 다른 요청이 생길때마다 이 과정을 반복하기 때문에 화면에서 바뀌지 않아도 되는 부분도 계속해서 다시 렌더링되는 단점이 있다. 이는 곧 서버 부하 등의 문제를 일으킬 수 있다.
CSR
렌더링이 클라이언트 쪽에서 일어난다. 서버는 요청을 받으면 클라이언트에 html과 js를 보내준다. 클라이언트는 그것을 받아 렌더링을 시작한다.
User가 Website 요청을 보냄 → CDN(콘텐츠 전송 네트워크)이 html 파일과 js로 접근할 수 있는 링크를 클라이언트로 보낸다. → 클라이언트는 html과 js를 다운 → js가 실행, api가 호출 → 서버가 api로 부터의 요청에 응답 → api로부터 받아온 data를 placeholder에 넣어준다. 상호작용 가능
차이
- 웹페이지 로딩시간
CSR의 경우 첫페이지는 길고 나머지는 짧다,
SSR의 경우 첫페이지는 짧고 나머지는 더 느리다.
- SEO 대응
SSR은 크롤러에 대응 용이
- 서버자원 사용
SSR이 서버 자원을 더 많이 사용. 매번 서버에 요청하기 때문
사용 권장
SSR
- 네트워크가 느릴 때
- 검색 엔진 최적화가 필요할 때
- 최초 로딩이 빨라야 할 때
- 메인 스크립트가 클 때
CRS
- 네트워크가 빠를 때
- 서버의 성능이 좋지 않을 때
- 데이터의 양이 많을 때(로딩창을 띄울 수 있다.)
- 메인 스크립트가 가벼울 때
- SEO 없을 때
⇒ Nest.js를 사용하여 첫페이지는 백엔드 서버에서 렌더링하여 빈 html이 아닌 데이터가 채워진 html을 받는다. 그 다음 페이지 부터는 CSR 방식으로 필요한 데이터 부분만 갱신해 서버의 부하를 줄인다.
