CSR, SSR 그리고 Pre-rendering

🖐🏻 들어가며

사실 Next.js 에서의 styled-component 를 사용하는 것과 관련해서 심각한 고민에 빠져있었어서 이 부분에 대한 트러블 슈팅을 작성하던 도중ㅋㅋㅋ 또크 털깎기로 CSR, SSR, Pre-rendering 에 대해 제대로 알고 가야겠단 생각이 들었…다 하하

React 공부를 처음 시작할 때 해당 부분에 대해 충분히 공부했다고 생각을 했었는데, 막상 이 부분에 대해 제대로 설명할 수 있는가? 를 스스로 질문해보니 그렇지 못했기에.. 이번 기회에 제대로 해야겠다는 생각에 다시 공부를 해봤다.

👩🏻‍💻 Client Side Rendering

출처 : https://www.blog.duomly.com/client-side-rendering-vs-server-side-rendering-vs-prerendering/

↔️ CSR process

유저가 웹 사이트에 진입(request)한다.
CDN 은 최소한의 HTML 파일을 다운로드(response) 한다.
- index.html : script, meta, link 등의 태그를 포함하며 빈 컨텐츠를 담고 있다.
브라우저는 index.html 에 있는 JavaScript 번들 파일을 다운로드 한다.
api 요청을 수행해 동적 컨텐츠를 가져와 파싱하고 최종 컨텐츠를 렌더링한다.
유저가 페이지를 이동한다면 서버에 추가 html 파일을 요청하지 않고 이미 받은 javaScript 를 이용해 렌더링한다.

🌐 Server Side Rendering

출처 : https://www.blog.duomly.com/client-side-rendering-vs-server-side-rendering-vs-prerendering/

🌐 SSR Process

유저가 웹 사이트에 진입(request)한다.
CDN 은 리소스를 확인하고 페이지 내에 있는 서버측 스크립트를 실행해 HTML 컨텐츠를 컴파일 및 준비한다.
컴파일된 HTML 은 추가 렌더링 및 표시를 위해 클라이언트 브라우저로 전송된다.(response)
브라우저는 HTML 을 다운로드하고 최종 사용자가 사이트를 볼 수 있게 한다.
브라우저는 JavaScript 를 다운로드하고 실행하며 페이지를 interactive 하게 만든다.
유저가 페이지를 이동하면 위 동작이 반복된다.

🤬 Uncanny Valley

출처: https://crystallize.com/blog/frontend-performance-react-ssr-and-the-uncanny-valley

SSR 방식으로 화면을 렌더링 했을 때, View 가 그려진 후 JavaScript 가 다운로드될 때 까지 인터랙션이 일어날 수가 없다. 만약 그 사이 다운로드가 완료되면 그 때부터 유저는 사이트와 인터랙션을 할 수 있는데, 뷰는 있지만 인터랙션이 안되는 구간을 “Uncanny Valley(불쾌한 골짜기)”라고 한다.

🤔 CSR vs SSR

CSR 과 SSR 의 렌더링 방식에서의 차이점은 결국 렌더링을 서버측에서 담당하는지, 클라이언트측에서 담당하는지이다. CSR 은 최소한의 html 파일을 받은 후, 앱에서 사용되는 모든 js 코드를 다운로드 받아 DOM 요소를 추가하는 방식이라면, SSR 은 페이지에 대한 모든 것들을 서버측에서 다운로드 받아 그려낸다.

CSR 의 경우는 첫 진입 시 모든 js 코드를 로드해야하므로 초기 렌더링 시간이 오래 걸린다. 하지만, 이후에는 추가적인 로드가 필요한 것이 아니기 때문에 부드러운 유저 경험을 제공한다. 화면 내에서 다른 페이지로 이동하는 경우라고 하더라도, html 소스를 서버에서 받는 방식이 아닌 클라이언트 측에서 처리하므로 훨씬 빠른 편이다.

그러나 처음 다운로드 받는 javaScript 번들 사이즈가 클 경우에는 초기 렌더링 속도가 현저히 느려질 수 있으므로 이에 대한 최적화 방법에 대해 계속 고민해야한다. 또한 html 을 미리 만들어두는 방식이 아니고 유저의 요청에 따라 생성되므로 SEO(serach engine optimization : 검색 엔진 최적화) 대응이 어려운 편이다.

SSR 의 경우는 CSR에서 발생하는 초기 렌더링 속도, 번들 사이즈, SEO 등의 문제점 개선을 위해 과거의 static site 로 돌아간 방식이다. CSR 과는 다르게 서버에서 html 을 만들어 제공한다. 그렇기 때문에 SEO 최적화가 잘 이루어지며 각 페이지별로 다운이 되므로 초기 렌더링 속도도 빠른 편이다.

🤨 CSR 과 SSR 선택은 어떤 것을 기준으로 잡으면 좋을까?

SSR

느린 네트워크를 사용할 때 (SSR은 각 페이지별로 응답값을 받아오기 때문!)
SEO 최적화를 필요로 할 때
빠른 초기 렌더링을 필요로 할 때
메인 스크립트가 크고 로딩이 매우 느릴 때
웹 사이트 내에서 상호작용이 별로 없을 때

CSR

네트워크가 빠를 때
서버 성능이 좋지 않을 때
사용자에게 보여줘야 하는 데이터의 양이 많을 때
메인 스크립트가 가벼울 때
SEO 최적화가 중요하지 않을 때
웹 사이트 내에서 상호작용이 많을 때

