서버 사이드 렌더링(SSR)이란? - CSR vs SSR(+SSG)

SSR(Server-side Rendering)이란?

간단히 말하자면 제공하고자 하는 웹 서비스의 화면을 서버 측에서 그리는 방법을 통칭하는 용어다. 웹 서비스는 결국 화면으로 보여줘야 하고 그걸 그려야 하는데, 클라이언트 단에서 그리냐 서버 단에서 그리냐의 차이가 있을 뿐이다.

 

이전 글에서 알아봤던 CSR은 웹 사이트 패러다임에 대단히 큰 변화를 가져왔지만 모든 기술에는 양면이 있다. 이제 CSR의 장단점을 조금 더 들춰볼 차례로, 그 특징을 좀 더 자세히 들여다보려면, 반대편에 있는 기술인 SSR이 어떻게 돌아가는 기술인지 간략하게 체크해볼 필요가 있다.

 

CSR은 서버로부터 페이지 렌더링에 필요한 asset들을 받아 브라우저에서 렌더링하고, SSR은 서버에서 페이지를 렌더링하고 브라우저로 보내준다.

 

SSR은 CSR에 비해 SEO(Search Engine Optimization)에 유리하다

크롤러 입장에서 렌더링이 되지 않아 정보가 없는 페이지는 인덱싱(indexing) 처리가 어렵다. 이 사실을 이해하고 나면 SSR, SSG가 SEO에 왜 유리한지 받아들이기 쉬울 것이다. 검색이 된다는 것은 어딘가의 DB에 정보가 적재되어 있다는 것이고, 정보가 적재되어 있다는 뜻은 가져갈 원본 정보가 있었다는 뜻이다.

 

SSR은 CSR에 비해 서버 부하가 크다

SSR은 서버에서 하는일이 많아지는 것이니 당연한 말이다. SSR은 서버 측에서 처리해야 하는 렌더링 로직 때문에 반드시 응답을 처리해줄 서버가 필요하다. CSR only 서비스보다 서버가 할 일이 많고 바쁘다. 트래픽이 많이 몰릴 경우 응답이 느려지거나, 메모리가 한도를 초과해 서버가 동작을 멈추게 될 수도 있다.

 

CSR only 서비스의 경우 미리 빌드해둔 HTML, CSS, JS 파일을 S3 등의 저장소에 올려두고, Cloudfront 등의 CDN을 붙여 별도의 컴퓨팅 자원 없이 정적으로 제공할 수 있다. 서버에서 렌더링하는 로직이 없고, 동일한 응답을 돌려주어 캐싱이 용이한 특징 덕분에 SSR보다 많은 트래픽을 효과적으로 받아낼 수 있다.

 

SSR vs SSG(Static Site Generation)

SSR은 요청이 들어왔을 때 서버 측에서 렌더링이 일어나지만, SSG는 개발자가 개발을 완료하고 빌드하는 순간에 렌더링이 일어난다. 때문에 SSG는 SSR보다 정보의 변화가 적은 사이트에 적합하다.

 

SSR은 요청이 들어올 때마다 요청에 맞는 페이지를 렌더링하는 반면, SSG는 빌드할 때부터 페이지가 전부 렌더링 된 상태로, 이미 완제품이기 때문에 사용자가 이런저런 요청을 한다고 해도 서버에 미리 준비된 페이지들을 가져가는 것 외에는 할 수 있는 방법이 없다.

 

SSG는 내용물을 수정하기 힘들다는 단점이 있지만, SSR과 같이 서버에서 페이지가 렌더링해서 보내주기를 기다리지 않고, 필요한 페이지를 바로 가져올 수 있어 훨씬 간단하고 빠르다는 장점이 있다.

 

CSR, SSR, SSG 기반 React 앱의 실행 과정

CSR(Client-side Rendering)

CSR 실행 과정

• 서버에 최초 GET 요청
• 빈 HTML
• JS, CSS 등 asset 다운로드
• JS 파일 실행
• React 실행 후 React에 의한 렌더링
• 화면에 출력

SSR(Server-side Rendering)

SSR, SSG 실행 과정

• 서버에 최초 GET 요청
• 서버 측에서 요청 경로를 보고 알맞게 React 앱 렌더링
• 생성된 HTML 응답
• 화면에 출력

SSG(Static Site Generation)

• 서버에 최초 GET 요청
• CDN
• 미리 완성된 HTML 응답
• 화면에 출력

SSR과 SSG는 서버 로직이 있냐 없냐의 차이일 뿐 실행 과정은 같다. 

 

CSR과 SSR의 렌더링 성능 차이

먼저 몇 가지 성능 관련 용어를 알아보자.

 

TTFB(Time to First Byte)

• HTTP 요청을 했을 때 처음 byte(정보)가 브라우저에 도달하는 시간을 의미한다.
• 즉, 어떤 리소스를 요청하고 해당 요청에 대한 첫 번째 데이터가 도착하기까지 걸리는 시간을 의미한다.

 

FCP(First Contentful Paint)

• 사용자가 화면에서 콘텐츠를 볼 수 있는 페이지 로드 타임라인의 첫 번째 지점을 표시하기 때문에 사용자가 감지하는 로드 속도를 측정할 수 있는 중요한 사용자 중심 메트릭이다.
• FCP가 빠르면 사용자가 서비스를 더 빠르게 이용할 수 있다.

 

TTI(Time to Interactive)

• 앱이 사용자와 상호작용하기에 준비가 된 시점을 뜻하며, 화면이 그려지는 것과는 거의 무관하다.
• 자바스크립트 이벤트가 걸린 버튼을 눌렀을 때, 해당 버튼이 제대로 이벤트 리스너에 연결된 함수를 호출하는 최초의 시점이다.

 

렌더링 성능 측면에서 CSR, SSR 두 방식을  중심으로 살펴보자.

 

CSR

• 빈 화면(TTFB fast, TTI slow)
• 번들 크기가 커질수록 두드러진다
• 코드 스플리팅, 번들 압축, 트리 쉐이킹이 중요하다

 

SSR

• 느린 응답(TTFB slow, TTI fast)
• 싱글 스레드 renderToString 메서드의 특징 상 최초 응답이 늦어질 수 있다
• 번들 크기가 커질 경우 TTI까지 속도가 느려져 CSR과 마찬가지 단점을 가질 수 있다

 

렌더링 방식에 따른 특징과 장단점을 정리한 표