[front-end] SSR vs CSR 특징과 장단점

SSR vs CSR

프론트엔드를 공부하셨다면, SSR과 CSR에 대해서 들어본적이 있을겁니다. 이번 포스팅에서는 SSR과 CSR이 뭔지, 그리고 어떤 특징과 장단점이 있는지에 대해서 다룹니다.

SSR(Server Side Rendering)

SSR은 Server Side Rendering 의 약자입니다. 이름에서도 들어나듯, 웹 페이지의 렌더링을 서버측에서 담당하여 전송하는 방식입니다.

흔히, 어떤 페이지를 가져와야 한다는 요청이 있으면, 서버가 그 화면에 대한 html 을 계산하여 클라이언트로 보내주는 형식입니다.

html 이 도착한 다음, 브라우저는 받은 html 파일을 가지고 웹페이지를 렌더링 하게 됩니다. 그 다음, 렌더링된 페이지에 기능을 입히기 위해서 서버에 js 파일을 요청합니다. js 파일을 다운받게 되면, 웹 페이지에서 특정 기능을 수행할 수 있습니다.

서버로부터 완성된 html 파일을 전송받으므로, 첫 로딩 화면을 그릴때의 속도가 빠릅니다. 또한, 검색엔진에서 해당 웹 사이트를 판단하는 로직에서 완성된 html 을 분석하므로, 검색엔진 최적화(SEO)에서 이점이 있습니다.

전통적인 웹은 대부분 서버사이드 렌더링 방식이었습니다. 하지만, 요즘은 웹에 제공되는 정보가 너무 많아 이를 매번 서버가 렌더링을 하게 된다면, 요청수에 비례해서 서버에 부하가 생기게 됩니다.

또한, SSR 방식은 서버에 정보를 요청하고 html을 받아올때 마다 새로운 html 파일을 가지고 화면을 그리기 때문에 화면이 새로고침 됩니다. 예를들어, 상품에 대한 정보가 바뀌면, 상품만 리렌더링 하는것이 아니라, 화면 전체를 리렌더링 하는 방식입니다. 이는 사용자 경험에서도 불이익이 있습니다.

정리하자면 다음과 같습니다.

방식

사용자가 웹사이트에 요청을 보냄
서버는 렌더링 가능한 완성된 html을 만듦
브라우저느 서버에서 보내준 html을 빠르게 랜더링 함. 하지만 js 가 없어서 기능공백이 생김
브라우저가 js를 읽음
이제 유저는 콘텐츠를 보고 사용자의 조작도 기록됨
브라우저가 js 프레임워크를 실행함
5번에서 기록된 사용자 조작도 실행되고 페이지 상호작용도 가능해짐

장점

서버에서 완성된 html 을 받아서 렌더링 하므로, 초기 렌더링 속도가 빠름
검색엔진이 완성된 html을 검사하기 때문에, 검색엔진 최적화 (SEO)에서 이점이 있음

단점

어떤 정보가 바뀔 때 마다 서버에서 html을 새로 받아와야 한다. 즉, 서버의 부하가 증가함
html 을 받아와서 전체 html을 리렌더링 하는 방식이라 정보가 바뀔때 마다 화면이 새로고침 됨
html을 받아와서 렌더링한 다음에 js를 다운받기 때문에, 초기 렌더링 시 기능 공백이 생김

CSR

CSR 은 Client Side Rendering 의 약자입니다. SSR 이 서버에서 렌더링 하는 방식인것 처럼 CSR 은 클라이언트에서 렌더링을 하는 방식입니다. 여기서 클라이언트는 각 사용자의 컴퓨터에 설치된 브라우저를 말합니다.

서버에서 받은 데이터를 클라이언트인 브라우저가 화면에 그리게 됩니다. 바로 렌더링이 가능한 완성된 html을 서버에서 보내주는 SSR 방식과 달리 html 파싱부터 js 읽기까지 브라우저에서 하기때문에 처음에 화면을 띄우는데 시간이 좀 걸립니다.

지금 프론트엔드 프레임워크로 널리 사용되는 React프레임워크도 바로 이 CSR 방식입니다. 그리고 CSR 방식은 SPA(Single Page Application)과도 깊은 연관이 있습니다. SPA 는 하나의 html 로 운영되는 웹 애플리케이션을 말합니다. React 를 build 하게 되면, index.html 만 덩그러니 나오는 이유가 이것 때문이죠. 여기서 사용자의 인터렉션에 따라서 어떤 html을 만들어야 하는지 클라이언트가 판단하고, 서버에서 데이터를 받아온 후 렌더링 하는 방식입니다.

여기서, 리엑트를 빌드해보신 분들은 알 수 있습니다. index.html을 빌드하면, body 태그에 아무것도 없는 형태로 나오게 됩니다. 즉, 사용자의 인터렉션에 따라서 필요한 정보만 body 안에서 렌더링 되는 방식인 것입니다. 이렇게 하면, 특정 부분의 html 만 고친 후 리렌더링 하면 되기 때문에, 특정 정보가 바뀌었을 때, 화면이 새로고침 되는것이 아닌, 해당 정보를 가지고 있는 html 만 리렌더링 되어 사용자 경험이 좋아집니다.

하지만, 사용자의 인터렉션에서만 html을 만들기 때문에, 사용자가 하지 않은 인터렉션에 대해서는 html을 만들지 않습니다. 이러면 어떤 문제가 생길까요? 검색 엔진이 모든 html을 볼 수 없어서 검색엔진 최적화에서 불이익을 받게 됩니다.

최근 구글에서는 SPA 기반 CSR 애플리케이션에도 크롤링 봇이 잘 동작하게 만들었다고 했지만, 아직도 SSR 만큼 검색엔진 최적화가 안된다는 이야기들이 있습니다.

정리하자면 다음과 같습니다.

방식

사용자가 웹사이트에 요청을 보냄
CDN(Content Delivery Networ로 유저의 요청에 물리적으로 가까운 서버에서 요청을 응답하는 방식)이 빠르게 HTML파일과 JS파일에 접근할 수 있는 링크를 보냄
브라우저는 HTML,JS 파일을 다운받고 그동안 화면에는 아무것도 보이지 않음
브라우저가 JS파일을 읽음 (이때도 화면 안보임)
다운이 완료된 JS가 실행됨. 데이터를 위한 API가 호출됨 (이때 유저들은 placeholder를 보게된다. )
서버가 API 요청에 응답함
API로부터 받아온 data를 placeholder 자리에 넣어준다. 이제 페이지는 상호작용이 가능해짐 (초기 랜더링까지 시간이 많이 걸림)

장점

클라이언트가 계산하여 서버에 필요한 정보만 요청하기 때문에 서버의 부하를 줄여줌
모든 html을 다시 그릴 필요가 없기 때문에, 정보가 바뀌었을때 새로고침이 일어나지 않아도 됨
초기 로딩시 기능 공백이 없음

단점

초기 로딩 시간이 SSR에 비해 느림
모든 html을 렌더링 하지 않기 때문에 검색엔진 최적화에서 불이익이 있음