CSR과 SSR의 렌더링 차이

CSR과 SSR

기본적으로 브라우저는 다음과 같이 동작합니다.

브라우저 동작 과정💡

서버와의 통신 → 브라우저 렌더링 → 스크립트 실행

이전 글에서 정리한 브라우저의 렌더링원리에서 처럼, 브라우저의 동작 단계는 크게 3단계로 나뉘어 집니다. 이는 SSR과 CSR 모두 동일한 단계를 거치는 것을 의미합니다. 그렇다면 둘의 렌더링에서 어떤 차이가 있을까?

SSR의 렌더링 과정

• SSR은 서버로부터 어느정도 구조가 갖춰진 HTML 문서를 받은 뒤, 렌더링합니다.

1) 서버와의 통신

1. 브라우저가 서버로 요청을 보냅니다.

2. 서버는 요청에 따른 구조가 잡힌 HTML문서 파일을 응답받습니다.

2) 브라우저 렌더링 엔진에 의한 렌더링

1. HTML을 파싱하여 HTML 태그를 하나하나 해석하여 DOM 트리 생성

   • 아직 각각 어떤 크기로 표현할지는 CSS코드가 필요함

2. CSS를 파싱하고, CSSOM(CSS객체모델) 트리 생성

3. DOM 트리와 CSSOM 결합

4. Render 트리 생성

   • 아직 생성만 된 상태

   • 각각의 DOM Tree별로 어떤 스타일 정보르 ㄹ가지고 있는지, 실제로 소프트웨어의 어떤 객체 모델로 객체화

5. 브라우저가 Render 트리를 읽고 Layout 또는 Reflow 과정을 통해 위치와 크기를 결정

   • DOM 노드의 위치와 그래픽을 계산 → 어디에 위치될건지, 크기가 몇인지를 결정

6. Render 트리 완성

7. Render 트리를 통해 화면에 실제로 그려주는 페인팅 작업 진행

8. 브라우저 화면에 출력 (DisPlay)

3) 자바스크립트 실행

1. 스크립트 태그를 통해 자바스크립트 파일을 한줄 한줄 읽으며 바로 실행

   • 이때 UI는 완성이 되어 있음

   • UI에 이벤트 등록, 동적인 화면 구현을 위한 기능 추가 (예 : 화면을 다크모드로 전환)

CSR의 렌더링 과정

• CSR은 서버로부터 css, js 링크만 있는 빈 HTML 파일을 전송받아 클라이언트 사이드에서 랜더링하는 방식

Key Point💡

CSR은 SSR과의 동작 과정은 전반적으로 비슷하며, 컨텐츠를 그려주는 과정과 시점만 다르다

1) 서버와의 통신

1. 브라우저가 서버로 요청을 보냄

2. 서버는 요청에 따른 css, js링크만 있는 빈 HTML 파일을 응답합니다.

2) 브라우저 렌더링 엔진에 의한 렌더링

SSR의 렌더링 과정과 똑같이 수행하지만 HTML 파일안에는 현재 아래와 같은 코드만 들어있습니다.

<div id="app"></div>
<script src="app.js"></script>

• 렌더링과 관련한 내용이 js 파일안에 들어있는 상태입니다.

3) 자바스크립트 실행

1. 스크립트 태그를 통해 자바스크립트 파일을 한줄한줄 읽으며 바로 실행

   • 이때, UI가 미완성이 되어 있으므로, JS에서 UI요소를 하나하나 동적으로 생성해서 그려줌

   • UI를 그려줌과 동시에 이벤트 등록, 동적인 화면 구현을 위한 기능 추가

차이점은?

결국의 차이점은 브라우저가 언제 그려지는가에 차이가 있습니다. SSR의 경우 브라우저 렌더링 엔진에 의한 렌더링일 떄, 전반적인 UI가 그려진 후, 스크립트 실행에서 추가적인 기능을 추가하는 반면에, CSR의 경우 자바스크립트 실행 단계에서 js 코드를 해석하여 UI를 그려주게 됩니다.

느낀점

그렇다면 진정한 의미에서의 스켈레톤 UI같은 로딩 상황이나 이미지의 LazyLoading을 걸어주는 것은 SSR이 더 적합하지 않을까...?