CSR(Client Side Rendring)
HTML 문서에서 모든 데이터를 받지않고, 기본적인 정보만 담고있는 뼈대를 사용하여 자바스크립트 파일과 연결한 뒤, 나머지 웹 페이지를 렌더링합니다.
작동원리
1. 유저가 웹페이지에 접근요청
2. 서버가 브라우저에 응답
3. 브라우저가 Javascript 파일 다운로드
4. 파일 콘텐츠 실행
5. visible and interactive contents
장점
높은 성능, 속도, 재사용 가능한 컴포넌트
- 성능 - CSR은 요구한(on-demand) HTML을 생성합니다. 일반적인 HTML 페이지 처럼 전체 페이지를 리랜더링하지 않습니다. 개별 페이지로 동작하는 것처럼 보일 수 있지만, 사실 페이지의 콘텐츠를 렌더링합니다. 이러한 이유로 계산이나 RAM을 많이 아낄 수 있고, SSR 보다 빠릅니다.
- 속도 - CSR은 보여주는 HTML만 생성합니다. 즉, DOM은 보이는 HTML 부분의 콘텐츠를 포함한 코드만을 가지고 있습니다. 그렇기 때문에 DOM은 쉽게 요소들을 핸들링할 수 있습니다. DOM이 갖고있는 코드가 많다고 하더라도, 렌더 시간이 오래걸리지 않습니다. lazy loading 덕에 CSR은 SSR보다 빠릅니다.
- 재사용 가능한 컴포넌트 - CSR을 사용하면 서버에 매번 요청하지 않고도 여러 페이지나 루트에 사용되는 UI 컴포넌트를 재사용할 수 있습니다. 이로서 페이지의 사용성이 향상됩니다.
단점
느린 초기속도, SEO 이슈, 캐시 이슈
- 느린 초기속도 - CSR은 초기에 모든 자바스크립트를 로딩한 후, API 호출을 통해 db에서 데이터를 받고, HTML을 생성합니다. 초기에 해당 데이터를 로딩하는 것은 SSR보다 시간이 더 걸릴 수 있습니다.
- SEO(검색 엔진 최적화 ) 이슈 - CSR에서는 JS 렌더링, 브라우저 인덱싱시 보통 2번의 과정을 거쳐야 합니다. (two-wave process)
- (frist wave)처음에는 소스 코드를 요청하고,현존하는 HTML에 인덱싱을 합니다. 하지만 CSR의 경우, JS에서 HTML로 컨버팅하는 시간이 걸리기 때문에 HTML이 많지 않습니다.
- (second wave)두번째에는 모든 리소스에 접근이 가능해지면, 브라우저는 추가적인 것들과 검색엔진에 맞는 인덱스를 반환합니다. SSR의 경우 HTML은 처음부터 이용할 수 있기 때문에 해당문제는 일어나지 않습니다.
- 캐싱 이슈 - HTML은 첫 렌더에서 쓸 수 없기 때문에, 브라우저는 HTML 구조를 캐싱할 수 없습니다. 해당 이슈를 피하려면 JS를 캐싱할 수 있지만,JS는 브라우저 메모리의 공간을 많이 차지하기 때문에, 이는 비용이 드는 작업입니다.(costly)
SSR
필요한 것만 담고 있는 작은 HTML 문서를 가지고 있는 게 아니라, 첫 페이지를 렌더링하는 과정을 서버가 담당합니다.그리고 브라우저는 자바스크립트를 처리하고, static HTML 에 렌더링을 합니다.
작동원리
1. 유저가 웹페이지에 접근요청
2. 서버가 준비한 HTML 파일 전송
3. 브라우저는 페이지를 렌더링하지만 interactive하진 않음
4. 브라우저가 자바스크립트를 다운로드
5. 자바스크립트 실행
6. interactive contents
SPA 웹앱에서 왜 SSR이 필요한가요?
- 초기 페이지 렌더링이 빠릅니다.
- 모든 HTML 페이지를 인덱싱할 수 있습니다.
➡️ 페이지가 처음 로딩될때 deep link들이 있는 콘텐츠가 많은 사이트에 좋을 수 있습니다.
Next.js 처음으로 세팅하기
해당 명령어로 next 를 시작합니다.
yarn create next-appyarn start 명령어 시 실행되는 파일: https://github.com/vercel/next.js/blob/canary/packages/next/cli/next-start.ts
cli에서 프로덕션 서버 실행을 위해 명령어를 입력하면 실행되는 파일인 것 같고, 빌드를 하지 않고 바로 실행하려고 하니, 앱을 먼저 빌드하는 에러가 뜹니다.
참고
