[Web] SSR, CSR, SSG의 특징

CSR(Client Side Rendering)

• 클라이언트 쪽에서 렌더링이 일어난다.
• 서버가 클라이언트에게 html(with links to JS), css를 보내주면 클라이언트는 그것을 받아 렌더링을 시작한다.

 

CSR 단계

출처) SoluteLabs

1. user가 웹사이트를 접속한다.
2. CDN(Content Delivery Network)이 html 파일과 js로 접근할 수 있는 링크를 클라이언트로 보낸다.
   💡 CDN: 클라이언트와 물리적으로 가까운 서버에서 요청에 응답하는 방식이다. AWS의 cloudflare라고 생각하면 된다.
3. 웹 브라우저(클라이언트)는 html과 js를 다운로드 받는다. 그 동안 유저는 빈 화면을 본다.
   💡 서버는 클라이언트에게 아무 내용이 없는 빈 HTML 껍데기를 보낸다. 그리고 이걸 클라이언트 쪽에서 동적으로 태그들과 스타일을 생성하여 페이지를 채우는 방식이다.
4. JS가 실행되며 UI를 렌더링한다. 이 때 추가적으로 데이터 요청을 위해 웹 API가 호출된다. (그 과정에서 유저에게 ‘로딩중’ 표시를 보여준다)
5. 서버는 웹 API 요청을 받아 해당되는 데이터를 보낸다.
6. 클라이언트는 API 요청으로 받은 데이터를 최종적으로 렌더링(동적으로 렌더링)하여 유저가 화면을 보게 된다.

 

CSR 특징

• 서버에서 처리 없이 클라이언트로 html(with js), css 파일만 보내주기 때문에 클라이언트 쪽에서 JS가 모두 다운로드 되고 나서 렌더링이 끝나기 전까지 사용자는 페이지를 볼 수 없다.
• 초기 로드가 오래 걸린다. 하지만 초기 로드만 완료되면 이후 렌더링이 빠르다(페이지를 처음 로드할 때, 서버로부터 모든 코드를 받아와 다운로드하기 때문에)
• 서버에게 요청하는 횟수가 훨씬 적기 때문에 서버의 부담이 덜하다.
• SEO에 불리하다. (초기 html 파일이 비어있기 때문에 크롤러 봇이 데이터를 수집 X)
  💡 구글 봇은 JS를 지원하지만 다른 검색엔진(네이버, 다음 등)은 그러지 않아서 문제가 발생한다.
  💡 이를 해결하기 위해 SSR with Hydration 기법이 나왔는데, 대표적으로 React 진영의 Next.js와 Vue 진영의 Nuxt.js가 위 기법을 구현한 프레임워크다. 즉, 처음엔 서버사이드 렌더링을 하고, 그 후 다른 페이지들에선 클라이언트 사이드 렌더링을 이용하는 방식이다.

 

 

SSR(Server Side Rendering)

• 서버에서 렌더링을 마치고, data가 결합된 html 파일을 클라이언트에 보내주는 방식이다.
• 새로운 페이지로 이동할 때마다 서버에 요청하고 페이지를 받아내야 하기 때문에 받아오는 시간동안 깜빡거리는 현상이 발생할 수 있다.

 

SSR 단계

출처) SoluteLabs

1. user가 웹사이트를 접속한다.
2. Server는 'Ready to Render'. 즉, 즉시 렌더링 가능한 html파일을 만든다. (리소스 체크, 컴파일 후 완성된 HTML 컨텐츠로 만든다.)
3. 클라이언트에 전달되는 순간, 이미 렌더링 준비가 되어있기 때문에 HTML은 즉시 렌더링 된다.
   💡 그러나 사이트 자체는 조작 불가능하다. (Javascript가 읽히기 전이다.)
4. 클라이언트가 자바스크립트를 다운받는다.
5. 다운 받아지고 있는 사이에 유저는 컨텐츠는 볼 수 있지만 사이트를 조작 할 수는 없다. 이때의 사용자 조작을 기억하고 있는다.
6. 브라우저가 Javascript 프레임워크를 실행한다.
7. JS까지 성공적으로 컴파일 되었기 때문에 기억하고 있던 사용자 조작이 실행되고 이제 웹 페이지는 상호작용 가능해진다.

 

SSR 특징

• 필요한 부분의 html만 불러오기 때문에 첫 페이지 로딩 시간이 CSR보다 빠르다. (CSR은 첫 페이지 로딩 시, 모든 html, css를 다운받기 때문에 더 오래 걸린다.)
• 첫 페이지 로딩 이후, 사이트의 다른 곳으로 이동한다고 가정하면 SSR은 첫 페이지 로딩할 때의 과정과 동일하게 다른 페이지를 로딩한다. 따라서 서버에서 페이지를 생성하는 시간이 소요되며 CSR보다 느리다.
• 서버에서 이미 html, css를 컴파일하여 클라이언트에 전달하기 때문에 SEO 최적화에 유리하다.
• 서버에 매번 요청을 하기 때문에 서버의 부하가 커질 수 있으며 비용도 많이 들 수 있다.

 

 

SSG(Static Site Generation)

소개 페이지 같은 정적 페이지는 모든 유저에게 항상 동일한 화면이 보이기 때문에, 한 번만 생성한 이후에 어딘가에 저장해두고 필요할 때마다 로드하면 되는데, 이러한 방식을 SSG라고 한다. 즉 SSG는 html을 빌드 타임에 각 페이지 별로 생성한 뒤, 해당 페이지를 요청이 들어오면 이미 생성된 HTML 문서를 반환하는 방식이다. (따라서 앞서 소개한 SSR도 엄밀히 말하면 SSG에 속한다)

• SSG: HTML을 빌드 타임에 각 페이지별로 생성하고 해당 페이지로 요청이 올 경우 이미 생성된 HTML 문서를 반환한다.
• SSR: 요청이 올 때 마다 해당하는 HTML 문서를 그때 그때 생성하여 반환한다.

CSR 방식이 가진 단점을 극복하기 위해 등장한 여러 프레임워크가 있는데, 그 중 하나가 React 생태계의 Next Js가 있다. Next는 브라우저에 렌더링할 때 기본적으로 pre-rendering(사전 렌더링)을 한다. 즉 각 페이지들을 사전에 미리(빌드 타임에) html 문서로 생성하여 (CDN에) 가지고 있는 것이다. 그리고 서버로 요청이 들어올 때마다 필요한 html 문서를 반환해주는 형식이다.

출처) longroadhome.log

 

정확히는 빌드 타임 때 개발자가 pages 폴더에서 작성한 각 페이지들에 대한 각각의 html 문서를 생성해서 static 문서로 가지고 있게 된다. 그리고 유저가 원하는 페이지를 요청하면 서버에서 이 html을 재생성하는 것이 아니라 이미 생성이 완료된 페이지를 반환해준다.

• 미리 html 문서를 생성하여 반환만 하기 때문에 응답 속도가 매우 빠르다.
• 퍼포먼스에 집중하려면 SSG가 더 좋다. (CDN을 통해 더 빠른 응답 가능)
• 모든 유저에게 똑같은 결과물을 보이는 정적 페이지(소개 페이지, 블로그 게시물 등)일 때 SSG가 효과적이다.

 

 

Reference

[FE] SSR(Server-Side-Rendering) 그리고 SSG(Static-Site-Generation) (feat. NEXT를 중심으로)

SSR과 CSR의 차이

웹 렌더링 방식 (CSR, SSR, SSG)