이전에 React를 공부하면서 CSR, SSR에 대한 정리글을 포스트한 적이 있는데 Next.js 공부를 새로 시작하면서 SSG, ISR까지 알아보고 한꺼번에 다시 정리했다.
클라이언트가 렌더링서버로부터 텅 빈, 즉 ui가 존재하지 않는 html파일을 전달받고 ui를 렌더링하기 위한 react library, js 소스 파일을 다운로드 한 후 페이지를 보여준다.
useEffect 를 통해 데이터를 가져오는 방식이다.
필요한 데이터를 부분적으로 요청해서 업데이트하기 때문에 한번 로딩되면 이후 빠른 응답이 가능하다.
서버의 부하가 적다.
사용자와 어플리케이션 간의 빠른 상호작용이 가능하다.
TTV(Time to View)가 길다.
( = 모든 소스 파일을 받기 때문에 첫 페이지 로딩 속도가 느리다.)
SEO 최적화에 불리하다.
서버로부터 전달받는 html파일은 텅 비어있기 때문에 동적으로 생성되는 콘텐츠가 포함되어 있지 않다.
-> 검색 엔진 크롤러가 동적으로 생성된 콘텐츠를 인식할 수 없다.
보안에 취약하다.
모든 소스 코드를 받고 다루기 때문에 보안에 취약하다.
서버가 렌더링html파일 만들어서 가지고 있다가 클라이언트에서 요청하면 전달해줘서 그대로 보여준다.(재활용)TTV(Time to View)가 짧다.
: 서버에서 미리 만들어서 가지고 있던 html을 전달받기 때문에 페이지 로딩 시간이 짧다.
SEO 최적화에 유리하다.
: 웹 크롤러가 빠르고 효율적으로 확인할 수 있다.
보안에 유리하다.
불필요한 소스 전송이 필요 없기 때문
단점을 해결하기 위해 나온 것이 아래의 ISR(Incremental Static Regeneration)
서버가 렌더링이러한 문제를 해결하기 위해 나온 것이 SSR(Server Side Rendering)
서버가 렌더링클라이언트가 요청하면 html 파일 만들어서 전달getServerSideProps, getStaticProps, getStaticPaths 등을 통해 데이터를 가져온다.
html 파일을 서버에서 만들어서 주기 때문에 TTV(Time to View)가 빠르다.CSR-> 페이지가 로드된 후 API 호출
SSR-> 페이지가 로드되기 전에 API 호출
각각의 특징과 장단점을 고려하여 상황마다 적절한 렌더링 방식을 적용하는 것이 중요할 것 같다. 이후 각 방식별 예제 코드를 작성하여 확인해볼 예정이다.
https://www.philly.im/blog/grokking-data-fetching-in-nextjs
https://velog.io/@sj_dev_js/Next.js-%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B1%B0%EC%9D%98-%EB%AA%A8%EB%93%A0-%EA%B2%83
https://blog.devgenius.io/rendering-strategies-csr-ssr-ssg-isr-a3a203778a96