서버컴포넌트
클라이언트 사이드 랜더링:
빠르게 유저와 상호적용 할수 있지만 초기로당시간이 걸려, 유져가 실제로 원하는 를 볼려면 텅빈 화면을 기다려여함
ssr
렌더링 주체가 서버 => 즉 서버에서 렌더링을 마치고 완전하게 만들어진 html파일을 브라우저로 전달한후 렌더링하는 방식
장점
페이지 로딩시간이 빠림
Seo 에 조음
- 실시간 데이터 보여줌
단점
요청마다 html 생성(뷰가 바뀔때마다) ssg sir 보다는 느림, 새로고침이 많음, 서버부담, cdn 캐시가 이루어지지 않음
SSG
빌드 시에 정적인 html을 만들고 각각의 요청시 html을 재사용!!!!!!
SSG에서 HTML은 next build 명령어를 사용할 때 생성됩니다.
그 후에는 CDN으로 캐시가 되어지고 요청마다 HTML을 재사용
ISR(incremental static regeneration )
ssg에 포함되는 개념 ssg와 차이는 설정한 시간마다 새로 렌더링!!!
서버 측에서 주기적으로 html을 서버에서 생성해 두고 내러줌(처음 빌드 시점에 만들어 두고, 설정한 주기마다 다시 렌더링 하여 html을 생성해 둔다)
csr과 달리 초기에 빠르게 컨텐츠를 볼수 있다는 개선점은 있나 역시나 ssr의 문제점은 워터풀 문제
모든 데이터는 보여지기전 서버에서 반드시 패치되어야한다
모든 자바스립트가 로드 된후에 페이지를 볼수 있다
모든 하이드레이션이 완료 되기전까지 클라이언트에서 어떤것도 상호작용할수 가 없다
그럼 Suspense를 사용하면 모든 문제가 해결되는가... 개선점은 있지만 몇가지 이슈는 남는다!
- 하이드레이션이 최적화되더라도, 유저는 클라이언트 사이드 자바스크립트가 다운로드 될 때까지 상호작용하지 못한다.
- 데이터패치를 위해 서버 클라이언트간의 긴 여행이 잇다
... 등등
그래서 이같은 문제를 해결하고자 나온것이 서버컴포넌트!
리액트 서버 컴포넌트
리액트의 새로운 서버 컴포넌트는 서버 사이드 렌더링을 보완하여 자바스크립트 번들에 추가하지 않고도 렌더링 할 수 있게 합니다. 또한, 서버에서만 실행되므로 서버 컴포넌트를 사용하면 UI를 서버에서 렌더 할 수 있고 컴포넌트 내부에서 직접 데이터를 페치할 수 있습니다.
데이터 페칭: 서버 컴포넌트는 데이티 페칭을 데이터 소스와 가까운, 서버로 옮길 수 있게 해줍니다. 이것을 통해 렌더링에 필요한 페치의 소요 시간, 클라이언트에서 만드는 요청의 양을 줄일 수 있습니다.
캐싱: 서버에서 렌더링 되기에, 후속 요청과 유저 전반에 걸쳐 재사용할 수 있습니다.
번들 사이즈: 서버 컴포넌트는 클라이언트 자바스크립트 번들에 영향을 미치는 큰 의존성들을 리졸브 할 수 있습니다. 즉 처리된 결과만을 클라이언트에 전달하므로 클라이언트에서 다운로드하지 않아도 되므로, 인터넷이 느리거나 성능이 좋지 못한 장치를 갖는 유저들에게 유용합니다.
초기 페이지 로드와 First Contentful Paint: 서버에서 HTML을 생성하기에, 클라이언트에서 자바스크립트의 다운로드와 파싱 필요 없이 즉시 페이지를 볼 수 있습니다.
스트리밍: 서버 컴포넌트는 렌더링 작업을 청크 단위로 쪼개고 준비가 되면 클라이언트로 스트리밍 합니다. 유저는 전체 페이지가 서버에서 렌더 되는 것을 기다릴 필요 없이 페이지의 부분을 볼 수 있게 됩니다.
SEO: 렌더 된 HTML은 서치 엔진 봇들에게 수집될 수 있고 소셜 네트워크 봇들이 페이지의 프리뷰를 생성할 수 있게 해줍니다.
