.png)
CSR
처음에 웹서버에 요청할 때 데이터가 없는 문서를 반환한다.
HTML 및 static파일들이 로드 되면서 데이터가 있다면, 데이터 또한 서버에 요청하고 그것이 화면상에 나타나게 된다.
Browser가 서버에 HTML과 static파일을 요청한 후 로드되면 사용자의 상호작용에 따라서 javascript를 통해 동적으로 Rendering한다. 필요에 따라 데이터를 서버에 요청해서 받아와 Rendring한다.
SSR
완전하게 만들어진 HTML파일을 받아오고 Rendering하게 된다.
웹서버에 요청할때 마다 Browser 새로고침이 일어나고 서버에 새로운 페이지에 대한 요청을 하는 방식.
SSR과 CSR 비교
- 초기 View로딩 속도
-
SSR의 경우 View를 서버에서 렌더링 하여 가져오기 때문에 첫 로딩이 매우 짧다.
-
물론 JS파일을 모두 다운로드하고 적용하기 전까지는
그 어떤 인터랙션에도 반응하지 않지만 사용자 입장에서는 로딩이 매우 빠르다고 느낄 수 있다. -
반면 CSR의 경우 서버에서 View를 렌더하지 않고
HTML 다운 + JS파일 + 각종 리소스 다운을 받은 후 브라우져에서 렌더링을 하기 때문에
SSR보다는 초기 View 로딩 속도는 오래걸린다.
- SEO 문제
- SEO(검색 엔진 최적화)의 문제가 존재한다.
CSR방식으로 이루어진 사이트에서는 View를 생성하기위해 자바스크립트를 실행시켜야 한다.
하지만 대부분의 웹 크롤러 봇들은 자바스크립트 파일을 실행시키지 못한다. - 때문에 HTML 에서만 콘텐츠를 수집하게 되고 CSR 페이지를 빈 페이지로 인식하게 된다.
- 보안 문제
-
SSR에서는 사용자에 대한 정보를 서버 측에서 세션으로 관리를 했다.
-
그러나 CSR일 경우 쿠키말고는 사용자에 대한 정보를 저장할 공간이 마땅치 않다
Next js는 여러가지 유용한 기능을 기본 으로 제공
- Server Rendering
- Static Exporting
- Zero Configuration
- CSS in JS 등
SSR (Server Side Rendering)을 기본으로 사용
파일 시스템 기반의 라우팅 기능을 제공
Next js 모든 페이지 사전 렌더링 (Pre-rendering)
더 좋은 퍼포먼스
검색엔진 최적화(SEO)
- 정적생성
- Server Side Rendering (SSR, Dynamic Rendering)
차이점은 언제 html 파일을 생성하는가
[정적생성]
- 프로젝트가 빌드하는 시점에 html 파일들이 생성
- 모든 요청에 재사용
- 퍼포먼스 이유로, Nest js는 정적 생성을 권고
- 정적 생성된 페이지들은 CDN에 캐시
- getStaticProps / getStaticPaths
[서버사이드 렌더링]은 매 요청마다 html 을 생성
- 항상 최신 상태 유지
- getServerSideProps
when to use Static?
- 마케팅 페이지
- 블로그 게시물
- 제품 목록
- 도움말, 문서
(미리 만들어 두는 경우)
when to use Server-Side Rendering?
- 항상 최신 상태 유지
- 관리자 페이지
- 분석 차트
출처:
https://www.youtube.com/watch?v=Ujjdn2wMIew&list=PLZKTXPmaJk8Lx3TqPlcEAzTL8zcpBz7NP&index=1
https://nextjs.org/
https://goodgid.github.io/Server-Side-Rendering-and-Client-Side-Rendering/
