[Frontend] CSR과 SSR의 차이와 살짝의 SSG까지 알아보자.

React.js나 Next.js로 프로젝트를 시작하면 한번쯤은 고려해보게되는 CSR과 SSR. SSG와 함게 대표적인 웹 페이지를 렌더링하는 방식인데, 둘의 차이점과 추가적으로 알아두면 좋을 정보들을 정리해보았다. 

---

웹 페이지를 렌더링하는 방식

초창기때만 하더라도 모든 웹페이지가 정적 페이지였다. 그래서 페이지를 이동하거나 어떠한 변화가 보일때마다 서버로부터 새로운 HTML을 받아 리렌더링을 해야했다. 매번 전체 페이지를 재생성해야 했기때문에 당연히 부담이 가고, 사용자 경험에 있어서도 좋지 못했다. 그래서 탄생하게 된 것이 Ajax(Asynchronous Javascript and XML)이다. Ajax는 자바스크립트를 통해서 브라우저와 서버가 비동기로 데이터를 주고받을 수 있게 해주었다. 그래서 매번 전체 페이지를 불러올 필요없이 필요한 부분의 데이터만 불러와저 동적으로 웹 사이트 화면을 변경할 수 있게 되는 것이다. 그리고 서버에서만 담당하던 로직 처리나 html 생성을 브라우저에서도 할 수 있게 된 것이다. 

CSR(Client Side Rendering)

클라이언트 쪽에서 렌더링이 된다. 즉, 서버는 요청을 받으면 클라이언트에 html와 js를 보내준다. 클라이언트는 그것을 받아 렌더링을 시작한다. 유저는 자바스크립트가 모두 다운로드 되고 실행이 끝나기전까지 사이트를 볼 수 없다.

 React와 Vue, Angular 등과 같은 SPA(Single Page Application)에서 주로 쓰인다.

 

CSR 동작 단계

 

1. 사용자가 웹 페이지를 방문하면(request)

2. CDN이 HTML 파일과 JS로 접근할 수 있는 링크를 클라이언트로 보낸다. 여기서 CDN이란, 사용자에게 웹 콘텐츠를 효율적으로 제공할 수 있는 서버의 분산 네트워크이다.

3. 클라이언트는 HTML과 JS를 다운로드 받는다. 이때, SSR과 달리 유저는 아무것도 볼 수 없다.

4. 다운이 완료된 JS가 실행되고 데이터를 위한 API가 호출된다. 이때, 유저들은 placeholder를 보게 된다.

5. 서버가 API로부터의 요청에 응답한다.

6. API 요청을 수행하여 동적 컨텐츠를 가져오고 파싱하여 최종 컨텐츠를 렌더링한다.

 

CSR 장점 😊

• 초기 로딩 이후, 후속 페이지 로드시간이 빨라서 사용자 경험이 좋다.
• 서버에 요청하는 횟수가 훨씬 적어서 서버의 부담이 적다.
• TTV(Time to View)와 TTI(Time to Interact)사이 간극이 없다.

CSR 단점 😥

• 첫 페이지 로딩 시, HTML과 CSS, 스크립트들을 한 번에 불러와야해서 초기 로딩 속도가 느리다.
• SEO(검색 엔진 최적화)에 친화적이지 않는다. 검색 엔진 크롤러가 해당 페이지에 처음 방문했을 때는 빈 페이지이기 때문이다. (구글 봇의 경우에는 js를 지원해서 예외라고 한다.)

SSR(Server Side Rendering)

서버쪽에서 렌더링 준비를 끝마친 상태로 클라이언트에 전달하는 방식이고, Next.js와 PHP, ASP 등이 이에 속한다.

 

SSR 동작 단계

 

1. USER가 웹사이트에 방문을 하면

2. 서버는 ‘Ready to Render’ 즉, 즉시 렌더링 가능한 html파일을 만든다.

3. 컴파일된 html은 추가 렌더링 및 표시를 위해 클라이언트에 전달된다.

4. 클라이언트가 html을 다운로드하고 사용자가 사이트를 볼 수 있도록한다. (사이트 조작은 불가능, 이때 사용자의 조작을 기억하고 있는다.)

5. 클라이언트가 자바스크립트를 다운로드하고 실행한다.

6. 자바스크립트가 성공적으로 컴파일되었기 때문에 지금까지 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호작용이 가능해진다.

 

SSR 장점 😊

• 렌더링이 준비된 HTML파일을 브라우저에서 로드하기 때문에 초기 페이지 로드 시간이 빠르다.
• 검색엔진 최적화(SEO)에 친화적이다. 이미 다 만들어진 페이지를 검색 엔진 크롤러가 요청에 대한 응답으로 받기 때문이다.

SSR 단점 😥

