CSR, SSG, SSR

Next.js를 공부를 시작하면서 웹 사이트의 랜더링 방법에 대해서 학습하게 되었다. 그동안 React를 사용하면서 CSR 개념은 알고 있었지만, CSR과 더불어 다양한 웹 사이트의 렌더링 방법에 대해서 정리해보고자 한다.

 

1. CSR(Client Side Rendering)

- CSR은 렌더링 하는 주체가 클라이언트(브라우저)다.

- 서버는 빈 HTML(index.html)과 모든 로직을 처리하는 자바스크립트 번들을 반환한다.

- HTML, React 라이브러리 소스 코드, 개발자가 작성한 js(React) 코드를 서버로부터 받고 브라우저가 렌더링을 실시한다.

 

장점

- 처음 페이지가 로딩된 이후에는 부드럽고 빠른 사용자 경험을 제공한다.

- 그 이유는 처음 렌더링을 할 때 필요한 파일들을 모두 서버로부터 받아오기 때문에, 추가로 필요한 부분에 대해서만 서버에 요청을 하면 되기 때문이다.

 

단점

- 첫번째 렌더링을 할 때 모든 파일이 번들링 되어있는 파일을 받기 때문에 첫번째 페이지 로딩시간이 길다.

- 처음 받아오는 index.html의 내용이 비어있기 때문에 SEO(검색 엔진 최적화)가 좋지 않다.

- 또한, index.html이 비어있기 때문에 브라우저에서 자바스크립트를 활성화하지 않는 경우에는 아무런 페이지를 볼수가 없다.

 

CSR은 언제 사용하면 좋을까?

- 작은 규모의 애플리케이션, SPA(Single Page Application).

---

2. SSR(Server Side Rendering)

- SSR은 렌더링 하는 주체가 서버이며, 서버에 페이지 요청을 보낼때 렌더링을 한다.

- 서버에서 완전히 렌더링 된 페이지를 클라이언트로 보내고, 클라이언트의 자바스크립트 번들이 SPA 프레임워크의 작동을 대신한다.

- 서버에서 렌더링된 HTML 파일을 가져오기 때문에, 정적 UI는 모두 정상적으로 동작하지만, js 파일을 전부 다운받기 전까지는 인터렉션이 정상적으로 작동하지는 않는다.

 

장점

- 미리 서버에서 만들어진 HTML을 받아오기 때문에 페이지의 로딩 시간이 빠르다.

- 서버에서 렌더링되어 클라이언트로 전송되기 때문에 동적 데이터를 사용하면서도 SEO(검색 엔진 최적화)를 유지할 수 있다.

- SSG나 ISR과 달리 실시간 데이터를 사용할 수 있고, 요청하는 사용자에 따라 사용자별 필요한 데이터를 사용할 수 있다.

 

단점

- 서버에 과부하가 걸릴 수가 있다. 만약 1000명의 사용자가 접속을 하면 사용자별로 1000개의 렌더링을 해야하기 때문이다.

 

SSR은 언제 사용하면 좋을까?

- SEO에 크게 의존하거나, 데이터가 자주 변경되는 매우 동적인 콘텐츠를 포함하고 있는 사이트.

---

3. SSG(Static Site Generation)

 

- SSG는 렌더링하는 주체가 SSR과 동일하게 서버이지만, 언제 렌더링을 하느냐의 차이가 있다.

- SSG는 애플리케이션을  배포해서 처음으로 빌드할 때, 렌더링을 한다.

 

장점

- SSR의 장점과 동일하다

 

단점

- 빌드할 때 렌더링이 일어나기 때문에, 데이터가 정적이며 데이터가 가변적으로 바뀌는 애플리케이션 제공이 어렵다.

- 데이터가 정적이기 때문에, 사용자별 정보(로그인이 필요한 경우) 제공이 어렵다.

 

SSG는 언제 사용하면 좋을까?

- 데이터가 정적인 페이지(ex. 소개 페이지) 혹은 데이터 등을 수정할 때마다 사이트를 다시 배포해도 괜찮은 경우.

---

참고 :  https://d2.naver.com/helloworld/7804182

https://velog.io/@seunghwan7305/SSR-CSR-SSG-ISR-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0

https://www.youdad.kr/frontend-rendering-ssg-isg-ssr-csr/