[WEB] React, SSR(Server Side Rendering),CSR 차이, 백신 서버는 왜 터졌을까...

어제 썼던 SEO에 SSR이 유리하다. 라고 하면서 CSR,SSR에 대해서 포스팅 한다고 했었습니다.

​

두개를 알아보겠습니다.

​

​

​

1. SSR (Server Side Rendering)

​

위의 사진처럼 SSR의 장점은 CSR 보다 먼저 사용자에게 페이지를 보여줄 수 있다는 점입니다.​

​

처음에 페이지를 켰을때, react를 실행시키고 js를 dom으로 변환해서 보여주기까지 시간이 걸린다고 했습니다.

그러면 그동안 사용자는 빈 페이지만을 보거나, 로딩페이지를 보고 있어야 합니다.

그런것보다는 페이지의 일부를 보는것이 UX가 좀 더 좋다고 느낄 수 있습니다.

​

​

1. 서버는 미리 넣어둔 HTML 파일을 렌더링 할 준비가 됐다고 response 합니다

2. 브라우저가 OK라고 하고 HTML페이지를 렌더링 해서 보여줍니다. 이때부터 사용자들이 볼 수 있는거죠.

3. 그 이후 js 번들을 다운받고, React를 실행시킵니다.

4. 리액트가 실행이 된 이후에 이제 Interact (클릭같은것)을 할 수 있습니다.

​

​

2. CSR (Client Side Rendering)

​

​

그에비해 CSR은

​

1. 서버에서 Browser에게 응답을 합니다.

2. 브라우저는 이제 js를 다운받습니다.

3. React를 실행시킵니다

4. 페이지가 나오면서 동시에 interact까지 할 수 있습니다.

​

이 과정에서 얻는것은 굉장히 빠른 사용자가, 화면이 나오자마자 눌러도 응답할 수 있다는 점 입니다.

​

​

공통점은 CSR,SSR 둘다 js를 다운로드 받고, virtual dom 생성, event binding 이후 Browser DOM으로 옮기는 과정은 모두 거칩니다.

​

그렇다면 SSR은 CSR보다 나쁜점은 없을까요?

1. CSR의 장점이기도 한데, SSR은 미리 준비해둔 화면을 보여주고, brower가 react 실행을 마칠동안 이벤트가 바인딩 되어있지않아

클릭을 하더라도 React의 실행이 끝날때까지 응답이 없다는 단점이 있습니다

​

2. SSR TTFB(Time To First Byte)가 CSR에 비해서 느립니다. 왜 일까요?

서버에서 그냥 빈 페이지를 보내는것과, 뭔가 사람이 볼만한 HTML 코드를 추가해서 보내는것엔 분명한 시간 차이가 있습니다.

따라서 서버가 무언가를 만들어서 보내기에, CSR보다 SSR이 첫 바이트의 도착 속도는 느릴 확률이 훨씬 높습니다. (이건 always가 아닙니다)

같은 이유로, 서버에서 첫 응답을 하는 페이지들의 Size는 항상 CSR보다 SSR이 더 큽니다. 이것도 당연합니다, HTML 코드에 뭔가 적혀서 오기때문에 SSS > CSR 일 수 밖에 없습니다.

​

3. (중요)★

CSR의 throughput(출력량)이 SSR의 출력량보다 훨씬 많습니다. 이게 무슨뜻이냐면.. 처리량이 더 많다는 말로 받아들여도 좋습니다.

React의 renderToString은 서버에서 HTML을 만들어서 보내게 하는 작업입니다. 또한 SEO를 위해서 크롤링을 할 수 있게 사용하는 용도도 있습니다.

​

바로 저게 문제가 됩니다. 저 함수는 synchronous call 입니다. 따라서 저걸 하는동안 다른 작업을 못합니다.

SSR에서 페이지 1개를 렌더링 하는데 500ms가 걸리면 그 동안엔 아무것도 할 수 없습니다.

그래서 너무 많은 양을 렌더링하려고 욕심내면 오히려 성능이 저하됩니다.

​

이 글에서 이러한 예시도 보여줍니다

SSR은 서버에서 먼저 렌더링을 해서 보내주기에, 화면에서 좀 더 빨리 볼 수 있습니다.

속도차이가 좀 많이 나는것처럼 보입니다. 중요한점은 SSR이 화면은 다 나왔을지라도, click은 안된다는 점 입니다

​

=============

추가 21/07/21

 

서버에서 처리하는 파일의 사이즈가 커질수록 사용자가 많아졌을때 서버에 부담이 커지는 단점이 있을 수 있겠습니다.

이번 백신사이트가 터지는것도, 서버에서 보내주는 page의 size가 굉장히 커서, 사용자가 많아지면 금방 트래픽이 초과가 납니다.

폰트의 사이즈가 600kb입니다. 아래 jquery 파일이 300kb입니다. 두개만 불러도 1MB입니다.

1MB면 1000 명이면 1기가, 근데 1000만명이 접속했다고 뉴스에서 본 것 같은데...

1기가 * 10^4 = 10테라 입니다. 

 

심지어 1MB 훨씬 넘습니다. 2개만 합친거라서요.

페이지 한개 들어갔을뿐인데 이미 10테라입니다. 아찔합니다.

서버에다 너무 다 박아놓지 말아야 겠습니다.

제가 이걸 담당했다면 전 아마 미래의 사장님한테 잘렸겠죠.. 오늘 목숨 +1 했다고 생각해야겠습니다 ^^

 

 

서버 용량도 엄청 커야할 것 같네요.

모든건 trade-off가 있는 것 같습니다.

만능키는 없는것 같아요.

=============

​​

그래도 SSR이 훨씬 좋아보이는데 왜 안쓸까요?

​

여러 기술을 써서 스켈레톤UI같은걸로 떼우면 괜찮은 UX를 선사할 수 있을겁니다.

유튜브도 처음에 스켈레톤UI 나오던데.. 암튼! 여기까지..

 

-> 안쓰는게 아니라 '못' 쓰는겁니다.

SSR을 구축하려면 초기비용이 비싸다고 합니다. 그래서 작은 사이트들에서 SSR을 하기엔 부담이 되나봅니다.

그리고 flexible의 문제도 있군요..

​

​

공부해야할게 굉장히 많군요.

SSR의 단점은 TTFB가 있는만큼..

근데 TTFB가 느리면 왜 안좋을까요?

어쨌든 CSR은 TTFB 필요없고 SSR보다는 늦게 뜰텐데요..

​

이 부분에 대해서는 더 생각해봐야겠네요. 명확한 답을 할 만큼 알지 못해서요..

​

끝!

 

---

reference:

https://developers.google.com/web/updates/2019/02/rendering-on-the-web

웹 렌더링  |  Web  |  Google Developers

https://medium.com/walmartglobaltech/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8

The Benefits of Server Side Rendering Over Client Side Rendering