[SSR vs CSR] SSR과 CSR 비교 및 사용시기

CSR에서는 HTML문서에서 모든 내용을 수신하지 않고 클라이언트 측 JavaScript 라이브러리를 사용하여 브라우저에서 콘텐츠를 렌더링하낟. 새 페이지가 로드될 때 브라우저는 서버에 새 요청을 하지 않고, 페이지가 브라우저에 로드될 때까지 콘텐츠가 렌더링되지 않기 때문에 검색엔진 순위에 부정적인 영향을 미칠 수 있다. 하지만 CSR Application에서는 Web Side Rendering이 더 빠른 경향이 있다고 한다. 개발자는 SSR과 CSR을 고려할 때 프로젝트의 규모, Application의 복잡성, 사용자수, 사용자 경험 우선순위 등의 요소를 평가하게 된다고 한다.

개인적으로 가장 표면적인 이유가 바로 사용자 경험 우선순위라고 생각했다. 사용자입장에서 화면 전체가 깜빡이는 것을 보게되고 UX의 흐름이 끊기는 것이 꾸준한 서비스 이용에 악영향을 미칠 것이기 때문이다.(Conversion Rate, CRR 등..)

하지만 SSR이 SEO에 대한 장점을 가지고 있다는 내용을 보면서 SEO에 대해 조금 더 깊게 이해할 수 있었고, 서비스의 지속적인 사용을 위해서는 새롭게 유입되는 고객의 수 또한 중요하다고 생각했다. 고유페이지 방문수 또는 인바운드링크 등과 같은 KPI를 높이기 위해서는 SEO의 검색 순위에서 높은 위치를 차지하는 것이 중요하다는 나의 생각을 남겨본다.

차이1 - 웹페이지 로드 시간

첫 페이지 로드 시간

첫 페이지 로드 시간은 사용자가 웹 사이트를 처음 로드할 때 걸리는 평균시간이다. 첫 번 째 로드에서 CSR에서는 브라우저가 기본 HTML, CSS 및 필요한 모든 스크립트를 한 번에 로드한 다음 브라우저에서 사용 가능한 콘텐츠로 HTML을 compile 하낟.

이 시간은 보통 미리 컴파일된 HTML과 해당 스크립트를 서버에서 가져오는 것보다 더 많이 걸린다. 즉, SSR이 첫 페이지 로드시간이 덜 걸린다.

추가 페이지 로드 시간

두 번째 페이지 로드시간은 한 페이지에서 다른 페이지로 이동하는 데 걸리는 평균 시간이다. 이 시나리오에서는 CSR에 대해서는 모든 지원 스크립트가 사전에 로딩되기 때문에 CSR에 대해서는 로딩시간이 적다. lazy module loading을 할 필요가 없는 한 서버에 요청을 보내지 않기 때문이다.

하지만 SSR의 경우 한 페이지를 로드할 때마다 서버에 Request을 보내는 cycle이 반복된다.

차이2 - 캐싱의 영향

cache는 무거운 web Application의 속도를 향상시키기 위해 Web server 뿐만 아니라 모든 브라우저에서 caching mechanism을 사용하여 클라이언트 컴퓨터에서 재사용가능한 Script를 cahing한다. 이는 SSR뿐만 아니라 CSR에 대한 전반적인 부하 시간을 향상시킨다.

CSR에서는 lazy module 로딩이 필요하지 않는 한, 실질적으로 CSR 기반의 Web Application도 인터넷없이 실행될 수는 있다.(단, API로 데이터를 안부르는 경우) 일단 로드되면 App은 더 이상 서버에 Request를 보낼 필요가 없다. 이는 간단한 Desktop Application처럼 Web Application을 탐색할 수 있게 해준다.

그러나 SSR에서는 서버에 대한 요청이 항상 전송된다.따라서 CSR에 비해 SSR의 페이지 로딩 시간이 의심할 여지 없이 더 높다.캐싱은 캐시에서 브라우저에 의해 스크립트가 검색되기 때문에 SSR에서도 컨텐츠 렌더링 속도를 향상시킨다.아래 이미지는 브라우저가 캐시된 스크립트에 대한 반복적인 요청을 처리하는 방법을 보여준다.

대부분의 스크립트는 메모리 또는 Disk Cache에서 로드되기 때문에 loading 시간이 향상되고 서버에 과도한 부하를 방지할 수 있다.

차이3 - SEO에 미치는 영향

