1. CSR? SSR? 렌더링이 뭔지부터 알려줘요

CSR과 SSR이 무엇인지 비교하기 전에 우선 렌더링이 무엇인지부터 자세히 살펴보자.

렌더링(rendering)

HTML, CSS, 자바스크립트로 작성된 문서를 파싱하여 브라우저에 시각적으로 출력하는 것이다. 즉, 해석된 위의 HTML, CSS, 자바스크립트를 유저가 화면상에서 볼 수 있도록 뿌려주는 것이다.

브라우저의 렌더링 과정을 요약하면 아래와 같다.

1. GET 요청

먼저 브라우저가 HTML, CSS, 자바스크립트, 이미지, 폰트 파일 등 렌더링에 필요한 리소스를 요청하고, 서버로부터 응답을 받는다.

2. [렌더링 엔진] HTML, CSS 파싱 → DOM, CSSOM 생성 → 렌더트리 생성

브라우저에는 렌더링 엔진이라는 것이 있다. HTML, CSS 등의 문서를 해석해주는 친구이다.
대표적으로 크롬의 Blink, Mozilla 등이 있다.

이 렌더링 엔진이라는 친구가 HTML 문서를 파싱하여 DOM을 생성하고, CSS 문서를 파싱하여 CSSOM을 생성한다. 그리고 이 2개를 결합하여 렌더 트리를 생성한다.

3. [자바스크립트 엔진] 자바스크립트 파싱 → AST(추상적 구문 트리) 생성, DOM API로 DOM, CSSOM 변경 → 변경된 DOM, CSSOM 렌더트리에 재결합

브라우저에는 자바스크립트 엔진이라는 친구도 있다. 자바스크립트를 파싱하여 CPU가 이해할 수 있는 저수준 언어로 변환하고 실행한다.
대표적으로 Node.js의 V8이 있다.

자바스크립트 엔진이 렌더링 엔진으로부터 제어권을 넘겨 받으면, AST(추상적 구문 트리)를 생성하고, 이를 기반으로 인터프리터가 실행할 수 있는 중간 코드인 바이트코드로 변환하여 실행한다.

그리고 이때 자바스크립트는 DOM API를 이용하여 DOM이나 CSSOM을 변경할 수도 있다. (웹 페이지를 동적으로 조작하기 위해 사용되는 인터페이스인 createElement(), addEventListener() 등이 DOM API의 예시가 될 수 있다.)

4. 리플로우, 리페인트

이렇게 DOM API를 이용하여 변경된 DOM과 CSSOM이 렌더 트리에 재결합되면, 변경된 렌더트리를 기반으로 리플로우와 리페인트를 거쳐 리렌더링이 발생한다.

• 리플로우: 레이아웃 계산을 다시 함
• 리페인트: 페인트를 다시 함

CSR, SSR 둘 다 이러한 과정들을 공통적으로 거친다. 다만 서버와 클라이언트 간의 작업 분배 방식에서 차이를 보이게 되는데, 이제 이 둘의 차이에 대해 알아보자.

2. CSR과 SSR의 개념과 특징

CSR(Client-Side Rendering)

서버: 브라우저, 너가 알아서 렌더링 하던지 말던지 (귀찮은 손가락으로 투척 와다다다)

단어 그대로 렌더링을 클라이언트가 하는 방식이다. 서버는 초기 로드 시에 필요한 최소한의 HTML, CSS, Javascript 파일만 전송하고, 클라이언트 측에서 자바스크립트 다운로드 및 실행 이후 필요한 데이터를 서버로 요청하여 placeholders를 채우며 동적으로 렌더링하는 방식이다.

위의 사진에 있는 순서를 하나씩 차례대로 살펴보자.

1. 유저가 웹사이트를 요청함
2. CDN이 Javascript 링크가 있는 HTML 파일을 보내준다.
   • CDN(Content Delivery Network) : 컨텐츠 전송 네트워크. 원본 서버에서 자원을 가져와서 캐싱해놓고, 원본 서버와 지리적으로 멀리 떨어져 있는 클라이언트에게도 빠르게 자원을 제공할 수 있는 기술
