[JS] # 0. 서버 사이드 렌더링 vs 클라이언트 사이드 렌더링

먼저 위 2가지 특징을 쓰기 전에, 렌더링에 대한 설명이 필요할 것 같다.

렌더링 : HTML/CSS 를 각각 Parser를 통해 개발자가 작성한 문서를 읽고 화면에 결과물을 그려내는 작업

 

일단 이것만 봐도 이해가 확 와닿진 않을 것이다.

지금 우리가 보고 있는 이 화면도 HTML문서로 작성이 되었고, 폰트나 색깔, 레이아웃 배치 등등은 CSS로 작성이 된 것이다. 당장 네이버를 키고 F12를 누르면 바로  현재 보고 있는 화면이 어떤 코드들로 이루어졌는지 알 수 있다.

 

 

이게 지금 현재 네이버 메인화면의 개발자도구(F12) 화면이다. 한눈에 다 보긴 어렵지만, 오른쪽 사이드바에 "DOM Breakpoints"라는게 보일 것이다. DOM. 오늘은 이거에 집중해보자.

 

DOM은 HTML의 구조를 보여주는 것인데

출처 : https://wooder2050.medium.com/%EC%9D%B4%EB%A1%A0-%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8-dom-%ED%8A%B8%EB%A6%AC-96ca3008a474

 

이런 식으로 상위 태그부터 하위 태그까지를 트리형태로 표현된 것을 DOM Tree라고 한다.

HTML Parser는 이 태그들을 분석해서  개발자가 이러이러하게 짜놨구나. 이대로 드로잉해야겠다. 하는 역할을 한다.

CSS측도 마찬가지다.

 

아 그러면 렌더링 과정이

1. HTML , CSS 문서를 전달받는다. (이걸 전달받고 표현하는 주체가 누구냐에 따라 SSR, CSR로 구분된다)

2. HTML은 DOM Tree 분석을, CSS는 CSSOM 분석을 통해 렌더링을 시작한다.

3. 완성된 결과물을 표현하거나, 전달해준다. (1번과 동일)

 

이렇게 요약할 수 있겠다.

그럼 이제 CSR, SSR을 한번 보자.

 

서버 사이드 렌더링 (Server Side Rendering)

개발자가 작성한 HTML/CSS를 분석하고 드로잉을 하는 주체가 서버 측에 있는 것이다.

그럼 여기서 개발자의 브라우저는 클라이언트가 된다. 내가 이렇게 이렇게 짜놨으니 서버가 분석하고 화면 그려서

다시 나한테 전달해줘! 라고 볼 수 있겠다.

 

이 SSR의 특징으로는 서버가 렌더링을 처리하므로 화면 로딩 속도가 CSR보다 빠른 편이다.

근데, 렌더링도 맡기고 또 이런저런 작업들을 요청하다보면 서버로 트래픽이 몰려 과부하가 걸릴 수도 있다.

이게 맞는 상황예시인지는 모르겠다만... 티케팅을 위해 인터파크같은 사이트에 접속이 몰리면 흰화면만 뜨고 렌더링이 안되는 경우를 종종 봤을 것이다. 

 

요즘 웹사이트들은 CSR, SSR 둘다 섞어서 쓴다해서 맞는 상황 예시인지는 모르겠지만, 어떤 느낌인지만 파악해가면 될 것 같다.

 

 

클라이언트 사이드 렌더링 (Client Side Rendering)

드로잉 주체가 클라이언트 측이 된다. 얘의 경우는 첫 화면 로딩 자체는 느리다. 왜냐하면 Client 측에서 DOM Tree를 구성하고 파싱하고하는 작업을 서버 대신 하기 때문이다. 리액트로 웹 만드신 분들은 느낄텐데  리액트기반 웹을 처음 실행하면 화면에 띄워지는 시간까지 은근 기다림이 있다. 짧긴하지만 체감은 살짝 될 것이다.

 

다만, 메인 화면이 로드된 이후에 페이지 내부를 돌아다니는데 있어서는 로드되는 작업이 없기에 화면 넘김에 간편하다.

리액트는 CSR 방식을 채택하고 있다.

그렇다고 첫페이지 로딩만 감수한다고 CSR이 무조건 좋은 것은 아니다. 검색엔진에 있어서 최적화가 필요하기 때문이다.

url 링크를 통해 또 다른 페이지로 로드되는 과정에서는 SSR처럼 빠르지가 않기 때문이다.

 

내가 기억하기론 이런 과정을 크롤링을 통해 보완하는 방식이 있다 들었는데 네이버 개발자 도구 화면을 보니 디렉토리 구조에 셀레니움이 보이긴하다.