Edge Side Rendering (SSR vs CSR vs ESR)

용어 정리

CSR

CSR은 Client Side Rendering의 약자로 말 그대로 브라우저(Client)에서 렌더링하는 것이다.

 

SSR

SSR은 Server Side Rendering의 약자로 서버에서 렌더링(html 파일 생성)하여 브라우저에 보내주는 것이다.

 

SSG

SSG는 Static Site Generation의 약자로 SSR과 다르게 빌드 시에 html을 미리 생성해놓는 것이다.

 

ESR

Edge Side Rendering의 약자로 Edge Computing을 이용해 사용자와 가까운 곳에 위치한 Edge 노드에서 렌더링에 필요한 데이터를 브라우저에 제공하는 역할을 한다. 흔히 서버리스 개념으로 보면 편하다. 아래 설명을 보면 이해되겠지만 Edge node에서 렌더링을 하는 것은 아니기 때문에 Edge Slice Rerendering의 약자로도 사용된다.

 

TTFB

TTFB(Time to first byte)의 약자로 브라우저에 첫 번째 바이트가 응답되는 데까지 걸리는 시간이다. DNS 등 각종 시간을 포함한다.

TTFB가 전체 페이지 로드 시간은 아니지만 TTFB가 빠를수록 서버의 응답 속도가 빠르다는 뜻이기 때문에 중요한 지표로 사용된다.

 

개요

유튜브 같은 동영상 플랫폼의 사용자 맞춤형 동영상 검색 결과 페이지를 개발한다고 가정하자.

이런 경우 SSR, CSR, SSG 어떤 방식으로 개발하는 것을 생각할 수 있을까?

 

비교

 

SSR 방식

 

SSR 방식은 요청이 오면 html을 생성한 후 응답하고 렌더링하기 때문에 html이 만들어지는 시간이 길어질수록 사용자는 흰 화면을 계속 보고 있어야 한다. 또 매 페이지 요청마다 위 과정이 반복되기 때문에 굉장히 불편한 UX를 선사해줄 수 있다.

 

 

 

SSG + CSR 방식

 

SSR 방식의 불편한 UX를 해결하기 위해 최근엔 SSG 방식을 많이 사용한다. 먼저 쇼핑몰 상품 목록의 템플릿을 빌드 시에 미리 만들어놓고 요청이 오면 만들어놓은 html 파일을 신속히 제공한다. 이렇게 하면 TTFB를 굉장히 단축시킬 수 있다. 당연히 ux도 훨씬 좋아진다. 유튜브에 검색을 하면 스켈레톤 이미지로 회색 음영 이미지가 먼저 보이고 나중에 동영상 목록이 채워지는 것을 볼 수 있는데 그게 이런 원리다

 

당연하지만 SSG 방식은 빌드 시에 html이 만들어지기 때문에 검색결과 같은 동적 컨텐츠를 만들어놓을 수 없다. 그 경우 CSR 방식으로 로딩하는 것이 필요하다.

 

물론 SSG+CSR 말고 SSG+SSR 방식도 가능하다. 하지만 그렇게 하더라도 동적 컨텐츠를 가져오는 시간은 같기 때문에 큰 차이가 없다.

 

 

CDN SSG + CSR 방식

 

SSG+CSR 방식은 좋은 ux를 줄 수 있지만 한 가지 큰 문제가 있다. 서버와 사용자 간의 물리적 거리가 멀어서 네트워크 지연시간이 길다면 TTFB도 그만큼 길어지는 문제가 발생한다. 한국의 사용자가 미국 동부 오하이오에 있는 서버에서 받아온다고 생각하면 된다.

 

그래서 배포 시에 한국에 CDN 서버에 정적 컨텐츠를 CDN에 미리 올려놓는 방식을 많이 사용한다. 위 그림에서 Edge가 CDN이라고 보면 된다.

 

이렇게 하면 위 문제를 상당 부분 해결할 수 있고 로드밸런싱도 가능하다.

 

 

ESR 방식

 

CDN 방식은 현재 많이 사용되고 있다. 하지만 최근 웹은 개인화된 페이지가 많아지면서 동적 컨텐츠를 포함하는 일이 아주 많다. 결국 동적 컨텐츠를 빨리 가져와야 사용자에게 높은 ux를 보여줄 수 있다.

 

ESR 방식은 사용자가 직접 서버에 동적 컨텐츠를 요청하는 것이 아니라 사용자와 가까운 Edge Node에 요청을 보내고 그 노드가 다시 서버에 요청을 보내서 응답을 받아오는 방식이다.

 

다만 여기서 중요한 점은 응답이 스트리밍 된다는 것이다.

기존에는 버퍼 사이즈가 다 찰 때까지 기다린 후 모아서 응답을 하는 것이 일반적이다.

다만 그렇게 하면 TTFB가 느리기 때문에 응답을 조금씩 나누더라도 보낼 것이 생기면 바로 응답하는 방식이 stream response이다.

 

또 이렇게 Edge Node가 사용자 대신 받아오면 더 좋은 점은 모든 상황에서 그런 것은 아니지만 보통 사용자와 서버 간의 네트워크 보다 Edge Node와 서버 간의 네트워크 지연 시간이 더 짧은 경우가 많다. 둘 사이의 통신 방식도 훨씬 선택지가 많다. 즉, 최적화 요소가 많은 점이다. 한 마디로 Edge Node가 물류센터 같은 역할이 되는 것이다.

 

결론

프론트엔드에서 개인화된 페이지가 많아지면서 사용자 개인정보를 담은 동적 컨텐츠를 어떻게 빨리 가져오냐가 새로운 트렌드로 다가오는 것으로 보인다. ESR은 기존 CDN의 정적 컨텐츠만 제공하는 한계를 극복하여 Edge Computing을 활용해 동적 컨텐츠를 포함하는 페이지의 TTFB를 어떻게 줄일 수 있는지 프론트엔드의 향후 미래를 엿볼 수 있었다.

 

Next.js의 가장 최신 버전인 12와 React 18 버전의 동향을 보면 프론트엔드의 현재 핵심 키워드는 Streaming이라고 생각한다. next.js 12버전 구성요소들을 보면 스트리밍 기능을 활용해 항상 전체 hydration이 되어야 하는 단점을 극복하여 부분적으로 hydration을 제공한다. 또 12.2에서는 Edge Api Routes 기능을 제공하는데, 이 기능은 위에서 ESR 부분에 표시한 stream response를 Edge Node에서 어떻게 보여줄 수 있는지 보여준다.

 

Streaming SSR을 보여주기 위한 기술은 Web API의 Streaming API인데 현재 대부분 브라우저에서 제공되고 있다.

stream response에 대한 포스트는 다음 포스트에서 직접 코드를 살펴보며 올리도록 하겠다.

 

 

참고

https://www.alibabacloud.com/blog/esr-optimizes-frontend-performance-by-using-edge-computing-capabilities-of-cdn_596863

https://nextjs.org/docs/api-routes/edge-api-routes#differences-between-api-routes