3. 브라우저가 (데이터가 모두 포함되어 있지는 않은) HTML을 다운로드 받는다. (자바스크립트 파일이 실행이 안되어서 유저에게는 아직 보이는 게 없다.)
4. 브라우저가 자바스크립트 파일을 다운로드 받는다.
5. 자바스크립트 드디어 실행!하여 동적으로 페이지를 구성한다. 서버에게 데이터를 요청하기 위한 API가 호출되는데, 이 때 유저는 아직 placeholder(데이터가 곧 채워질 빈칸이라 생각하면 된다.)만 보게 된다.
6. API 호출되었으니 서버가 데이터와 함께 응답한다.
7. 데이터가 드디어 placeholder를 채우고나면, 유저와 상호작용이 가능해진다.

즉 서버에서 완성되지 않은 날 것의 HTML을 보내주기 때문에, 클라이언트 측에서 자바스크립트를 실행하기 전까지는 딱히 볼 수 있는게 없다.

SSR(Server-side rendering)

서버: 클라이언트님, 지금 바로 렌더링할 수 있는 HTML 파일을 저희 쪽에서 정성껏 만들었으니 한번 구경해보세요.

웹페이지 렌더링을 서버 측에서 하는 방식이다. 클라이언트 측에서 웹 페이지를 요청하면, CSR과 달리 뼈대가 되는 HTML만 던져주는 게 아니라 데이터를 채워 넣은 HTML 파일을 전송해준다.

SSR도 단계 별로 살펴보자.

1. 유저가 웹사이트를 요청함
2. 서버가 "Ready to Render", 즉 렌더링할 준비가 이미 다 된 데이터가 꽉꽉 채워진 HTML 파일을 생성한다.
3. 브라우저가 HTML 파일을 받으면 데이터가 채워져 있기 때문에, 자바스크립트를 다운로드 받기도 전에 바로 렌더링하더라도 유저가 볼 수 있는 데이터들이 있다.
4. 브라우저가 자바스크립트 파일을 다운로드 받는다.
5. 유저가 컨텐츠를 볼 수는 있지만, 아직 자바스크립트가 실행되기 전이기 때문에 상호작용은 할 수 없다. 예를 들어 버튼을 클릭하면 창이 뜨기를 기대하더라도, HTML 파일 그 잡채이므로 창은 아직 뜨지 못한다. 다만 이러한 이벤트들이 (추후 JS프레임워크 실행 이후 재생될 수 있도록) 따로 기록된다.
6. JS 프레임워크 실행!
7. 드디어 기록되었던 이벤트들이 실행되고(아까 전에 버튼을 눌렀으니 이제 창이 뜬다던가), 유저와 상호작용을 할 수 있는 페이지가 된다.

서버에서 완성된 HTML 파일을 대령해주기 때문에, 클라이언트 측에서 자바스크립트를 실행하기 전부터 벌써 컨텐츠들을 볼 수 있다.

3. CSR과 SSR의 장단점 비교

1. 로딩시간 비교

첫 화면 로딩

CSR : 깡통 HTML 페이지만 받아서 자바스크립트 파일 다운로드하고 실행하여 렌더링해야 하는데 어느 세월에 다해? 바쁜 브라우저..초기 로딩 시간이 길 수 밖에 없다.

SSR : 그 때 그때 필요한 HTML을 불러오기 때문에 (심지어 서버가 이미 생성도 완료해 놓음) 단일 파일의 용량이 적은 SSR이 평균적으로 더 빠르다.

나머지 로딩

CSR : 일단 자바스크립트 실행까지 다 마쳤다? 이제 서버에 요구할 건 fetch해 올 데이터 뿐! SSR과 달리 서버한테 웹 페이지를 다시 요청할 필요가 없으므로, 첫 화면 로딩만 바쁘게 끝내놓으면 CSR이 SSR보다 빠르다.
사용자가 다른 경로를 요청하더라도, 서버한테 새로운 웹 페이지를 달라고 할 필요없이 (맨 처음 웹 페이지 파일과 동일한 파일에서) 동적으로 라우팅을 관리하기 때문에 새로고침할 필요도 없다. 빠르다는 뜻이다.

