CSR 과 SSR 알아보기! 부제 : 브라우저 렌더링은 서로 다르게 일어나는가?

오늘은 CSR과 SSR 에 대해서 개인적으로 정리한 내용을 공유하고자 한다.

궁금증을 해결하기 위해서 공부한 내용이라, 기존 나의 지식과 새로 생긴 궁금증을 바탕으로 알아가는 흐름으로 글을 진행하려고 한다.

지금까지 나는 CSR과 SSR에 대해서 정말 간략하게 클라이언트에서 페이지를 렌더링한다, 서버에서 페이지를 렌더링한다 정도로만 알고있었다.
렌더링이라는 용어 때문에 SSR 에서는 '브라우저 렌더링 과정이 일어나지 않는 것인가?!' 라는 궁금증이 생기기도 해서 조금 더 정확하게 알고싶어서 공부하고, 발표까지 하게 되었다.

✅지금까지 알고있는 것

• CSR 은 서버에서 주는 데이터를 바탕으로 클라이언트에서 페이지를 렌더링 하는 것.
• SSR 은 서버에서 렌더링을 마친 페이지를 클라이언트에서 보여주는 것.
• SPA 는 싱글페이지 애플리케이션으로 모든 데이터를 클라이언트에서 받아 라우팅까지 하는 것.
• CSR 은 html 안에 빈 코드밖에 없기 때문에 SEO에 불리하다.

🤔나의 궁금증…

1. 브라우저 렌더링 과정과 CSR, SSR 의 렌더링은 다른 것인지? 다르다면 어떤 차이가 있는지?
2. 서버에서 렌더링을 한다는 것의 의미가 무엇인가?
3. SSR, CSR 을 어떻게 적절히 사용할 수 있는가?

😸먼저 살펴볼 것: CSR 과 SSR이 뭘까?

CSR : Client Side Rendering

출처: https://medium.com/walmartglobaltech/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8

전체 페이지에 대한 데이터를 한 번에 받아온 다음에, 자바스크립트 코드를 파싱해 DOM을 동적으로 생성해주는 렌더링 방식이다. 
서버에서는 HTML 생성에 대한 부담이 적고, 필요한 연산과 라우팅을 클라이언트가 처리하기 때문에 반응 속도가 빠르고 따라서 우수한 UX를 제공할 수 있다는 장점이 있다.

1. DOM 을 동적으로 생성한다.

빈 HTML 파일과 자바스크립트 코드를 다운받아서, 리액트를 통해 DOM 을 동적으로 생성한다.

모든 페이지 렌더링이 완료되면 화면과 기능(Interaction) 이 한 번에 로딩이 되므로 TTI 와 TTV 가 동일하다는 점이 특징이다. (TTI : Time to Interact / TTV : Time to View)

 

즉 페이지가 로딩이 되면, 사용자가 버튼을 클릭했을 때 그에 해당하는 기능까지 이미 사용할 수 있는 상태가 되는 것!

 

단, 자바스크립트를 가지고 동적으로 DOM을 만드는 것이기 때문에, 이 과정이 끝나기 전까지 사용자는 아무것도 볼 수가 없다. 처음 페이지를 볼 수 있는 시간은 SSR 보다 느릴 수밖에 없다.

2. 클라이언트에서 연산과 라우팅을 담당한다.

CSR 방식의 SPA 의 경우 하나의 HTML 을 가지고 여러 페이지를 라우팅 하는데, 동적으로 변하는 부분만 렌더링을 하면 되기 때문에 화면 깜빡임 없이 부드럽고 빠른 UX 를 제공할 수 있다.

 

또 중간에 필요한 부분만 서버에 AJAX 요청을 통해 동적으로 호출할 수 있고, 통신이 필요한 경우에만 발생하기 때문에 SSR에 비해 속도가 더 빠르게 느껴진다.

 

서버 입장에서는 HTML을 만들어서 보낼 필요가 없기 때문에 부담이 적다는 장점이 있다.

3. HTML은 비어 있는 상태이기 때문에, SEO 에 불리하다.

