Client-side Rendering vs Server-side Rendering

<Client-Side Rendering (CSR)>

클라이언트 사이드 렌더링(CSR)은 JavaScript를 사용하여 웹사이트나 애플리케이션을 브라우저에서 렌더링 하는 방식입니다. CSR에서는 콘텐츠의 처리 및 렌더링이 서버가 아닌 브라우저에서 이루어집니다. 

 

서버는 페이지의 기본 HTML 컨테이너만 렌더링하고, 나머지 콘텐츠는 클라이언트에서 처리됩니다.
CSR은 동적 콘텐츠가 많고 높은 수준의 인터랙티브 기능이 필요한 애플리케이션, 예를 들어 채팅 앱이나 소셜 미디어 플랫폼에 자주 사용됩니다. 또한, 단일 페이지 애플리케이션(SPA) 에도 적합합니다.

 

<CSR 진행 방식>

1. 유저가 웹 페이지 요청 : 브라우저로부터 유저의 웹페이지 요청을 받습니다
2. 서버가 요청을 받습니다 : 서버로 GET 요청 발송
3. 서버가 CSS와 JavaScript 파일이 있는 링크를 HTML 페이지 통해 전달 : 브라우저가 서버로부터 초기 HTML 파일 요청합니다
4. HTML 파싱 : 브라우저가 HTML 파싱 통해 DOM 트리를 생성합니다
5. 브라우저가 CSS와 JavaScript 다운로드 : 브라우저가 CSS와 JavsCript 다운받기 위해 서버에 추가 요청 발송합니다
6. 페이지 렌더링 : 브라우저는 다운받은 CSS 파일과 DOM 트리를 사용해 기본 웹 페이지 구조를 렌더링 합니다 (텍스트, 이미지, 버튼 등)
7. JavaScript 실행 : 브라우저가 JavaScript 실행하여 웹 페이지에 인터랙티브 기능과 동적 콘텐츠를 추가합니다. (애니메이션, API에 데이터 불러오기 등)
8. 리-렌더링와 업데이트 : 사용자가 웹 페이지와 상호작용할 때 (버튼을 클릭하거나 양식을 작성할 때 등), 브라우저는 사용자의 행동에 따라 웹페이지의 일부를 다시 렌더링 합니다. 이 과정에는 DOM을 업데이트하거나 새로운 데이터를 얻기 위해 서버에 추가 요청을 보내는 작업이 포함될 수 있습니다.
9.  최종 페이지 : 업데이트된 DOM과 동적으로 가져온 데이터가 브라우저에 의해 렌더링되어 완전한 상호작용이 가능하고 동적으로 업데이트되는 웹페이지가 생성됩니다.

<CSR 장점들>

• 빠른 웹사이트 상호작용 제공 :  사용자는 버튼 클릭이나 폼 제출과 같은 상호작용을 할 때 전체 페이지를 다시 로드하지 않고도 거의 즉각적인 업데이트와 피드백을 받을 수 있습니다.
• 서버 부하 감소 : SSR(서버 사이드 렌더링)에서는 서버가 페이지에 필요한 데이터, 스타일 및 콘텐츠를 가져와서 페이지를 렌더링해야 합니다. 이는 특히 트래픽이 많은 시기에 상당한 서버 자원을 요구합니다.
• 동적 업데이트가 필요한 웹사이트에 적합 : CSR은 실시간 데이터 대시보드, 협업 도구, 온라인 게임 등 빈번하고 동적인 콘텐츠 업데이트가 필요한 애플리케이션과 높은 호환성을 가지고 있습니다.

<CSR 단점들>

