[TIL] CSR vs SSR 🌍

🖥️ 렌더링

렌더링은 서버로부터 요청해서 받은 내용을 브라우저 화면에 표시해주는 것이다.

📡 클라이언트 사이드 렌더링(CSR)

클라이언트 사이드 렌더링(CSR)은 쉽게 말해서 클라이언트에서 모두 처리하는 것이다. (ex. React)

서버에서 전체 페이지를 한번 렌더링 하여 보여주고, 그후 사용자가 요청할 때마다
리소스를 서버에서 제공받아 클라이언트가 해석하고 렌더링 하는 방식이다.

서버 사이드 렌더링과 달리 서버에 HTML 문서를 요청하는 것이 아니라,
브라우저에서 자바스크립트로 콘텐츠를 렌더링 하는 것이다.
따라서 처음 다운로드 받을 때 꽤나 시간이 소요될 수 있다.

또한 추가적으로 데이터가 필요하면 서버로부터 데이터를 받아와서,
클라이언트 쪽에서 자바스크립트와 함께 동적으로 화면을 구성하여
사용자에게 최종적으로 화면을 보여주게 된다.

💡 CSR 작동 방식

브라우저 -> 프론트 서버 -> 브라우저 -> 백엔드 서버 -> 브라우저

⚡️ 장점

1) 사용자의 UX가 뛰어나다.

2) 서버에 요청하는 횟수가 훨씬 적기 때문에 서버의 부담 또한 덜하다.

⚡️ 단점

1) 사용자가 첫 화면을 보기까지의 시간이 오래 걸릴 수 있다.

2) 썩 좋지 않은 SEO(Search Engine Optimization)

이러한 문제점들 때문에, 서버 사이드 렌더링(SSR)을 도입.

💡 SEO

검색 엔진 최적화(search engine optimization)는 검색 엔진으로부터 웹사이트나 웹페이지에 대한 웹사이트 트래픽의 품질과 양을 개선하는 과정이다.

웹 페이지 검색엔진이 자료를 수집하고 순위를 매기는 방식에 맞게 웹 페이지를 구성해서
검색 결과의 상위에 나올 수 있게 한다. 웹 페이지와 관련된 검색어로 검색한 검색 결과 상위에 나오게 된다면 방문 트래픽이 늘어나기 때문에 효과적인 인터넷 마케팅 방법 중의 하나이며 비용처리 없는 마케팅이라고 할 수 있다.

구글과 네이버와 같은 검색 엔진들은 서버에 등록된 웹사이트를 돌아다니면서
웹사이트의 HTML 문서를 분석해서 우리가 검색할 때 웹사이트를 빠르게 검색할 수 있도록 도와준다.

하지만 CSR에서 사용되어지는 HTML의 바디는 앞선 예제처럼 대부분 텅텅 비어있기 때문에
검색엔진들이 CSR로 작성된 웹페이지를 분석하는데 많은 어려움을 겪고 있다.

📡 서버 사이드 렌더링(SSR)

SSR은 클라이언트에서 모든 것을 처리하지 않는다.

웹 사이트에 접속하면 서버에서 필요한 데이터를 모두 가져와서 HTML 파일을 만들게 되고,
만들어진 HTML과 HTML 파일을 동적으로 조금 제어할 수 있는 소스코드와 함께 클라이언트에게 보낸다.

그리고 클라이언트는 잘 만들어진 HTML 문서를 사용자에게 바로 보여주게 된다. (ex. Next JS)

💡 SSR 작동 방식

브라우저 -> 프론트 서버 -> 백엔드 서버 -> DB -> 백엔드 서버 -> 프론트 서버 -> 브라우저

⚡️ 장점

1) 페이지 로딩이 빠르다.

2) CSR과 달리 모든 컨텐츠가 HTML에 담겨있기 때문에 효율적인 SEO가 가능하다.

즉, 앞서 CSR의 단점인 느린 페이지 로딩과 좋지 않은 SEO 성능을 해결한 것이다.

⚡️ 단점

1) Blinking Issue

: 사용자가 새로고침을 하게 되면 전체 웹사이트를 다시 서버에서 받아와야 하기 때문에 화면이 없어졌다가 나타나는 현상

2) 서버 과부하

: 사용자가 많은 제품일수록 서버에 데이터를 요청하는 횟수가 많아지고,
그때마다 서버에 매번 요청을 하기 때문에 서버의 부담이 커진다.

3) TTV와 TVI의 공백시간

SSR 방식에서는 서버에서 만들어진 HTML 파일을 가져오게 되고 사용자는 바로 웹 사이트를 볼 수 있다.
하지만 웹 사이트를 동적으로 제어할 수 있는 자바스크립트 파일은 아직 받아오지 않았기 때문에
사용자가 클릭을 해도 아무런 것도 처리할 수가 없는 상태가 된다.
최종적으로 자바스크립트 파일을 받아와야 사용자가 원하는 것을 처리할 수 있는 인터랙션이 가능해진다.

그래서 SSR은 사용자가 사이트를 볼 수 있는 시간(TTV)과
실제로 인터랙션이 가능한 시간(TTI)의 공백시간이 꽤 길다는 단점이 존재한다.

반대로 CSR은 HTML만 받아왔을 때는 아무것도 보여지지 않고
링크되어 있는 모든 로직을 처리하는 자바스크립트 파일을 받아오게 되면
웹 사이트가 보여지는 동시에 인터랙션이 가능해진다. 즉 TTV와 TTI의 공백시간이 없는 것이다.

💡 TTV

Time To View : 사용자가 웹브라우저에서 내용을 볼 수 있는 시점

💡 TTI

Time To Interact : 사용자가 웹브라우저에서 인터랙션 할 수 있는 시점

📡 요약

우리가 웹브라우저에 접속하면 보이는 화면은 HTML이다.
이때, 이를 구현하는 것이 서버단에서 이루어진다면 SSR 방식이고,
브라우저에서 이루어진다면 CSR 방식인 것이다.

만약, 모든 검색엔진의 SEO가 중요하고, 웹사이트의 빠른 초기 로딩이 필요하며,
웹사이트 콘텐츠가 많은 상호작용이 필요하지 않다면 SSR 방식을 사용하는 것이 효율적일 것이다.

반면 SEO가 최우선이 아니고, 웹사이트의 콘텐츠가 많은 상호작용을 필요로 하며,
웹 애플리케이션을 구축했다면 CSR 방식을 사용하는 것이 좋을 것이다.

🛹 결론

CSR을 잘 사용하기 위해서는 최종적으로 번들링 해서 사용자에게 보내주는 자바스크립트 파일을
어떻게 하면 효율적으로 많이 분할해서 첫 번째로 사용자가 사이트를 보기 위해서 필요한
필수적인 요소들만 보낼 수 있을지 고민해봐야 한다.

SSR 같은 경우는 TTV와 TTI의 공백시간을 줄이기 위해서 어떤 노력을 할 수 있을지와
어떻게 조금 더 매끄러운 UI와 UX를 제공할 수 있을지를 고민해보면 좋을 것이다.

❗️ 요즘에는 SSG(Static Site Generation)라는 방식도 존재