검색엔진의 크롤러는 HTML 을 바탕으로 정보를 수집하기 때문에, 빈 HTML 을 받는 CSR 방식의 페이지는 SEO 에 불리할 수밖에 없다.

SSR : Server Side Rendering

출처: https://medium.com/walmartglobaltech/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8

요청 페이지에 대한 “Ready to Render” HTML 파일과 자바스크립트 파일을 받아서, JS 가 파싱되는 동안 HTML 페이지 먼저 보여주는 렌더링 방식이다. 

1. 렌더링이 될 준비를 마친 HTML 파일을 받는다.

렌더링이라는 용어 때문에 (제가…) 오해를 한 것 같은데, 브라우저의 렌더링 과정은 CSR 이나 SSR이나 동일하다. 둘의 차이는 “받는 파일” 에 있다!

서버에서 클라이언트로부터 특정 페이지에 대한 요청을 받게 되면, 서버에서 이미 필요한 내용이 모두 담겨있는 HTML 파일을 받게 된다. 클라이언트는 자바스크립트로부터 Interaction 에 해당하는 내용만을 HTML 에 연결해주면 된다.

💡궁금증 해결 1.
: 브라우저 렌더링 과정과 CSR, SSR 의 렌더링 다른 것인지?

Server Side Rendering 서버 사이드 렌더링 이라고 해서, 브라우저 렌더링을 서버에서 해준다는 의미는 아니다.

SSR 과 CSR의 차이는 빈 페이지에서 자바스크립트를 가지고 동적으로 UI를 생성하느냐, 아니면 이미 UI는 완성이 되어 있고 기능만 연결해주면 되느냐의 차이!

💡궁금증 해결 2.
: 서버에서 렌더링을 한다는 것의 의미가 무엇인가?

각 요청에 해당하는 페이지 HTML 을 만들어서 보내주는 렌더링 방식이다. 이미 만들어진 HTML을 브라우저가 빠르게 렌더링 할 수 있다는 장점이 있지만, 인터렉션이 되기 까지의 간극이 있다는 것이 단점이다. 매 요청마다 필요한 HTML을 서버에서 전달받기 때문에, SEO 에 유리하면서 깜빡거림이 있어서 사용감이 좋은 편은 아니다. 

2. TTI 와 TTV의 간극

사용자는 화면이 있기 때문에 이것 저것 클릭해보지만, 자바스크립트 파싱이 완료될 때 까지 어떠한 상호작용도 할 수 없다! 이를 Time to view 와 Time to Interact 사이에 간격이 있다고 표현한다. 화면을 빠르게 볼 수 있다는 장점은 있지만, 아무것도 할 수 없다는 단점이 공존한다.

3. SEO 에 유리하지만 깜빡거린다.

페이지별로 서버에서 그때 그때 필요한 HTML을 만들어 보내주기 때문에, 크롤러가 데이터를 수집하기에 좋다! 그래서 SEO에 유리하다.

단점은…

1. 서버에서 매 요청마다 필요한 HTML을 만들어서 보내주기 때문에, 서버에 부담이 된다.
2. 매 요청시 새로운 HTML 페이지를 보여주는 것이기 때문에, 깜빡 깜빡 거리는 현상이 있다.

😸CSR vs SSR?

❓각자의 장단점이 있다면, 도대체 어떤 방식을 써야하는 것일까?

SEO와 최초 로딩 속도가 중요한 서비스일 경우, SSR 방식을 사용하자.

상호작용이 별로 없는 페이지에서 콘텐츠 소비 속도가 빠른 서비스의 경우 SSR 방식을 도입해 페이지를 빠르게 보여줄 수 있도록 할 수 있다.

 

참고글 : 네이버 블로그 SSR 도입

(네이버 블로그 모바일 서비스는 블로그 콘텐츠를 빠르게 소비할 수 있도록 CSR 에서 SSR로 변경하였다고 한다.)

 

매끄러운 사용자 경험과 상호작용이 중요할 때는 CSR 방식을 사용하자.

SEO 는 별로 중요하지 않은데, 매끄러운 사용자 경험과 상호작용이 중요할 때. 처음 보내줘야 할 데이터의 양이 그리 많지 않은 경우 CSR 방식을 사용할 수 있다.

 