• 긴 페이지 로드 시간 : 클라이언트 사이드 렌더링은 서버 사이드 렌더링(SSR)보다 페이지 로드 시간이 더 길어질 수 있습니다. 이는 브라우저가 완전한 웹페이지를 렌더링 하기 전에 필요한 모든 JavaScript 파일을 다운로드하고 실행해야 하기 때문입니다.
• SEO 제한 사항 : 초기 페이지 로드 시 클라이언트에서 렌더링된 웹 페이지는 빈 HTML 파일로 구성되며 JavaScript 리소스에 대한 링크만 포함됩니다. 클라이언트에서 렌더링 된 웹사이트는 검색 결과에서 쉽게 발견되지 않을 수 있어, 이로 인해 가시성, 유기적 트래픽, 전환율이 나쁘게 영향을 받을 수 있습니다.
• 사용자 장치에 대한 의존성 : 클라이언트 사이드 렌더링은 사용자의 장치 처리 능력에 크게 의존합니다. 만약 장치가 오래되었거나 충분한 자원이 부족하다면, 복잡한 JavaScript 프레임워크나 라이브러리의 렌더링 및 실행을 처리하는 데 어려움을 겪을 수 있습니다.
• 사용자가 JavaScript를 비활성화 : 사용자가 브라우저에서 JavaScript를 비활성화하면, 그들은 초기 HTML 파일만 보게 되며, 이 파일은 최소한의 내용이나 아예 내용이 없을 수 있습니다.

<CSR 성능 개선 방법>

• 프리로딩 (Pre-Loading) : 이 기술은 페이지 생명 주기 초기에 페이지에서 필요할 주요 리소스를 미리 로드하는 데 사용될 수 있습니다.
• 지연 로딩 (Lazy Loading) : 지연 로딩을 사용하면 비필수 리소스를 식별하고 필요한 경우에만 로드할 수 있습니다.
• 코드 분할 (Code Splitting) : 큰 JavaScript 코드 번들을 피하기 위해 번들을 나누기 시작할 수 있습니다. 코드 분할은 Webpack과 같은 번들러에서 지원됩니다.

<Server-Side Rendering> 

서버 사이드 렌더링(SSR)은 웹 페이지를 서버에서 렌더링하고 완전히 렌더링 된 HTML을 클라이언트에 보내는 프로세스입니다. 이 접근 방식에서는 서버가 HTML을 생성하며, 여기에 동적 데이터도 포함됩니다. 그 후 서버는 완전한 페이지로 클라이언트에 전송하고, 클라이언트는 추가적인 처리 없이 페이지를 표시합니다.

 

<SSR 진행 방식>

1. 사용자가 방문하고 싶은 URL를 기입합니다.
2. 서버는 브라우저에 완전히 렌더링된 HTML 응답을 제공합니다.
3. 브라우저는 페이지를 렌더링 하고 JavaScript를 다운 받습니다.
4. 브라우저는 개발 프레임워크 (React, Angular, Vue 등) 실행 페이지를 인터랙티브로 만듭니다

<SSR 장점들>

• 더 빠른 로드 시간 : 서버 사이드 렌더링 애플리케이션은 느린 인터넷 연결을 사용하는 사용자의 페이지 로딩 속도를 높입니다. 따라서 전체적인 사용자 경험을 크게 향상합니다.
• SEO 개선 : 서버 사이드 렌더링(SSR)은 검색 엔진이 웹 페이지의 콘텐츠를 쉽게 크롤링하고 인덱싱할 수 있도록 보장하여, 더 나은 SEO와 높은 검색 엔진 결과 페이지(SERP) 순위를 얻는 데 도움이 됩니다.
• 정적 웹사이트에 적합 : 서버 사이드 렌더링(SSR)은 랜딩 페이지, 문서, 블로그와 같이 정적인 콘텐츠를 가진 웹사이트에 효율적인 접근 방식입니다. 서버는 렌더링 된 HTML 페이지를 생성하고 캐시 하여 서버 부하를 줄일 수 있습니다.

<SSR 단점들>

• 비용 증가 : SSR 애플리케이션을 배포하려면 서버나 최소한 "서버리스" 백엔드가 필요합니다. 이는 더 높은 운영 비용을 의미합니다.
• 서버 부하 증가 : SSR에서는 서버가 각 요청에 대해 전체 UI를 렌더링해야 하므로, 서버의 작업량이 증가할 수 있습니다. 이는 특히 트래픽이 많은 애플리케이션이나 동시 사용자 수가 많은 경우 더욱 두드러집니다.

<결론>

CSR : 동적 웹 애플리케이션

• 클라이언트 사이드 렌더링(CSR)은 소셜 네트워크나 온라인 메신저와 같은 동적 웹 애플리케이션에 주로 사용됩니다. 이러한 애플리케이션은 정보가 지속적으로 변경되며, 대규모의 동적 데이터를 빠르게 처리하고 업데이트하여 사용자 요구를 충족시켜야 하기 때문입니다.

