[Web] SSR과 CSR

안녕하세요.

오늘은 SSR(Server Side Rendering)과 CSR(Client Side Rendering)에 대해 알아보도록 하겠습니다.

 

들어가며

웹 개발을 하면서 자주 언급되는 두 용어는 SSR(Server Side Rendering)과 CSR(Client Side Rendering)입니다. 두 기술 모두 웹 페이지를 사용자에게 렌더링 하여 보이는 데 사용되는 기술이지만 방식이 다릅니다. 방식마다 고유한 장점과 그에 따른 단점을 가지고 있어 Frontend 개발자들은 애플리케이션 최적화에 있어 제일 먼저 고려할 사항 중 하나입니다. 이 글에서는 SSR과 CSR의 작동방식, 장단점을 비교하며 내용을 살펴보도록 하겠습니다.

SSR과 CSR 이해하기

구체적인 내용에 대해 파헤치기 전에 SSR과 CSR에 대해 기본적인 이해가 필요합니다.

SSR (Server Side Rendering) 개념

서버가 웹 페이지의 전체 HTML 콘텐츠를 생성하고 사전에 렌더링 하여 이를 클라이언트 브라우저로 전달하여 초기 로드 시 완벽한 기능을 갖춘 페이지를 제공합니다. 

SSR 동작 방식

SSR에서는 서버가 주된 작업을 담당합니다. 요청을 받은 후 데이터베이스나 외부 API에서 필요한 데이터를 가져와 처리하고 완전한 HTML 페이지를 생성합니다. 이러한 사전 렌더링 된 HTML은 클라이언트로 보내져 클라이언트 측 처리를 크게 줄입니다.

사용자 요청
사용자가 특정 웹 페이지를 요청합니다.
서버 처리
서버는 요청을 받고 데이터베이스나 외부 API로부터 필요한 데이터를 가져옵니다.
HTML 생성
서버는 요청된 페이지의 HTML 콘텐츠를 동적으로 생성하고 검색된 데이터를 통합합니다.
HTML 전달
완전히 렌더링 된 HTML 페이지가 사용자의 브라우저로 전송됩니다.
Client Side 렌더링
브라우저는 HTML을 받은 후 화면에 콘텐츠를 구문 분석하고 표시합니다. 

CSR(Client Side Rendering) 개념

서버에서 렌더링에 필요한 기본 HTML 파일과 함께 JavaScript 파일을 보내고 클라이언트 브라우저는 서버로부터 다운로드하고 실행하여 페이지를 직접 렌더링 합니다.

CSR 동작방식

CSR에서는 서버가 처음에 브라우저에 최소한의 HTML 페이지를 전송합니다. 이 페이지에는 필요한 마크업과 JavaScript 파일 외에 거의 아무것도 포함되지 않은 경우가 많습니다. 이후 브라우저가 주도적인 역할을 수행하여 수신된 JavaScript를 사용하여 서버로부터 필요한 데이터를 가져오고 DOM(Document Object Model) 내에서 페이지 콘텐츠를 동적으로 구축합니다.

사용자 요청
SSR과 마찬가지로 사용자가 특정 웹 페이지를 요청합니다.
초기 HTML 전달
서버는 최소한의 콘텐츠와 JavaScript 파일을 포함하는 가벼운 HTML 페이지를 전달합니다.
JavaScript 실행
브라우저는 수신된 JavaScript를 실행하여 필요한 데이터를 서버에 요청합니다.
데이터 Fetching
서버는 JSON 형식으로 요청된 데이터를 응답합니다.
DOM 조작
JavaScript는 수신된 데이터를 구문 분석하고 DOM을 동적으로 조작하여 페이지를 구축합니다.
사용자 경험 향상을 위한 처리
Javascript로부터 사용자 경험 향상을 위한 처리를 하고 그에 따라 DOM을 업데이트합니다.

SSR과 CSR의 주요 차이점

두 가지 방식 모두 웹 페이지를 렌더링 역할을 하지만 과정과 그 결과적인 영향은 크게 다릅니다. 주요 차이를 알아보겠습니다.

초기 로딩 시간 - SSR👍

SSR
SSR은 일반적으로 서버가 HTML을 사전 렌더링 하기 때문에 더 빠른 초기 로드 시간을 제공합니다. 브라우저는 이미 표시할 준비가 된 전체 페이지를 받습니다.
CSR
일반적으로 초기 페이지 로드가 느릴 수 있습니다. 브라우저는 콘텐츠를 렌더링 하기 전에 데이터를 Fetching 하고 처리해야 합니다.

