CSR(Client Side Rendering) vs SSR(Server Side Rendering)

🤔CSR이 뭔가요?

CSR이란 Client Side Rendering의 약자로 클라이언트 측에서 렌더링하는 방식이다.

🤔SSR이 뭔가요?

SSR이란 Server Side Rendering의 약자로 서버측에서 렌더링하는 방식이다.

🤔그래서?

렌더링은 결국 화면에 그려지는 것은 HTML, CSS인데 말 그대로 그리는 주체가 클라이언트냐 서버냐에 따라서 나뉘는 개념이라고 할 수 있다.

일반적으로 SPA(Single Page Application)은 CSR을, MPA(Multiple Page Application)은 SSR을 채택한다.

🤔일반적으로 SPA가 CSR을 채택하는 이유가 뭔가요?

SPA는 웹 애플리케이션을 필요한 정적 리소스를 초반 한 번에 모드 다운로드 하고 그 이후 새로운페이지 요청이 있을 때 페이지 갱신에 필요한 데이터만 전달받아서 클라이언트에서 페이지를 갱신하기 때문에 자연스럽게 렌더링 방식으로 CSR을 사용한다.

리액트, 뷰, 앵귤러를 사용해서 SPA를 만들고 특별한 목적을 가지고 렌더링 방식을 변경 하지 않는다면 자연스럽게 CSR을 사용하게 되는 것이다.

🤔일반적으로 MPA가 SSR을 채택하는 이유는 뭔가요?

MPA는 새로운 요청이 있을 때마다 서버에서 이미 렌더링된 정적 리소스를 받아오기 때문에 렌더링 방식으로 SSR을 사용한다.

PHP나 JSP로 MPA를 만들면 자연스럽게 SSR 사용하게 된다.

SPA는 CSR, MPA는 SSR이라는 오해가 생겨나기도 했지만 이 두 개념은 페이지가 몇 개냐, 렌더링을 어디서 하냐에 따라 달라지는 다른 개념이다.

🤔CSR의 동작 과정은 어떻게 되나요?

1. 유저가 웹사이트에 방문하면 브라우저가 서버에 콘텐츠를 요청하고 서버는 빈 뼈대만 있는 HTML을 응답으로 보내준다.
2. 브라우저가 연결된 JS 링크를 통해 서버로부터 다시 JS 파일을 다운로드 받는다. 그 사이에 사용자는 웹페이지에서 아무것도 볼 수 없다.
3. 다운로드가 완료된 JS 파일을 이용해 동적으로 페이지 만들어서 브라우저에 띄워준다.

🤔CSR의 특징에 대해 말해주세요.

1. 초기 로딩 속도는 느리지만 이후의 구동 속도는 빠르다.
   CSR은 브라우저가 JS 파일을 다운로드 받고 동적으로 DOM을 생성하는 시간을 기다려야 하기 때문에 초기로딩 속도가 느리다.
   하지만 초기로딩 이후에 페이지 일부를 변경할때는 서버에 해당 데이터만 요청하면 되기 때문에 이후 구동 구동 속도는 빠르다.
   

2. 서버측 부하가 적다.
   서버가 빈 뼈대만 있는 HTML을 넘겨주는 역할만 수행하면 되기 때문에 서버측에 부하가 적다.

3. 반응 속도가 빠르다.
   클라이언트 측에서 연산, 라우팅 등을 모두 직접 처리 하기 때문에 반응 속도가 빠르고 UX도 우수하다.

4. SEO에 불리하다.
   브라우저들이 가지는 웹 크롤러는 HTML을 읽어서 검색 가능한 색인을 만들어낸다. 웹 크롤러 봇 입장에서 본 HTML은 텅텅 비어 있다. 검색엔진이 색인을 할 만한 콘텐츠가 존재하지 않는다는 것 이다. 이 때문에 CSR은 검색엔진 최적화에 불리하다.
   구글의 크롤러 봇은 CSR 웹 크롤링도 가능하지만 구글 측에서도 여전히 크롤러 봇이 JS를 실행하기전에 더욱 빠르게 크롤링을 할 수 있도록, 또 자바스크립트를 실행할 수 없는 다른 크롤러 봇들을 위해서 SSR을 고려해 보라는 말을 덧붙이고 있다.

5. TTV(Time To View)와 TTI(Time To Interaction)가 동일하다.
   CSR은 JS가 동적으로 DOM을 생성하기 때문에 HTML은 JS 로직이 모두 완전히 연결된 상태라 사용자가 보는 시점과 이용할 수 있는 시점이 동일하다.
   