SSR : 검색 엔진 가시성과 SEO 향상이 필요할 때

• Google에서의 가시성을 높이고 검색 엔진 결과 페이지(SERPs)에서 높은 순위를 차지하고 싶다면, 서버 사이드 렌더링(SSR)이 최선의 선택입니다.
• e-러닝 웹사이트, 온라인 마켓플레이스, 그리고 페이지 수가 적고 동적 데이터가 많지 않은 간단한 사용자 인터페이스를 가진 애플리케이션은 서버 사이드 렌더링의 혜택을 가장 잘 받을 수 있습니다.

	클라이언트 사이드 렌더링 (CSR)	서버 사이드 렌더링 (SSR)
렌더링 프로세스	렌더링 프로세스가 브라우저에서 JavaScript를 사용하여 이루어짐	렌더링 프로세스가 서버에서 수행됨
SEO	검색 엔진이 콘텐츠를 크롤링하고 인덱싱하기 어려움	검색 엔진이 렌더링된 HTML을 쉽게 크롤링할 수 있어 SEO에 유리함
초기 페이지 로드	HTML 껍데기만 먼저 로드되고, JavaScript 번들을 가져와 실행하여 UI를 렌더링함	서버에서 완전히 렌더링된 HTML 페이지를 처음부터 로드함
초기 페이지 로드 경험	JavaScript 번들이 다운로드 및 실행될 때까지 빈 페이지 또는 로딩 스피너가 표시됨	페이지 로드 시 즉시 렌더링된 콘텐츠를 볼 수 있음
어플리케이션 유형	SPA, 소셜 미디어 플랫폼, 채팅 앱, 내부 대시보드와 같은 높은 상호작용을 필요로 하는 웹 앱에 적합	랜딩 페이지, 전자상거래 앱, 문서, 미디어 출판과 같은 정적인 콘텐츠가 많은 웹사이트 및 상호작용이 적은 앱에 적합
지원 프레임워크	React, Angular, Vue, Svelte, Backbone.js, Ember.js와 같은 프레임워크 지원	Next.js, Nuxt.js, Remix, SvelteKit, Angular Universal, Astro, Qwik 등의 프레임워크 지원
상호작용성	초기 로드 후 상호작용이 매우 빠르고, 이후의 상호작용은 전체 페이지 새로고침 없이 클라이언트 사이드에서 처리함	초기에는 미리 렌더링된 콘텐츠만 상호작용 가능하며, 이후의 상호작용은 전체 페이지 새로고침 또는 CSR이 필요할 수 있음
로드 속도	JavaScript 파일을 가져오고 해석해야 하므로 초기 로드 시간이 느림	HTML이 사전에 렌더링되어 초기 로드 시간이 빠름
캐싱	렌더링된 페이지를 캐싱하기 어려움	렌더링된 HTML 페이지를 서버나 CDN에서 쉽게 캐싱할 수 있음
데이터 가져오기	초기 로드 후 API 호출을 통해 데이터를 가져옴	서버에서 데이터를 가져옴
서버 부하	렌더링이 브라우저에서 이루어지므로 서버 부하가 적음	렌더링이 서버에서 이루어지므로 서버 부하가 증가
HTTP 요청	서버에 보내는 HTTP 요청이 적음	서버에 더 많은 HTTP 요청이 필요함
JavaScript 의존성	JavaScript에 크게 의존함	JavaScript 의존도가 적음

 

참고 자료 :

https://solutionshub.epam.com/blog/post/what-is-server-side-rendering

EPAM SolutionsHub | Software Solutions for Digital Business

https://prismic.io/blog/client-side-rendering

What is Client-side Rendering (CSR)?

https://www.patterns.dev/react/client-side-rendering

Client-side Rendering

https://prismic.io/blog/client-side-vs-server-side-rendering

Client-side Rendering (CSR) vs. Server-side Rendering (SSR)

https://www.searchenginejournal.com/client-side-vs-server-side/482574/

Client-Side Vs. Server-Side Rendering

https://www.geeksforgeeks.org/server-side-rendering-vs-client-side-rendering-vs-server-side-generation/

Server Side Rendering vs Client Side Rendering vs Server Side Generation - GeeksforGeeks