• 초기 페이지 로드 시간은 빠르지만, 다른 페이지로 이동 시에 다시 처음부터 렌더링해야하기 때문에 로딩속도가 느리다.
• TTV와 TTI 사이 간극이 있어서 사용자 경험이 좋지 않다. (클릭과 실행 사이의 시간이 걸린다.)
• 매번 서버에 요청하기 때문에 서버 자원을 더 많이 사용한다. 그래서 서버 부담도 커지고 그에 따른 서버 비용도 더 많이 든다.

SSG(Static Site Generation)

클라이언트에서 필요한 페이지들을 사전에 미리 준비해뒀다가, 필요할 때마다 이미 완성된 파일을 단순히 반환하여 브라우저에서 보여지게 하는 방식이다. SSR과 CSR의 단점을 적절하게 보완한 방식이라고 생각하면 된다.

SSG는 사이트를 빌드하는 시점에 미리 HTML을 생성한다. 미리 정적사이트를 만들어서 사용자에게 보여주고 하루나 일주일마다 다시 정적사이트를 빌드하면 되기때문에 서버 부하가 줄어든다.

Next.js에서 권장하는 렌더링 방식이기도 하다.

 

SSG 동작 단계

 

1. 사용자가 웹 페이지를 방문하면(request), 엣지 캐싱(edge caching)된 HTML을 클라이언트로 반환해준다.

2. 부라우저는 HTML을 다운로드하고 최종 사용자가 사이트를 볼 수 있도록 한다.

 

 ‼️ 엣지 캐싱 ‼️
최종 사용자에게 더 가까운 컨텐츠를 저장하기 위해 캐싱 서버를 사용하는 것이다. 대표적으로 CDN을 많이 사용한다.

 

SSG는 이미 생성된 HTML 파일을 받기 때문에 SEO에 친화적이고, 서버에서는 단지 그 파일을 전달해주는 것 뿐이어서 매우 빠르지만, 현실적으로 웹 서비스에 존재하는 수많은 페이지들의 정적 페이지를 다 생성하기에 무리가 있다. 

---

그래서 우리가 선택해야할 방식은 필요에 따라 여러 방식을 조화롭게 사용해야 한다는 것이다.

위에서 알아봤다시피 대부분의 SPA에서는 CSR을 사용하고 있는데, CSR의 단점을 보완하기 위해서 SSR이나 SSG를 도입하면 된다. 쉽게 말해 실시간성이 요구되면 CSR, 핵심 데이터가 수시로 바뀌거나 SEO까지 고려 할 때는 SSR을 적절히 도입해서 쓰면 된다. 

 

보통 프레임워크를 사용해서 도입하는 방법이 가장 쉬운데, 

리액트 기반 프로젝트에서  Next.js 는 SSR, SSG를 둘 다 지원하기 때문에 페이지의 성격별로 선택을 하면되고,  Gatsby.js는 SSG에 특화된 리액트 기반 정적페이지 프레임워크로 SSG에 최적화되어 있지만 CSR이나 SSR 또한 지원한다.

 

프레임워크를 선택할 때 고려해야 할 점이 있다.

개인이 혼자서 작은 규모의 프로젝트를 진행할 때는 프레임워크나 라이브러리를 쓰는 것보다 그냥 HTML/CSS/JS을 쓰거나 NodeJS template design을 쓰면된다.

하지만 팀으로 프로젝트를 진행하게 되면 컴포넌트 베이스 프레임워크인 React나 Vue를 사용하는 것을 권장한다.

그리고 만약 SEO가 중요하다면 Next.js나 Gatsby.js를 사용하면 되고, 별로 중요하지 않다면 그냥 React를 사용하면된다.

SEO가 중요하고 업데이트가 자주 일어나는 동적인 사이트를 만든다면, SSR이나 SSG 둘다 선택가능한 Next.js를 추천하고, SEO가 중요하지만 업데이트가 자주 일어나지 않는 정적인 사이트를 만든다면 Gatsby.js를 추천한다.

 

출처

https://www.sarah-note.com/%ED%81%B4%EB%A1%A0%EC%BD%94%EB%94%A9/posting2/

👩‍💻 SSR vs CSR 비교 설명, Next.js가 탄생하게 된 이유

https://www.youtube.com/watch?v=C6kiIkrBdyE 

https://ajdkfl6445.gitbook.io/study/web/csr-vs-ssr-vs-ssg

CSR vs SSR vs SSG - 콥 노트

https://velog.io/@altmshfkgudtjr/CSR-SSR-SSG-%EC%A1%B0%ED%99%94%EB%A5%BC-%EC%9D%B4%EB%A3%A8%EB%8B%A4

CSR, SSR, SSG 조화를 이루다.