CSR SSR 단점 보완 방법 정리해보기

 

지난 시간에 CSR, SSR의 개념과 장단점에 대해서 정리해 보았는데, 그렇다면 이 둘의 단점을 개선하기 위한 방법에는 어떤 것들이 있는지 정리해보려고 한다.

 

CSR 단점 보완 방법

먼저 CSR은 초기 로딩 속도가 느리다는 점과 SEO가 불리하다는 점이 단점이다. 
이것을 개선하기 위해서는 다음과 같은 방법들을 이용하여 개선할 수 있다.

 

1. Code Splitting, Tree-Shaking 

이 방법들의 초기 로딩에 필요한 javaScript의 크기를 줄여주어서 로딩 속도를 개선할 수 있도록 만들어준다.
Code Splitting은 말 그대로 코드를 쪼갠다는 의미이며, Tree-Shaking은 나무를 흔들어 죽은 나무잎을 떨어트리는 것처럼 사용되지 않는 코드를 제거하기 위해 사용되는 용어이다. 

https://crystallize.com/comics/no-code-splitting-vs-code-splitting

CSR의 초기 속도가 느린 것은 페이지 로딩 시 app에서 필요한 로직 + app 구동에 필요한 프레임워크와 라이브러리 등을 한 번에 서버에서부터 다운로드하기 때문인데, 코드를 쪼개거나, 불 필요한 코드를 제거하여 파일의 크기를 줄여주면 해당 페이지에 방문 시 그에 관련된 모듈들만 로딩될 수 있어서 로딩 속도를 개선할 수 있다.

 

2. Pre-rendering

라이브러리나 웹팩플러그인을 통해 각 페이지에 대한 HTML 파일을 미리 생성해둔 뒤 사용자에게 정적인 HTML 파일을 먼저 보여주는 방식이다. TTI와 TTV가 달라서 단점이 되기도 하지만, 로딩 속도가 빨라지고 검색 최적화(SEO)가 잘 되지 않는다는 단점을 보완할 수 있는 방식이다.

 

3. SSR, SSG 도입

SPA는 주로 페이지 렌더링이 빠른 CSR을 사용하여 만들어지는데, 여기에 SSR이나 SSG를 함께 적용시키면 CSR의 단점을 상당 부분 보완 할 수 있다.

SSG (Static Stie Generation)란 개발자가 개발을 완료하고 build하는 순간에 렌더링이 일어나는 방식을 말한다. 미리 서버에 화면을 저장해 두고 꺼내서 사용하는 방식으로 컨텐츠가 변화할 가능성이 없는 정적인 서비스에 적합하다.

 

CSR + SSR / SSG 자세히 알아보기

프레임워크나 라이브러리 없이 하는 방법과 프레임워크, 라이브러리와 함께 사용할 수 있는 방법이 있는데, 전자의 경우는 서버구축에 익숙하지 않은 프론트엔드 개발자에게 어려움이 많아서 보통 후자의 방법을 많이 선택한다. 프레임워크와 함께 사용할 수 있는 방법들은 다음과 같다.

1. Next.js

Next.js는 CSR에 특화된 React에서 SSG나 SSR을 적용할 수 있도록 만들어준다. 페이지 단위로 SSR과 SSG를 선택할 수 있어서 상황에 맞게 적용하여 우리의 앱을 조금 더 강력하고 유연하게 목적에 맞게 사용할 수 있도록 도와준다.
자동 코드 분할이나  SSG 캐싱을 이용하여 로딩 속도를 줄여주고, 첫 페이지를 SSG를 통해 미리 생성해 두어 SEO 문제도 해결할 수 있다. CSR의 장점인 반응속도가 빠르다는 점과 서버 부담이 적다는 점은 그대로 가지고 있으면서, SSR, SSG의 장점도 함께 사용할 수 있다.

이렇게 양 측의 장점을 모아둔 앱이나 방식을 Isomorphic App 또는 Universal Redering이라고 한다.
특히 React에서의 Isomorphic App이란  서버와 클라이언트 측 모두에서 실행할 수 있는 코드로 구성된 웹 앱을 의미하며, 일반적으로 서버의 성능과 SEO 친화성을 최대한 활용하여 복잡한 사용자 상호 작용을 처리해 준다.

(자세한 내용은 아래 더보기 클릭)

https://www.upbeatcode.com/react/what-is-isomorphic-react-app/

What Is Isomorphic React App

 

 

 

2. Gatsby

React는 CSR에 특화된 라이브러리지만, gatsby와 함꼐 사용 시 React로 만든 웹 어플리케이션을 정적으로 미리 HTML로 만들어 서버에 배포해 둘 수 있다. 따라서 CSR + SSG의 형태라고 볼 수 있다. 하지만 이렇게 만들어진 사이트들이 모두 정적인 것은 아니다. 서버에서 추가 데이터를 받아오거나 동적으로 처리해야 할 로직이 있다면 javaScript파일을 함께 가지고 와서 동적인 요소도 추가할 수 있다.

그렇지만 이는 미리 페이지를 만들어두는 형태이므로 주로 컨텐츠가 변화될 가능성이 적은 경우에 사용이 적합하며, 보통 기업 소개 페이지, 블로그 등에 많이 사용된다.

(자세한 내용 더보기 클릭)

https://mnxmnz.github.io/gatsby/what-is-gatsby/

Gatsby는 처음이라 :: 개념부터 프로젝트 시작까지

https://blog.banksalad.com/tech/build-a-website-with-gatsby/

React밖에 모르는 당신에게. GatsbyJS한 잔, '채용~' | 뱅크샐러드

 

 

 

결론

 

이렇게 다양한 방법들이 존재하는데 도대체 어떤 방법을 사용해야 가장 좋은 서비스를 제공할 수 있을까?

정답은 "서비스에 따라 다르게 적용된다." 이다.

- 사용자와의 상호작용이 많고, 대부분이 개인정보로 이루어진 경우, 검색창에 노출되는 것보다 정보를 보호하는 것이 더 중요해서 SEO가 필요하지 않은 경우 👉 CSR 선택

- 회사 홈페이지 같은 정적페이지에 상호작용이 많지 않아서 누구나 같은 페이지를 보는 경우인데 매주 업데이트가 필요한 경우에는 👉 SSR 선택

- 위와 같이 정적 페이지로 주로 구성되어있지만 업데이트를 거의 하지 않는 경우에는 👉 SSG 선택

- 마지막으로 사용자와 상호작용이 많아서 사람마다 페이지의 내용이 달라져야 하고, 빠른 인터랙션과 함께 화면 깜빡임도 없으면서 상위 노출이 필요한 경우에는 👉 CSR + SSR 선택

즉, 각각의 방법이 모두 다른 특성을 가지고 있기 때문에 내가 사용할 페이지가 어떤 점이 필요한지를 파악하여 방법을 선택하면 된다.

 

참고자료

• 드림코딩 - 서버사이드 렌더링 (개발자라면 상식으로 알고 있어야 하는 개념 정리)
• 신세한탄의 CSR&SSR
• 코트팩토리 CSR vs SSR
• 웹 성능 최적화를 위한 Tree Shaking 소개
• Next.js와 Pre-rendering
• React에서 해보는 코드 스플리팅