CSR vs SSR (Rendering 기법의 차이)

이 글에서는 Server Side Rendering과 Client Side Rendering의 차이점을 공유하고자 합니다. 

상반된 관계에 있는 방식인 만큼 장단점이 서로 엇갈려서 서로의 장단을 정확하게 알고 적재적소에 필요한 방식으로 구현하는 것이 중요하다고 생각합니다.

 

SSR (Server Side Rendering)

SSR은 서버측에서 렌더링이 되고 나온 결과물을 클라이언트에 전달하는 방식을 의미합니다. 

1. User가 WebSite 요청을 보냅니다.
2. Server는 'Ready To Render'. 즉, 즉시 렌더링 가능한 html 파일을 만듭니다.
3. 렌더링 된 HTML과 함께 클라이언트가 자바 스크립트를 다운받습니다.
4. 다운 받아지고 있는 사이에 유저는 컨텐츠는 볼 수 있지만, 사이트를 조작할 수는 없습니다.
5. 브라우저가 JavaScript 프레임 워크를 실행합니다.
6. 성공적으로 컴파일 되었기 때문에 사용자 조작 및 웹 페이지와의 상호작용이 가능해집니다.

 

CSR (Client Side Rendering)

CSR은 렌더링이 클라이언트 쪽에서 일어납니다. 즉, 서버가 요청을 받으면 클라이언트에 HTML과 JS를 전송합니다. 

클라이언트는 그것을 받아 렌더링을 시작합니다.

 

1.  User가 WebSite 요청을 보냅니다.
2. CDN이 HTML파일과 JS로 접근할 수 있는 링크를 클라이언트로 보냅니다.
3. 클라이언트는 HTML과 JS를 다운로드 받습니다.
4. 다운이 완료된 JS가 실행되면서 데이터를 받아 오기 위한 API가 호출됩니다.
5. 서버가 API 요청으로부터 data를 전송하면, Client는 placeholder 자리에 데이터를 넣어주게되고 페이지는 상호작용이 가능해집니다.

 

SSR vs CSR

그럼 서로 어떤 장단점이 있고, 어떤 상황에서 적용해야 할까요??

	SSR	CSR
첫 페이지 로딩 시간	SSR은 필요한 부분의 HTML과 스크립트만 불러오게 되므로 비교적 빠름	모든 HTML, CSS와 스크립트를 한번에 불러오므로 비교적 느림
페이지 이동 로딩 시간	필요한 부분의 HTML과 스크립트를 그때그때 받아오기 때문에 비교적 느림	모든 HTML, CSS와 스크립트를 한번에 받아왔기 때문에 비교적 빠름.
SEO (Search Engine Optimization) 대응	서버 사이드에서 컴파일 되어 클라이언트로 넘어오기 때문에 크롤러에 대응하기 용이	자바스크립트가 동적으로 컨텐츠를 생성하기 때문에 추가적인 SEO 최적화가 필수적
자원 사용	서버에서 렌더링을 진행하기 때문에, 서버 자원 사용	클라이언트에서 렌더링을 진행하기 때문에 클라이언트 자원을 사용

 

SSR

• 네트워크가 느릴 때
• SEO가 필요할 때
• 웹 사이트가 상호작용이 별로 없을 때
• 동적으로 변경해야 되는 데이터가 많지 않을 때

CSR

• 네트워크가 빠를 때
• 서버의 성능이 좋지 않을 때
• 사용자에게 보여줘야 하는 데이터의 양이 많을 때(로딩창을 띄울 수 있는 장점이 있다.)
• 메인 스크립트가 가벼울 때
• SEO에 관심이 없을 때
• 사용자와 상호작용 해야 할 것이 많을 때

 

주로 React 프레임워크인 Next.js는 SSR를 제공하면서 부분적인 CSR을 적용할 수 있다고 합니다.

간단하게 Next.js가 제공해주는 기능을 보도록하겠습니다.

• Automatic Routing : 페이지 기반 라우팅 시스템
• pre-Rendering : 페이지 별 정적 파일 생성과 서버 사이드 렌더링 지원
• Code Spliting : Dynamic import를 이용하여 손쉽게 코드 스플리팅이 가능합니다.
• pre-Fetch 기능을 갖는 CSR
• CSS, SASS 기본 지원 및 다른 CSS-in-JS 라이브러리 지원
• HMR(HOT Module Replacement) 지원
• 서버 없이 API 끝단 라우팅 지원 (API routes to build API endpoints with Serverless Function)
• SEO 지원 가능