CSR과 SSR을 둘 다 사용해야한다면?

CSR의 단점을 보완해보자.

1. 초기 렌더링 속도를 보완하자.
   코드 스플리팅 : path 별로 필요한 코드를 분리하여 번들링한다. path 가 변경될 때마다(다른 페이지로 넘어갈 때마다) 필요한 데이터를 보내줄 수 있기 때문에, 초기에 서버로부터 받아오는 데이터의 크기를 줄일 수 있다.
2. pre-rendering 을 사용하자. 
   빌드 시에 특정 페이지에 대한 html을 미리 만들어두는 것. 따로 SSR 을 적용하지 않고 SEO를 할 수 있고, 미리 만들어진 HTML이 있기 때문에 사용자가 기다릴 필요가 없다는 장점이 있다. 별도의 라이브러리를 활용한다.

CSR + SSR = Universal Rendering

이 방법은 SSR을 위한 별도의 서버 구축이 필요하다. express 를 사용하거나, 아니면 각 라이브러리(리액트, 앵귤러, 뷰 ...) 별로 SSR 을 지원하는 프레임워크를 사용하는 방법이 있다.

React 에서는 Next.js 와 Gatsby 가 가장 유명하다. 

 

아래 두 프레임워크에 대해서 간략하게 정리해보았다.

 

[Next.js]

• 서비스에서 페이지의 성격별로 SSR 혹은 CSR 을 선택해서 렌더링 할 수 있다.
• pre-rendering 기능이 있어서 CSR 페이지여도 어느정도 HTML이 구성된 상태로 서버로부터 넘어온다.

[Gatsby]

• 페이지의 내용이 자주 바뀌지 않는 SSG (정적 사이트 방식) 에 적합하다.
• 빌드 시점에 정적 페이지를 만들어주는 프레임워크라서, 서비스 규모가 작고 페이지 갯수가 그렇게 많지 않은 경우 적합!

💡궁금증 해결 3.
: SSR, CSR 을 어떻게 적절히 사용할 수 있는가?

SEO가 중요하다면 ~ SSR
상호작용이 중요하다면 ~ CSR

둘 다 중요하다면? SSR을 위한 서버를 구축하거나 Next.js 같은 프레임워크를 사용해보자!

💡Summary

지금까지 프론트엔드 개발자 필수 지식인 CSR 과 SSR에 대해서 간략하게 알아보았다. CSR과 SSR 이 중요한 이유는 검색엔진에 노출여부를 결정하는 SEO와 직접적인 연관이 있기 때문이다.

 

SSR의 경우 서버에서 HTML 을 만들어서 주기 때문에, HTML에 담겨있는 정보를 토대로 SEO 에 유리하지만 CSR은 빈 페이지에서 자바스크립트로 DOM을 동적으로 생성하기 때문에 SEO에는 불리하다는게 CSR, SSR의 핵심이다.

 

또한 서버 사이드 렌더링이라고 해서 브라우저 렌더링이 일어나지 않는 것은 아니라는 점... 렌더링이라는 용어때문에 헷갈릴 수 있지만, 서버로부터 전달되는 HTML 의 내용과 전체 UI를 동적으로 생성하는지 여부의 차이일 뿐이라는 점을 기억해야 할 것 같다. 페이지의 컨텐츠를 빨리 보여주느냐, 만들고나서 보여주느냐의 차이라고 볼 수도 있다. 

 

+) 

사실 실제 서비스를 운영해본 경험이 없는지라 SEO, CSR, SSR 에 대해서 크게 와닿지 않았었던 것 같다. 현업에서는 내가 예상하는 것보다 더 넓은 범위에서 다양한 문제를 다룬다는 것을 간접적으로나마 알게되었고, 앞으로는 이런 부분까지 잘 알고 활용할 줄 아는 개발자가 되고싶다!

 

👀참고자료

[ 기술 스터디 ] SSR과 CSR의 차이

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

SSR(서버사이드 렌더링)과 CSR(클라이언트 사이드 렌더링)

CSR 앱에서 SSR + CSR 환경으로 이주하기