🤔SSR의 동작 과정에 대해 설명해주세요.

1. 유저가 웹사이트에 방문하면 브라우저에서 서버로 콘텐츠를 요청한다.

2. 서버에서는 즉시 페이지에 필요한 데이터를 얻어와 모두 삽입하고 css 까지 모두 적용해서 렌더링 준비를 마친 HTML과 JS코드를 브라우저에 응답으로 전달한다.

3. 브라우저에서는 바로 전달 받은 페이지를 띄운다. 페이지는 보이지만 JS가 읽히기 전이라 상호작용은 불가능하다. (이 때 사용자의 조작은 기억된다.)

4. 이어, 브라우저가 JS 코드를 다운로드하고 HTML에 JS 로직을 연결한다.

5. 이제 사용자는 웹페이지와 상호작용이 가능하다. (기억되었던 사용자의 조작들도 실행된다.)

🤔SSR의 특징에 대해 말해주세요.

1. SEO에 유리하다.
   모든 데이터가 이미 HTML에 담겨진채로 브라우저에 전달되기 때문에 검색엔진 최적화에 유리하다. JS를 실행 할 줄 모르는 크롤러 봇도 무리없이 HTML을 읽을 수 있기 때문이다.

2. 초기 구동 속도가 빠르다.
   JS 다운로드를 기다려야했던 CSR보다 초기구동 속도가 빠름.

3. TTV(Time To View)와 TTI(Time To Interaction)간에 시간 간격이 존재한다.
   자바스크립트 코드를 다운로드 받고 실행하기 전에 사용자가 화면을 볼 수 있지만 이 시점에는 사용자가 버튼을 클릭 하거나 이동하려고 아무런 반응이 없을 수 있다.
   인터랙션 가능한 페이지처럼 보이지만 그저 내용과 스타일이 입혀진 껍데기에 불과하고, 실제로 클라이언트 측 JS 가 실행되고 이벤트 핸들러 첨부되어서 JS 로직이 모두 연결될때까지 사용자 입력에 응답 할 수 없기 때문이다.

🤔CSR과 SSR의 각각 장단점은 무엇인가요?

우선 CSR의 장점에는 화면깜빡임이 없다, 초기로딩 이후 구동 속도가 빠르다, TTV, TTI 사이 간극이 없다, 즉 전체적으로 매끄러운 사용자 경험(UX)이 특징이고 서버에 부하가 클라이언트로 분산 된다는 점도 장점이다.

단점에는 초기 로딩속도가 느리고 SEO에 불리하다는 점이 있다.

SSR의 장점은 초기 구동 속도가 빠르고 SEO에 유리하다는 점이 있고, 단점으로는 화면 깜빡임이 있고 TTV와 TTI 사이 간극이 있어 사용자 경험이 나쁘다, 매 페이지 로딩시마다 서버에 요청하므로 서버에 부하가 있다는 점이 있다.

🤔CSR의 단점을 보완할 수 있는 방법이 있나요?

1. code splitting, tree-shaking, chunk 분리를 통해 JS 번들 크기를 줄여서 초기 DOM 생성 속도를 줄이면 초기 로딩속도를 개선할 수 있다.

2. pre-rendering을 통해 SEO를 개선할 수도 있는데, 라이브러리나 웹팩 플러그인을 통해 각 페이지에 대한 HTML 파일을 미리 생성 해둔 뒤 서버에서 요청하는 자가 만약 크롤러라면 사전에 렌더링 된 HTML 버전 페이지를 보여 주는 방식을 통해 개선할 수 있다.

3. CSR을 사용하고 있는 SPA에 SSR이나 SSG를 도입하는 것도 방법인데, 실제로 CSR의 단점을 상당 부분 보완할 수 있다.

🤔SSG는 뭔가요?

SSG는 Static Site Generation의 약자로 Static Rendering 이라고도 불리는 방식이다.

🤔SSR과 SSG의 차이는 뭔가요?

서버에서 HTML을 보내준다는 측면에서는 SSR과 비슷하지만 언제 만들어 주느냐에 차이가 있다.

SSR은 요청 시 서버에서 즉시 HTML을 만들어서 응답하기 때문에 데이터가 달라지거나 자주 바뀌어서 미리 만들어 두기 어려운 페이지에 적합하고, SSG는 페이지들을 서버에 모두 만들어둔 뒤에 요청시에 해당 페이지를 응답하는 것이기 때문에 바뀔 일이 거의 없어서 캐싱 해두면 좋은 페이지에 사용하면 적합하다.

