CSR과 SSR
✔️ CSR(클라이언트 사이드 렌더링)과 SSR(서버사이드 렌더링)을 비교해서 살펴보자
CSR
- 한 문장으로 정리를 해 보면 브라우저에서 컨텐츠를 그리는 동작을 직접 하는 것을 의미한다
처음에 클라이언트가 서버로부터 리소스를 받아올 때 HTML 파일을 받아오는데 그때 빈 HTML 파일만 받아오게 된다. 그러면 사용자 입장에서는 화면에서 그 HTML 파일이 보여지더라도 아무것도 이제 볼 수가 없는 흰 화면만 나타나게 된다. 그 빈 뼈대를 가지고 그 다음에 브라우저가 자바스크립트 파일을 다운로드를 받는다. 그렇게 됐을 때 자바스크립트 안에서 이 HTML 안에 컨텐츠들을 그려주는 로직들이 포함이 되게 되어 있다. 그래서 그렇게 자바스크립트가 실행이 되면서 컨테츠가 만들어지고 렌더링이 되어지면서 보여지는 컨텐츠가 나타나고 인터랙터블한 요소들까지 나타내는 방식이 바로 클라이언트 렌더링이다.
즉, 자바스크립트로 동적으로 페이지를 만들어지는 과정을 클라이언트 사이드에서 진행을 한다는 것이다.
그렇기 때문에 처음에 HTML을 받아서 자바스크립트 파일을 클라이언트에서 불러와서 기다렸다가 그 그리는 과정을 다 기다렸다가 가야 되기 때문에 초기 로딩 속도가 좀 느리다는 특징을 가지고 있다. 하지만 이렇게 브라우저를 한 번 다 그리고 나서 그 다음에 만약에 페이지에서 어떤 변경을 해야 될 때는 이 HTML을 다 다시 그릴 필요가 없이 그 해당 부분만 데이터를 받아와서 자바스크립트로 바꿔서 만들어 줄 수가 있기 때문에 이후에는 굉장히 빠르게 바꿔줄 수 있다는 장점을 가지고 있다.
그리고 클라이언트 사이드가 가지고 있는 또 하나의 장점은 이 HTML만 브라우저에서 받아서 그다음에 자바스크립트를 받아서 그려주는 방법이기 때문에 서버 측에서는 이 렌더링을 해줘야 되는 부담이 상대적으로 적다. 그리고 클라이언트 쪽에서 어떤 연산이라든지 라우팅 같은 작업들로 직접 다 처리하기 때문에 반응 속도가 굉장히 좀 빠르고 UX가 좋다는 장점도 있다.
하지만 반대로 아까 이야기 했던 것처럼 클라이언트에서 HTML 파일을 빈 파일로 받아오기 때문에 구글이나 네이버 같은 검색엔진의 입장에서는 이 HTML을 통해서 정보를 수집해서 검색엔진에서 노출시켜줘야 하는데 (SEO) 그렇게 수집을 하기가 어렵다. 즉, SEO 측면에서는 상당히 불리한 측면을 가지고 있다.
SSR
- 서버사이드 렌더링은 유저가 웹 사이트에 방문을 해서 그 브라우저에서 서버로 컨텐츠에 대한 요청을 보냈을 때 서버에서 그 요청을 받아서 HTML, CSS 그리고 페이지를 만들깅 위해 필요한 요소들을 다 렌더링을 해준다. 그러면 그 응답을 브라우저에서 받아서 유저에게 보여지는 것이다.
- 즉, 사용자가 볼 수 있는 시간이 굉장히 빠르다는 특징을 가지고 있다.
- 그 다음에 이제 자바스크립트 코드를 브라우저에서는 다운로드를 받게 되는데 그 이후에 자바스크립트 코드를 실행을 시켜 주면서 이 작업을 하이드레이션 작업이라고 한다.
- 이러한 하이드레이션 작업이 이루어지고 나서 사용자가 이벤트를 정상적으로 수행할 수 있는 그런 인터랙터블한 화면을 마주할 수 있다.
즉, 서버사이드 렌더링은 컨텐츠를 서버에서 만들어준다라는 특징을 가지고 있다. 아무래도 서버에서 만들어서 한 번에 전달을 해주기 때문에 빠르게 화면을 볼 수 있다는 가장 큰 장점을 가지고 있으며 사용자 입장에서는 바로 화면을 볼 수 있기 때문에 구글이나 네이버 같은 검색엔진에서도 검색엔진 봇이 돌면서 그 컨텐츠들을 HTML에서 읽기도 수월하다.
SSR 단점
- 보여지는 상태랑 인터랙터블한 상태 사이에 간격이 있기 때문에 이 시간 간격이 있다는 점이 단점으로 작용을 할 수 있다.
- 매번 서버에서 컨텐츠를 렌더링을 해줘야 하기 때문에 그 연산에 대한 부담이 서버 측에 굉장히 많이 갈 수가 있다. 즉, 시스템적으로 부하를 분산시킬 수 있는 고민도 같이 해줘야 될 수가 있다.
CSR vs SSR 어떤 것을 사용해야 하는가?
- 클라이언트 사이드 렌더링은 이렇게 자바스크립트를 다운로드를 받아서 렌더쉘을 이제 그리는 작업을 하고 그다음에 데이터베이스에 쿼리를 하고 컨텐츠를 그리는 방식이라면
- 서버사이드 렌더링은 먼저 서버에서 렌더쉘이 일어나고 그다음에 클라이언트로 와서 자바스크립트를 다운로드 받아서 하이드레이션을 거치고 그다음에 데이터베이스 쿼리를 하고 렌더 컨텐츠를 수행을 한다.
| CSR | SSR | |
| First Contentful Paint(FCP) | 느림 | 빠름 |
| 상호작용(Interaction) | 부분 렌더링(자바스크립트) | 페이지 전체 렌더링(HTML) |
| 검색엔진 최적화(SEO) | 불리함 | 유리함 |
| 서버 부담 | 낮음 | 높음 |
| Time To First Byte(TTFB) | 빠름(빈 페이지 응답) | 느림(렌더링 후 응답) |
결론(그럼 뭐를 써야할까?)
정해딘 답은 없다. 서비스마다 주어진 조건이 다르고 환경이 다르기 때문에 이 서비스는 무조건 클라이언트 혹은 서버 사이드 렌더링을 해야 돼 라고 말을 할 수는 없다. 하지만 전반적으로 살펴봤을 때 만약에 유저와 상호작용하는 부분이 많다? 그리고 대부분 개인정보가 많이 있어서 검색엔진에 굳이 노출될 필요가 없다? 하는 서비스라면 클라이언트 사이드 렌더링을 쓰는 것도 굉장히 도움이 될 수 있을 것이다. 상호작용이 많기 때문에 클라이언트 사이드 렌더링에서 훨씬 더 빠르게 처리할 수 있기 때문이고 검색엔진에 걸리지 않기 때문에 개인정보나 이런 민감한 정보들에 대해서 노출되는 걱정도 적게 할 수가 있다.
반대로 만약에 어떤 페이지가 회사의 홈페이지라서 검색엔진에도 잘 걸려야 되고 검색엔진 상위 노출도 필요하다? 그리고 모두에게 항상 동일한 내용을 보여준다? 즉, 이런 인터랙션이 자주 일어나지 않는다 그리고 페잊의 데이터가 좀 자주 바뀐다? 이런 특징을 가진다면 서버 사이드 렌더링을 고민해 보는 것도 좋은 방향이다. 아무래도 검색엔진 최적화에 유리하고 항상 같은 내용을 보여주는데 더 빠르게 보여줄 수도 있고 인터랙션이 적다면 처음에 빨리 보여주는 게 굉장히 중요하기 때문이다.