[SSR vs CSR] SSR(Server Side Rendering)

회사에서 타임리프를 쓰고 있지만, 레거시 소스코드에는 핸들바라는 CSR도 함께 사용되고 있다.

처음 Ajax에 대해 배우면서 CSR에 대해 알게 되면서, 화면의 깜빡임 없이 새로운 정보를 클라이언트에게 제공할 수 있다는게 무조건적으로 장점이라고 생각했던 시절이 있었다.

Thymeleaf와 Handlebar를 함께 써보고, React 공부를 하면서 배우고 느낀 SSR과 CSR에 대해 정리해보고자 한다.

먼저 SSR!

SSR이란?

SSR은 서버의 HTML파일을 클라이언트를 위해 요청받은 정보에 대한 응답으로 완전히 렌더링된. 즉, 클라이언트에게 보여줄 data가 그려진 형태의 페이지를 전송해준다. 서버쪽에서는 클라이언트에게 콘텐츠를 전송하기 전에 전달할 data를 indexing 하는 것 과 같이 미리 가공을 할 수 있기 때문에 검색엔진 최적화를 해야하는 경우 SSR이 유용하다고 한다.

렌더링 단계

1. 사용자가 웹사이트로 요청
2. 서버에서 페이지 내에 있는 서버측 Script를 확인하여 필요한 resource를 이용하여 compile을 마치고 HTML을 완성한다.
3. 컴파일된 HTML가 클라이언트의 브라우저로 전송되고, 추가적인 렌더링 진행 뒤 display된다.
4. 브라우저가 HTML를 다운로드하여 User가 사이트를 볼 수 있게 한다.
5. 그런 다음 브라우저는 JS를 다운로드 받고 실행함으로서 페이지를 Interactive하게 만든다.

SSR의 이점!

• SSR Application은 페이지를 더 빨리 로드하여 사용자 경험을 개선시킬 수 있다.
• SSR를 사용하면 검색엔진은 페이지가 로드되기 전에 렌더링이 끝나기 때문에, 콘텐츠 Indexing & Searching이 쉬워져서 SEO에 이상적인 기능이다. 특히, SNS에서 링크를 공유했을 때 해당 웹사이트의 정보를 이미지와 설명으로 표시해주는 Open Graph Tag를 페이지 별로 적용할 때 SSR이 효율적으로 사용될 수 있다고 한다.
  
  • ❓ SEO(검색엔진 최적화) 웹사이트가 유기적인(무료) 검색 방식을 통해 검색 엔진에서 상위에 노출될 수 있도록 최적화하는 과정. 비즈니스 유형이 어떤 것이든 SEO는 가장 중요한 마케팅 유형 중 하나이다.

• 웹브라우저가 로딩 시간이 빠른 웹 페이지의 우선순위를 정하기 때문에 웹페이지 Indexing이 적절하고 정확해진다.
• SSR은 인터넷 연결이 느리거나 저사양 기기 사용자의 웹페이지를 효율적으로 로드하는데 도움이 된다.

SSR의 단점

• SSR은 JavaScript 웹사이트의 기본값이 아니다. 서버측에서 해야할 일이 CSR에 비해 많기 때문에 자원과 비용이 많이 소모될 수 있다.
• 정적 HTML을 렌더링할 때는 효율적이지만, 더 크고 복잡한 Application을 렌더링하는 경우 동적 렌더링이 불가능하고 요청이 갑자기 늘어나는 경우 렌더링시간이 증가될 수 있게된다. 빈번한 클라이언트의 요청 또는 전체 페이지 re-loading이 발생한다면 전반적인 페이지 렌더링이 느려진다.

---

Reference

1. https://www.heavy.ai/technical-glossary/server-side-rendering
2. https://ko.wix.com/blog/post/what-is-seo?utm_source=google&utm_medium=cpc&utm_campaign=14051298432^124501874839&experiment_id=^^535938152124^^_DSA&gclid=CjwKCAjwgr6TBhAGEiwA3aVuIS3wXp2x-WQ0R9YDRZfkggIfZLXwf3FrpB6DWI0JqLxzQmb7Rp5EahoCTC4QAvD_BwE
3. https://joshua1988.github.io/vue-camp/nuxt/ssr.html#서버-사이드-렌더링의-단점