🤔CSR에 SSR/SSG를 어떻게 도입할 수 있나요?

1. 프레임워크없이 도입하는 방법
   우선 프론트엔드 개발자에게 상대적으로 친숙한 Express.js로 별도의 서버를 직접 운영하는 방법이 있다.
   타입 스크립트 설정이 걱정 된다면 기본적으로 타입스크립트를 지원하는 NestJS를 사용할 수도 있다.
   하지만 이 방법들은 서버 환경 구성이나 빌드 등의 작업이 생소한 프론트엔드 개발자에게는 복잡하고 헷갈리는 부분이 많아서 다소 진입장벽이 있다.

2. SPA 에서 보다 쉽게 SSR나 SSG를 적용할 수 있도록 해주는 프레임워크를 사용
   1. Next.js
   Next.js는 리액트에서 SSR이나 SSG를 사용할 수 있게 해주는 프레임워크로, 페이지의 성격 별로 SSR을 사용할 것인지 SSG를 사용할 것인지 미리 정해 주는 것도 가능하다.
   2. GatsbyJS
   GatsbyJS는 SSG에 최적화된 리액트 기반 정적 페이지 생성 프레임워크로 SSG에 최적화되어 있긴 하지만 CSR, SSR, 레이지 로딩 등도 지원하고 무엇보다 굉장히 다양한 플러그인들을 제공하는 것이 장점이다.
   빌드 시점에 스태틱 HTML들을 만들어 주는 것이기 때문에 페이지가 적고, 작은 서비스라면 확실히 좋은 수단이 될 수 있다.
   3. Nuxt.js
   Nuxt.js는 뷰를 위한 프레임워크 인데, Next.js에 영감을 받아서 만들어졌다.
   4. 앵귤러 유니버셜
   앵귤러 유니버셜은 앵귤러에서 SSR을 가능하게 해주는데 원래 프레임워크로 시작했지만 앵귤러4부터는 앵귤러 자체에 포함 되었다. 엄밀히 말하면 더 이상 프레임워크는 아니다.
   

🤔CSR에 프레임워크를 써서 SSR/SSG를 도입했을때의 단점은 없나요?

프레임워크들이 CSR에 SSR이나 SSG 도입을 훨씬 편하게 만들어 주는 것은 사실이지만 프레임워크를 사용하더라도 일반 SPA. 즉 CSR 개발에 비해 코드 복잡도는 올라간다.

또 프레임워크를 사용하면 당연히 감수해야할 부분이긴 하지만 직접 제어할 수 없는 영역도 존재한다.

🤔Isomorphic App 혹은 Universal Rendering에 대해 아시나요?

초기 렌더링 방식으로 SSR을 사용하고 그 이후에는 CSR을 사용하는 앱이나 그 렌더링 방식을 뜻하는 용어이다.

Isomorphic App은 서버와 클라이언트에서 동일한 코드가 동작하는 어플리케이션 이라는 의미로 해석할 수 있다.

클라이언트와 서버가 모두 같은 코드로 돌아가기 때문에 예상과는 다른 결과를 마주할 가능성도 있지만, 초기 로딩속도와 SEO를 해결하면서도 CSR의 장점을 그대로 가져갈 수 있는 좋은 대안이 되기 때문에 최근 많이 사용되고 있는 추세이다.

🤔CSR? SSR? SSG? 도대체 어떤 방식을 쓰면 좋을까요?

서비스 성격에 따라 달라진다.

1. 사용자와의 상호작용이 많고 대부분 페이지가 고객의 개인정보 데이터를 기준으로 구성되는 서비스의 경우 검색포털 상위 노출 되는 것보다 오히려 고객의 데이터를 보호하는 것이 더 중요한 경우 ⇒ CSR

2. 홈페이지가 상위노출 되어야하고 누구에게나 동일한 내용을 노출 하고 있다면, 그리고 만약 그 페이지 데이터가 자주 바뀌는 경우 ⇒ SSR

3. 홈페이지가 상위노출 되어야하고 누구에게나 동일한 내용을 노출 하고 있다면, 하지만 내용을 업데이트 하는 일이 거의 없는 경우 ⇒ SSG

4. 사용자에 따라 페이지 내용도 달라지고 빠른 인터랙션도 중요하고 검색엔진 최적화도 포기할 수 없는 경우 ⇒ CSR + SSR 즉, Universal Rendering

참고

[10분 테코톡] 🎨 신세한탄의 CSR&SSR