비즈니스 웹사이스라면 검색시 노출되어야 소비자가 유입되어 구매까지 이어질 수 있기 때문에 검색엔진을 위한 최적화가 필수이다. 검색엔진은 크롤링을 통해 웹사이트를 읽고 이해하는데, 이 크롤러는 실제 내용보다는 웹사이트의 메타데이터에 더 관심이 많기 때문에, 웹페이지에 검색엔진에 적합한 메타데이터를 반영해야 한다.

CSR에서는 웹페이지 콘텐츠가 자바스크립트를 사용하여 동적으로 생성된다. 이 말인 즉슨, 한 페이지에서 다른 페이지로의 메타데이터변경이 자바스크립트 실행에 의존한다는 것을 의미한다. 과거의 검색엔진의 크롤링에서는 자바스크립트가 실행되지 않는 것을 선호했는데, 최근에는 구글이 자바스크립트 실행을 받아들이면서 트렌트가 바뀌고 있다고 한다.

CSR에서는 페이지 메타데이터가가 다른 페이지로 변경될 수 있도록 설정해줘야할 필요가 있다. 이 때 리액트의 React Helmet이나 @angular/browser의 Meta 같은 라이브러리가 사용된다. 각 페이지마다 메타데이터를 설정하여 Client측에서 렌더링할 수 있도록 설정해주어야 한다.

SSR은 전체 페이지가 Server에서 올바른 메타데이터로 compile된 다음, 최종 HTML가 Front-end로 전송된다. 검색엔진 크롤러 입장에서는 자바스크립트 사용 허용 유무에 관계없이 메타데이터를 읽기만 하면 되기 때문에 CSR보다 SSR이 검색엔진에 최적화된 페이지를 만드는 방법이다.

언제, 어떤 것을 사용해야할까?

시나리오1 - 동적 컨텐츠 로드

서버 PC는 대게 연산처리능력이 좋고 네트워크 속도가 빠른 컴퓨터이다. 때문에 예상 처리 요청 건수를 처리하는 데에 무리가 없고, 결과적으로 Server에서 컨텐츠를 요청하고 받아오는 속도가 비교적 빠르다.

반면에 Client System은 제한된 컴퓨팅 성능을 가졌기 때문에 동적 컨텐츠를 가져오고 렌더링하는데 시간이 더 걸릴 수 있다. 컨텐츠를 렌더링하는데 소요되는 전체 시간이 더 오래걸리기 때문에 웹사이트가 반복적인 동적 컨텐츠 렌더링을 포함하는 경우 CSR보다 SSR이 더 나은 선택이다.

시나리오2 - 웹 애플리케이션 UX vs 웹 사이트 UX

웹 애플리케이션과 웹사이트는 거의 비슷하다고 생각할 수 있지만, 두 가지는 다른 형태의 웹 컨텐츠이다. 웹 애플리케이션은 회계, CRM, HR관리, 프로젝트 관리 등과 같은 목적으로 사용할 수 있는 완전한 애플리케이션이라고 한다. 반면 웹사이트는 비즈니스에 있어 유익한 컨텐츠 형태이다.

웹 애플리케이션은 사용자가 데이터 입력을 수행하고 웹 애플리케이션에서 보고서를 생성하기 때문에 웹사이트에 비해 훨씬 더 많은 Interaction이 발생한다. 이런 경우 클릭이 오래 걸리지 않도록 하는 것이 중요하다. 따라서 CSR은 SSR에 비해 웹 애플리케이션에서 더 잘 작동한다.

반면에 웹 사이트의 경우, 캐싱이 일반적으로 렌더링 속도를 높이는 것을 담당하기 때문에 클릭할 때마다 새로운 웹페이지가 로딩되도 괜찮고, 크롤러에게도 올바른 메타데이터를 제공할 수 있다. CSR에 비해 SSR이 웹사이트에서 더 잘 작동한다고 볼 수 있다.

 

 

결론

SSR과 CSR. 둘 중 어떤 것을 선택해야하는 가에 대한 궁금증을 해결할 수 있었던 서칭이었다. 실제로 CSR과 SSR은 사용자에게 제공하려는 UX에서 매우 중요하다고 한다. 위의 내용들을 모두 고려하여 현명한 선택을 해야 전체 웹사이트 및 웹 애플리케이션의 재개발에 비용을 쓰지 않을 수 있다는 것을 배웠다.

 

 

 

---

Reference

1. https://www.solutelabs.com/blog/client-side-vs-server-side-rendering-what-to-choose-when
2. https://www.freecodecamp.org/news/lazy-loading-in-angular-intro-to-ngmodules/