SPA와 CSR 그리고 SSR

웹 개발을 하면서 가장 많이 사용하는 라이브러리, 프레임워크는 React, Vue.js, Angular이다. 이것들로 우리는 SPA를 만들 수 있다. 

SPA를 검색해보면 CSR, SSR이라는 용어들도 함께 등장한다. 이 세 가지 용어가 어떤 것을 의미하고, 서로 어떤 관계를 가지고 있고, 영향을 줄 수 있는지 알아보려고 한다.

SPA (Single Page Application)

SPA는 웹사이트 전체를 하나의 페이지(Single Page)에서 보여주고, 내부 요소를 바꾸면서 화면을 보여주는 페이지이다.

기존 옛날 웹사이트에서는 새로운 페이지로 전환될 때 마다 서버로부터 리소스를 전송받았다. 하지만 점차 페이지의 용량이 커지면서 서버에서 매번 리소스를 받아오는 부담이 커지게 되었고, 이 문제를 해결하기 위해 SPA가 등장하게 되었다고 한다.

 

 

CSR (Client Side Rendering)

서버에서는 최소한의 화면 구조 HTML만 랜더링하고, 나머지 데이터, 컴포넌트와 관련된 로직은 모두 브라우저(클라이언트)에서 실행되는 렌더링 방식이다. 

 

장점

자연스러운 사용자 경험(UX)

CSR을 통해 만든 SPA는 초기에 서버로 부터 웹페이지에 대한 리소스를 모두 받아오기 때문에 이후 데이터 조회 이외에는 서버 통신이 없기 때문에 새로고침 없이 페이지를 탐색할 수 있다. 그리고 페이지간 라우팅 속도가 빠르기 때문에 페이자의 반응속도가 빨라 보인다.

 

서버와 클라이언트의 분리

클라이언트 부분 코드와 서버 코드의 영역을 조금더 명확하게 구분하여 개발, 관리 가능하다.

 

단점

검색 최적화 (SEO)

SEO는 브라우저의 서버 랜더링에 대해서 웹 크롤링을 수행하여 관련 콘텐츠를 선정하는데 CSR의 경우 초기 서버 랜더링 요소가 거의 없고, 초기 랜더링 시간, 데이터 요청과 같이 의미 있는 콘텐츠가 화면에  처음 렌더링 되는 시간이 길기 때문에 검색 최적화 부분에서 취약점을 가지고 있다.

 

성능

서버로 부터 초기에 모든 리소를 받아서 사용하기 때문에 JS의 번들 크기가 크거나, 성능이 부족할 경우 초기에 렉이 걸리는 것처럼 부자연스러운 경험을 제공할 수 있다.

 

데이터 조회

필요한 데이터를 이벤트를 통해 요청하고, 조회해야한다. 이때 데이터 요청 시 일정 시간이 필요하기 때문에 데이터가 없는 경우에 대한 클라이언트 쪽에서 대처가 필요하다.

 

 

SSR (Server Side Rendering)

SSR은 과거부터 사용되었던 웹페이지를 렌더링하는 방법이다. 사용자가 웹페이지를 요청했을 때 서버에서 전체 HTML 구조를 만들어 클라이언터로 전달한다. 이때 HTML에 필요한 데이터를 모두 포함하고 있다.

 

장점

빠른 초기 랜더링

우선 서버 측에서 화면을 랜더링하고, 데이터 요청, 조회를 담당하기 때문에 클라이언트의 JS 코드가 확연히 줄어든다. 그래서 초기 화면 랜더링 시 해석하고 로드하는 JS 코드라인이 적기 때문에 빠른 *FCP와 *TTI를 가진다. 

 

클라이언트의 여유

앞서 말한 것 처럼 클라이언트에서는 데이터 조회, 랜더링을 담당하는 코드들이 제거되기 때문에 비교적 클라이언트 영역에서 다른 서드 파티 JS 라이브러리를 위한 공간을 많이 확보할 수 있다.

 

검색 최적화 (SEO)

SEO는 구글 검색, 네이버 검색과 같이 검색엔진이 홈페이지의 구조와 콘텐츠를 잘 이해해서 우리 콘텐츠가 검색 결과를 상위에 노출시키기 위해 하는 작업을 말한다.

 

SSR랜더링을 사용하면 검색엔진이 웹페이지의 구조와 컨텐츠를 쉽게 크롤링하여 파악할 수 있기 때문에 SEO의 수준이 높아진다.

 

단점

서버의 부하

SSR의 웹 서버에서는 데이터 조회, 페이지 랜더링이 모두 서버에서 처리되므로 CSR보다 상대적으로 서버의 부하가 많다. 그리고 네트워크 환경이나, 사용자의 수, 서버의 환경 등에 영향을 받을 수 있다.

 

전체 페이지 새로고침

SSR은 페이지가 전환될 때마다 서버에 페이지 요청을 보낸다. 앞서 말한 서버의 부하 때문에 화면이 늦게 표시될 수 있는 가능성이 있고, 화면 전환시 화면 전체가 사라졌다가 다시 화면이 표현되어 깜빡이는 것처럼 보여 CSR에 비해 상대적으로 부자연스러운 UX를 제공할 수 있다.

 

 

내가 고민한 부분 

SPA는 CSR인가?

다양한 자료를 읽으면서 점차 SPA === CSR이라는 생각을 하고있게 되었다. 하지만 이것은 틀렸다. SPA라는 것을 화면 동작 방식 결과를 구현하기 위해 CSR이라는 방식을 채택한 것이다. 각각에 대해서 설명하다 보면 주체만 다르고 같은 설명을 하게 되는데 두 가지는 다르다는 설명을 먼저 명심하고 설명을 보아야 나중에 헷갈리지 않을 것 같다.

 

SPA에서 SSR가 필요한 이유

내가 생각하는 SPA에서 SSR을 적용하려는 이유는 크게 두가지 일 것 같다.

 

초기화면 랜더링 속도

SPA는 CSR 방식(?)이기 때문에 웹 페이지에 대한 모든 리소스를 초기에 다운로드한다. 그래서 처음 화면을 랜더링 하는 시간이 길어질 가능성이 있고, 부자연스러운 사용자 경험을 제공할 수 있다.

 

검색 최적화(SEO)

검색 엔진에 우리의 컨텐츠가 상위에 노출되는 것은 아주 중요하다. 상위에 노출될수록 사용자의 유입이 많아질 것이고 결국 매출로 이어질 수 있다. 앞서 CSR을 채택하는 SPA는 이러한 부분에서 취약점을 가지고 있기 때문에 아무리 자연스러운 사용자 경험을 제공하더라도 사용자가 들어오지 않으면 말짱 꽝이지 않을까.

 

용어

• FCP (First Contentful Paint) : 페이지가 로드되기 시작하고 컨텐츠의 일부가 화면에 랜더링 될 때까지의 시간
• TTI (Time To Interactive) : JS의 실행이 완료되어, 페이지의 상호작용이 가능하게 될 때까지의 시점
• TTFB (Time to First Byte) : 사용자가 웹페이지를 요청하고 웹서버에서 전달받는 첫 바이트(Byte)가 도착하는 시점

 

Reference

SPA(Single Page Application) 이란?

클라이언트 사이드 렌더링

서버 사이드 렌더링