
📚 CSR vs SSR vs SSG
📕 CSR
소개
- 클라이언트 측에서 페이지 렌더링을 수행하는 방식이다.
- 사용자의 브라우저에서 JavaScript를 사용하여 페이지를 동적으로 생성한다.
- 서버는 빈 HTML 페이지만 제공하고, 이후 데이터 & 페이지를 렌더링하는 역할은 클라이언트가 수행한다.
- 주로 웹 애플리케이션에서 클라이언트 측 라우팅 및 상호작용이 많은 경우에 사용한다.

장점
- 상호 작용성 : 클라이언트에서 페이지를 렌더링 하므로 사용자와의 상호 작용이 빠르게 이루어진다.
- 서버 부하 감소 : 서버는 초기 HTML만 제공하고 이후에는 클라이언트에서 데이터를 로드한다.
- 자연스러운 앱 경험 : 싱글 페이지 애플리케이션 (SPA)으로 구현되는 경우가 많은데, 이는 자연스러운 앱과 유사한 사용자 경험을 제공한다.
단점
- SEO 어려움 : 검색엔진은 JS 실행 후의 콘텐츠를 색인화하기 때문에, 비교적 설정하기 까다롭다.
- 그 외 : 초기 로딩 후 콘텐츠 표시까지 시간이 걸리는 문제, 성능 문제, JS에 의존하는 문제 등이 있다.
📗 SSR
소개
- 서버에서 페이지를 미리 생성한 뒤, 사용자가 요청 할 때마다 페이지를 렌더링하는 방식이다.
- 사용자가 페이지에 접속할 때 서버에서 미리 HTML을 생성하고 클라이언트로 보낸다.
- 사용자에게 초기 내용을 빠르게 표시하고 검색 엔진 최적화를 개선하는데 도움을 준다.
- 주로 동적 콘텐츠를 포함하고 있는 웹 애플리케이션에 적합하다.

장점
- SEO 최적화 : 서버에서 렌더링 된 페이지들은 검색 엔진에서 쉽게 색인화 가능
- 초기 로딩 속도 개선 : 사용자에게 초기 컨텐츠를 더 빠르게 표시할 수 있다.
- 데이터 최신화 : 매 요청마다 최신 데이터를 가져올 수 있다.
단점
- 서버 부하 : 매 요청마다 서버에서 페이지를 가져오면서 서버 자원을 많이 사용할 수 있다.
- 느린 네트워크 연결 : 서버에서 HTML을 생성해서 가져오는데, 느린 네트워크 영향을 받으면 초기 로딩이 느려질 수 있다.
📘 SSG
소개
- SSG는 페이지를 사전에 빌드 시점에 한 번 생성하고 정적 파일로 제공하는 방식이다.
- 여러번 요청을 해도 빌드된 파일을 제공한다. (변화 X)
- 기본적으로 Next는 SSG 방식으로 데이터를 페칭한다.
- 하지만 정적 데이터를 사용하므로 동적 콘텐츠에는 제한이 있다.
- 주로 블로그, 포트폴리오 웹 사이트, 회사 홈페이지 등 정적인 사이트에 사용한다.
장점
- SEO 우수 : 초기 로딩 속도가 빨라 SEO가 우수하다.
- 서버 부하 낮음 : 미리 빌드된 페이지를 제공하므로 서버 부하가 낮다.
단점
- 동적 데이터에 제한적이다.
- 업데이트 된 데이터에 대한 재빌드가 필요하다.
📙 요약
CSR vs SSR vs SSG
- CSR : 초기 로딩이 빠르지만 SEO가 어려우며 클라이언트에서 데이터 로딩 필요
- SSR : 초기 로딩이 빠르고 SEO가 우수하지만 서버부하가 증가할 수 있음
- SSG : 초기 로딩이 빠르고 SEO 가 우수하며 서버부하가 낮지만 동적 데이터에 제한이 있음
⇒ next.js는 세가지 방법 모두 지원! 적절하게 사용하는것이 중요