1. 개요
Angular, React 그리고 Vue가 등장한 이후로 Front-end를 개발하는 방법이 크게 바뀌었습니다. 이 글에서는 Reat와 Vue를 중심으로 내용을 구성했습니다.
JSP와 jQuery를 이용해서 화면을 만들때는 라우팅이 변경될 때마다 화면이 깜빡이면서 새로운 화면이 그려지는 것이 보통이었습니다. 우리는 이것을 MPA(Multi Page Application) 방식이라고 부릅니다. 그리고 동시에 화면이 어떤 방식으로 클라이언트(즉, 사용자의 브라우저)에게 어떤 방식으로 전달되느냐는 측면에서 SSR(Server Side Rendering)이라고 부를 수도 있겠습니다.
하지만, 이 때의 SSR은 React나 Vue를 이용해서 구현하는 SSR과는 다소 차이가 있습니다. 최초의 화면 렌더링의 주체가 누구인가? 하는 기준에서 바라본다면 큰 의미에서는 차이가 없겠지만 최초 렌더링 이후에는 hydration(수화)이 추가적으로 수행되고 MPA방식이 아니라 SPA방식으로 동작하므로 이 둘을 구분할 필요성은 있습니다. 그래서 이를 엄밀하게 구분할 때는 SR(server rendering)과 SSR with Rehydration이라고 구분합니다. (참고: 웹 렌더링) 이 글에서는 SSR이라고 언급하면 NextJS등에서 사용하는 SSR with Rehydration 방식을 말하는 것으로 하겠습니다.
이 글에서는 React나 Vue 그리고 NextJS에 대한 깊이 있는 설명은 하지 않습니다. 다만 해당 framework나 library의 렌더링의 특징에 대해서만 다룹니다.
2. 렌더링 순서
2.1. CSR (Client Side Rendering)
React를 기준으로 CSR방식의 화면 렌더링의 순서를 도식화 하면 아래와 같습니다.
- 클라이언트(브라우저) 에서 서버로 화면을 요청하고 서버는 클라이언트에 요청에 (거의 비어있는) HTML 파일을 응답으로 보냅니다.
- 서버로부터 받은 HTML은 거의 비어있기 때문에 사용자에게는 흰색 화면만 보입니다. 브라우저는 HTML에 링크된 자바스크립트 번들들을 다운로드 합니다.
- React가 적용됩니다. 이 과정에서 정적인 HTML에 추가적으로 DOM을 렌더링하고 Virtual DOM도 구축하고 이벤트 처리를 위한 기능들도 준비됩니다. 이를 Hydration(혹은 rehydration, 수화)이라고 합니다.
- Hydration(혹은 rehydration, 수화)이 완료되면 사용자가 브라우저를 통해 화면을 볼 수 있고 또 화면에서 제공하는 기능과 상호작용 할 수 있습니다.
2.2. SSR (Server Side Rendering (with hydration))
React를 기준으로 SSR 방식의 화면 렌더링의 순서를 도식화 하면 아래와 같습니다.
- 클라이언트(브라우저) 에서 서버로 화면을 요청하고 서버는 클라이언트에 요청에 렌더링이 가능한 HTML 파일을 응답으로 보냅니다.
- 서버로부터 응답받은 HTML은 렌더링이 가능한 상태이므로 화면이 렌더링되고 사용자는 화면을 볼 수 있는 상태가 됩니다. 브라우저는 HTML에 링크된 자바스크립트 번들들을 다운로드 합니다.
- Hydration(혹은 rehydration, 수화)이 수행됩니다. 최초화면은 이미 렌더링 되어있기 때문에 Virtual DOM과 이벤트 처리를 위한 기능들이 준비되는 과정입니다.
- Hydration(혹은 rehydration, 수화)이 완료되면 사용자는 화면에서 제공하는 기능과 상호작용 할 수 있습니다.
React를 이용한 SSR을 지원하는 Framework인 NextJS의 경우 1의 단계에서는 pre-rendering된 HTML을 생성하고 4의 단계 이후에는 일반적인 React처럼 동작합니다. 즉, SSR과 CSR의 특징을 모두 가진다고 보시면 됩니다.
3. 렌더링 방식의 상호비교
렌더링 방식에 대해서 살펴보면 Modern UI Framework에서 CSR과 SSR의 렌더링 방식에서 큰 차이점을 보이는 부분은 최초 로딩시의 렌더링 입니다. SSR의 경우 최초 로딩 이후에는 CSR 방식으로 동작하면서 CSR의 장점을 취하고 있기 때문입니다.
3.1. TTFB(Time to First Byte (첫 번째 바이트까지의 시간)) 관점
이 경우에는 CSR이 더 빠른 편입니다.
앞선 내용에서 렌더링의 첫번째 과정을 상기해 보면, SSR의 경우 서버에서 HTML 파일을 렌더링하는 과정이 필요합니다. 그 반면에 CSR의 경우에는 그런 과정은 필요없습니다. 이 때문에 대체로 TTFB의 관점에서는 CSR이 SSR보다 대체로 빠르다고 할 수 있습니다.
|
1
2
3
4
5
|
<!-- CSR의 경우 비어있는 HTML이 반환됩니다. -->
<head></head>
<body>
<div id="app">
</body>
|
|
1
2
3
4
5
6
7
|
<!-- SSR의 경우에는 서버에서 렌더링된 HTML이 반환됩니다. -->
<head></head>
<body>
<div>SSR에서는 HTML이 렌더링 된 상태로 반환됩니다.</div>
<div>이것이 CSR방식과의 큰 차이입니다.</div>
<div>서버에서 HTML을 렌더링해야 하기 때문에 CSR과 비교하면 대체로 SSR이 사용자의 요청에 반응하는 데에 시간이 더 걸립니다.</div>
</body>
|
3.2. TTV(Time To View, 사용자에게 화면이 보이는 시점)의 관점
이 경우에는 SSR이 더 빠른 편입니다.
SSR의 경우에는 이미 화면이 렌더링되서 반환되기 때문에 (Re)Hydration 이 수행되지 않아도 사용자는 화면은 볼 수 있습니다. 반대로 CSR의 경우에는 hydration이 완료되어야만 화면을 확인할 수 있습니다. 이 때문에 동일한 콘텐츠를 대상으로 비교하면 FCP의 관점에서는 대체로 SSR이 CSR보다 빠르다고 할 수 있습니다.
3.3. TTI(Time To Interactive, 화면과 상호작용이 가능해지는 시점)의 관점
CSR과 SCR 사이에는 큰 차이가 없습니다. 두 방식 모두 (Re)Hydration이 완료돼야 화면과 상호작용이 가능해지기 때문입니다.
CSR 방식의 경우 화면이 사용자에게 보이는 시점과 상호작용이 가능한 시점차이에 큰 간격은 없습니다. 두 시점 모두 hydration이 완료되는 시점 이후이기 때문입니다.이와는 달리 SSR의 경우에는 렌더링된 화면은 이미 사용자에게 노출되어있고 Hydration이후에 상호작용이 가능해지게 된다는 점에서 차이가 있습니다.
4. 마무리
이상으로 Modern UI Framework 의 SSR과 CSR의 특징에 대해서 살펴봤습니다. 특히나 초기 렌더링을 중심으로 내용이 채워졌었습니다. 그리고 React 중심으로 작성되었지만 Vue와 Nuxt도 큰 틀에서는 위의 내용과 다르지 않으니 참고만 해주시면 될 것 같습니다.
이 글은 CSR 방식과 SSR방식 중 어느 것이 절대적으로 좋은 방법인가를 설명하기 위한 글은 아닙니다. 프로젝트의 상황에 맞는 렌더링 방식을 선택하시기 바랍니다.
최근댓글