🚀 Pre-rendering

출처 : https://www.blog.duomly.com/client-side-rendering-vs-server-side-rendering-vs-prerendering/

Next.js 공식문서 도입부를 보면 아래와 같이 나와있다.

By default, Next.js pre-renders every page. This means that Next.js generates HTML for each page in advance, instead of having it all done by client-side JavaScript. Pre-rendering can result in better performance and SEO.

Each generated HTML is associated with minimal JavaScript code necessary for that page. When a page is loaded by the browser, its JavaScript code runs and makes the page fully interactive. (This process is called hydration.)

기본적으로 Next.js 는 모든 페이지를 pre-rendering 한다. 여기서 말하는 pre-rendering 은 Next.js 가 client-side javascript 로 모든 작업을 수행하는 대신, 미리 각 페이지에 대해 html 을 만들어두는 것을 의미한다. pre-rendering 은 SEO 에서 더 나은 퍼포먼스를 보여준다.

이렇게 생성된 html 은 페이지가 브라우저에 로드될 때 해당 JavaScript 코드가 돌아가고 완전한 interactive page가 되도록 만드는데, 이를 hydration이라고 한다.

Next.js 에서의 Server-side rendering 과 Static Generation 은 모두 pre-rendering 방식이며 필요한 data fetching 과 HTML 렌더링이 client 에 보내지기 전에 이미 수행이 된다. 이를 통해서 client 는 non-interactive 한 페이지를 빠른 시간에 전달받을 수 있으며, 컴포넌트에 필요한 이벤트 리스너와 같은 interactive 한 속성들은 별도의 번들로 전달을 받아서 client 측에서 hydration 이 이루어진 뒤에 우리가 사용하는 웹앱이 된다.

🌧️ hydration

pre-rendering 방식으로 구축된 초기 DOM은 동적인 이벤트가 없는 메마른 상태의 뼈대이다. 이 메마른 곳에 수분을 보충하는, HTML 과 JavaScript 를 서로 매칭시켜 동적인 웹 사이트를 브라우저에 렌더링 시키는 기술을 Hydration 이라고 한다. 아래의 그림을 참고하면 더 이해가 쉬울 것이다.

render() 함수와 hydrate() 함수도 비교를 해보자.

ReactDOM.render(element, container, [callback]);
// 제공된 container 에 element 를 렌더하고, component에 대한 참조를 반환
// 기존 자식을 덮어쓰지 않고 기존 DOM 노드에 구성요소를 Insert

ReactDOM.render() 함수는 특정 컴포넌트를 두 번째 파라미더인 지정된 DOM 요소 하위로 주입해 렌더링을 처리해주는 함수이다. 렌더링이 완료되면 특정 이벤트를 처리할 콜 백 함수를 세 번째 파라미터로 넣을 수 있다.

ReactDOM.hydrate(element, container, [callback]);
// 기존 마크업에 이벤트 리스너를 붙여주는 과정

ReactDOM.hydrate() 함수는 특정 컴포넌트를 두 번째 파라미터인 지정된 DOM 요소의 하위로 hydrate 처리만 담당한다. 렌더링을 통해 새로운 웹 페이지를 구성할 DOM 을 생성하는 것이 아닌, 기존 DOM Tree 에서 해당하는 DOM 요소를 찾아 정해진 javascript 속성들만 부착시킨다는 의미이다.

🥲 이해가 어려웠던 부분,

CSR 과 SSR 의 렌더링 방식의 차이점을 이야기하라고 하면 너무나 명확해서, 설명이 쉬웠는데 여기서 Pre-rendering 과 SSR의 차이는 무엇인지 처음에는 눈에 확 들어오지 않았다. 결국은 HTML 을 서버에서 그려주고 응답으로 내려주면, 이후에 JavaScript 코드가 돌면서 인터랙티브한 웹사이트가 된다는것 아닌가? 싶었기에..

하지만 이 두가지의 차이점이라고 한다면 JavaScript 코드의 다운로드 시점에 주목해야할 것 같다. 아래 그림들을 비교하면 Pre-rendering 의 경우에는 JavaScript 는 서버에서 static HTML 을 보내주는 시점에 함께 전송이 되지만, SSR의 경우에는 HTML을 클라이언트 측에 보내어 렌더링을 끝낸 시점에 JavaScript 다운로드가 이루어진다.

흠 그럼 SSR에서의 Pre-rendering 으로 Uncanny Valley 를 줄였다고 보면되는걸까..? Hoxy 잘못된 부분이 있다면 댓글달아주십쇼!

출처 : https://www.blog.duomly.com/client-side-rendering-vs-server-side-rendering-vs-prerendering/

👩🏻‍🌾 마무리

사실 공식문서를 보면서 응 그냥 이런게 있구나~ 하면서 넘겼던 부분들을 제대로 짚을 수 있어서 좋았다. 그리고 사실 이것들을 보기 전에 겪고있던 문제에 대해서 조금은 감이 좀 잡힌 것 같아서 얼른 다시 찾아봐야겠다. 내가 생각하는 부분이 맞는지…! 그리고 Next.js 에서의 여러가지 렌더링 방식도 조만간 제대로 정리를 해봐야겠다. 오늘도 공부할 것들 하나 지웠고, 두 개가 추가되었다! 😏

CSR, SSR 그리고 Pre-rendering

🖐🏻 들어가며