SSR : 첫 화면 로딩은 빨랐지만, 사용자가 다른 경로를 요청한다? 서버에 새로운 웹 페이지를 요청해야 한다. 즉, 첫 화면 로딩할 때 했던 작업을 다시 수행해야 한다. 처음에만 무지 바쁜 CSR 클라이언트에 비해 SSR에서는 클라이언트가 일관성있게 조금씩 바쁘다.

2. SEO 측면 (SSR > CSR)

SEO(Search Engine Optimization)

검색 엔진 최적화, 즉 웹사이트나 컨텐츠가 검색 엔진에서 잘 노출되도록 최적화하는 작업을 말한다. 검색 엔진에서 상위에 노출되면 웹사이트 방문 트래픽이 증가하여 기업이나 개인 브랜드의 홍보와 마케팅 측면에서 유용한 도구가 된다.

구글 등 검색엔진은 웹사이트의 정보를 수집하기 위해 크롤러라는 프로그램을 이용한다. 크롤러가 사이트를 방문하여 해당 사이트의 페이지 목록을 작성하고, 검색 엔진 색인에 추가한다. 그렇다면 SSR과 CSR 중 SEO에 더 유리한 방식은? 정답은 60초 후에 공개하겠음.

SSR : 서버에서 HTML을 렌더링해주기 때문에, 검색엔진 크롤러가 페이지의 컨텐츠를 수집하기 쉽다.

CSR : 서버가 빈 HTML 파일을 던져주고, 클라이언트 측에서 초기 로딩 후에 자바스크립트를 실행하여 페이지를 동적으로 생성하기 때문에 검색 엔진이 웹 페이지의 컨텐츠를 인덱싱(컨텐츠를 수집하고 분석하여 색인을 생성하는 것)하기 어렵다.

따라서 SSR이 SEO에 더욱 유리하다. BBC News, CNN 등 검색엔진 상위 노출이 중요한 뉴스 웹사이트나 Amazon, Walmart 등 전자상거래 기업에서도 SSR을 많이 사용한다.

3. 서버 리소스 부담

CSR : 클라이언트 측에서 HTML, CSS, JS를 렌더링하므로 서버에 부담이 적다.

SSR : 서버에서 HTML 파일을 만들어서 클라이언트에게 전달해야 하므로 서버 리소스 부담이 크다. 심지어 유저가 다른 경로를 요청할 때마다 서버에서 HTML 파일을 전달해줘야 하기 때문에 이러한 부담은 더욱 가중된다.

4. 그래서 CSR, SSR 둘 중 뭘 써야 하나? 장점만 취할 수는 없나?

위에서 살펴보았듯이, CSR과 SSR은 각각 장단점이 있기 때문에 어떤 방식이 나을지는 상황과 목적에 따라 달라진다.

CSR은 초기 로딩 시간이 길기는 하지만, 페이지 전환 속도가 빠르고 서버 리소스 부담이 적어서 사용자와의 복잡한 상호작용이 필요한 웹 어플리케이션에 적합하다.

SSR은 서버 리소스 부담이 크지만, 초기 로딩 시간이 짧고 SEO 측면에서 강점이 있기 때문에 정적인 컨텐츠가 주가 되거나 SEO가 중요한 요소인 웹 사이트에 적합하다.

물론 둘 중에 꼭 하나만 쓸 필요는 없다. CSR과 SSR을 적절히 조합하여 사용하는 Hybrid Rendering도 있다.
초기 로딩 시에는 SSR을 사용하여 페이지를 서버 측에서 렌더링하고, 이후 로딩 시에는 CSR을 사용하여 페이지를 렌더링하는 방식이다. 이렇게 하면 초기 로딩 시간을 단축하면서도 SEO 최적화가 가능하다. 초기 로딩 성능 향상과 빠른 상호작용까지 잡으니 사용자 경험 개선 가능!

React에서는 Next.js와 Gatsby라는 프레임워크를 사용하여 구현 가능하다고 한다. 나중에 Next.js도 배워보고 싶다 ㅎㅎㅎ

여기까지 !! CSR과 SSR의 차이 포스팅 끄-읕 !
그는 좋은 공부였습니다 ..⭐️

참고:
https://hahahoho5915.tistory.com/52
https://proglish.tistory.com/216