SEO(Search Engine Optimization) - SSR👍

SSR
검색 엔진 크롤러는 서버 렌더링된 HTML을 쉽게 크롤링하고 색인화할 수 있어 SEO 성능이 향상됩니다.
CSR
검색 엔진 크롤러는 JavaScript 중심의 CSR 애플리케이션을 처리하는 데 어려움을 겪을 수 있으며, 이는 콘텐츠의 색인화 및 검색 순위에 부정적인 영향을 미칠 수 있습니다.

사용자의 상호작용 경험 - CSR👍

SSR
빠른 초기 로드를 제공하지만, 이후 사용자 상호 작용은 추가적인 서버 요청을 유발하여 응답 속도에 영향을 미칠 수 있습니다.
CSR
사용자 상호 작용 부분에서 탁월합니다. JavaScript는 DOM 내에서 실시간 업데이트를 허용하여 더욱 매끄럽고 응답성이 높은 경험을 제공합니다.

SSR과 CSR의 주요 장단점

SSR 장단점

SSR 장점
사전 렌더링된 HTML로 인한 SEO 성능 향상
빠른 초기 페이지 로드 시간
저사양기기에서도 보여주는 좋은 퍼포먼스

SSR 단점
트래픽이 몰리게 되면 서버의 부하가 크게 증가됨 
전체 페이지 로드 전까지 후속 상호 작용이 제한됨 
서버 렌더링 병목 현상 가능성

CSR 장단점

CSR 장점
향상된 상호 작용성과 응답성
후속 상호 작용에 대한 서버 부하 감소
유연한 클라이언트 측 상태 관리

CSR 단점
초기 페이지 로드가 느립니다.
올바르게 구현되지 않은 경우 SEO에 대한 문제가 발생할 수 있습니다.
클라이언트 측 렌더링을 관리하는 데 증가된 복잡성이 있습니다.

Case별로 알아보는 유리한 렌더링 방식

콘텐츠 중심 웹사이트 (SSR)
정적 콘텐츠가 많은 웹사이트는 SSR의 빠른 초기 로드 시간을 위해 SSR을 사용하는 것이 좋습니다.
e커머스 애플리케이션 (SSR)
e커머스와 관련된 애플리케이션은 SSR을 사용하여 제품 페이지를 빠르게 제공하고, 사용자 경험을 향상해 전환율을 높일 수 있습니다.
SEO에 중요한 페이지 (SSR)
랜딩 페이지나 블로그 게시물과 같은 페이지는 검색 엔진 최적화 위해 SSR을 사용하는 것이 좋습니다.
동적이고 상호 작용적인 애플리케이션 (CSR)
SPA와 같이 페이지 리로딩 없이 매끄러운 사용자 경험을 제공하기 위해 CSR을 사용하는 것이 좋습니다.
실시간 업데이트가 필요한 SNS 플랫폼 (CSR)
SNS 플랫폼은 실시간 콘텐츠 업데이트와 사용자 상호 작용을 제공하기 위해 CSR의 기능을 활용하는 것이 좋습니다.

SSR과 CSR을 둘 다 사용하기 - 하이브리드 방식

SSR과 CSR을 모두 활용하는 하이브리드 접근 방식이 점점 인기를 얻고 있습니다. 이를 통해 중요한 콘텐츠를 SEO 및 초기 로드 속도를 위해 서버에서 렌더링 하고, 동적 요소와 사용자 상호 작용은 클라이언트 측에서 처리할 수 있습니다. 이러한 하이브리드 방식을 Isomorphic Rendering이라고 합니다. 이 방식은 웹 애플리케이션의 장점을 모두 활용하여 최적화된 성능, 유연한 사용자 경험 및 SEO를 제공할 수 있습니다.

 

Isomorphic Rendering에 대해서는 다른 게시글을 통해 다루도록 하겠습니다. 여기서는 "이러한 방식이 있다" 정도로 이해해 주시고 넘어가주시면 될 것 같습니다 :)

마치며

SSR과 CSR은 각각의 장점과 단점을 가지고 있어 적합한 상황에 맞게 사용하는 것이 좋습니다. SSR과 CSR을 이해하고 잠재적으로는 하이브리드 방식까지 고려함으로써 이후 사용자에게 제공할 서비스에서 성능, 상호 작용 및 검색 엔진 최적화까지 모두 챙길 수 있을 것입니다.

 

긴 글 읽어주셔서 감사합니다.