Server Side Rendering (SSR) : 서버 측 렌더링 이란 ?
서버사이드 렌더링(일명 SSR)은 서버가 클라이언트에게 HTML 파일을 전달할 때, 사용자가 볼 수 있는 완전한 html을 전송한다는 뜻이다.
즉, 클라이언트가 서버에게 요청신호를 보내면, 클라이언트의 웹 브라우저가 페이지를 그리기 위해 별도의 작업을 할 필요 없이 완전히 구성된 페이지(html)를 클라이언트에게 돌려주는 것이다.
SSR 에 대한 정의는 아주 심플하지만, 정확하게 감이 잘 오질 않는다. 용어 정리부터 다시 해보자.
렌더링(Rendering) 이란 ?
웹 개발에서의 렌더링은 웹 사이트 코드를 사용자가 웹 사이트를 방문할 때 보게 되는 실제 대화형 페이지로 바꾸는 프로세스다. (코드 -> 페이지)
이 용어는 일반적으로 HTML, CSS 및 JavaScript 코드의 사용을 나타낸다.
이 렌더링이란 프로세스는 일반적으로 웹 브라우저에서 사용되는 렌더링 엔진에 의해 수행되는데. 웹 브라우저와 밀접하게 연관되어 있어 렌더링 엔진을 일반적으로 브라우저 엔진이라고 말하기도 한다. (실제론 별개의 개념이지만 일반적으로 얘기하기도 한다)
브라우저 렌더링 프로세스의 순서
브라우저가 사용자에게 렌더링된 페이지를 제공하는 순서이다.
원시 데이터를 DOM과 CSSOM으로
웹 서버가 HTML, CSS 및 JavaScript가 포함된 파일 폴더를 사용자의 웹 브라우저로 전송 (웹서버 -> 브라우저 전송)
브라우저 엔진이 전송받은 데이터(Byte)를 문자(HTML 코드)로 변환 (Byte -> 문자열 Code)
코드 문자열( HTML Code )을 토큰으로 구문분석 + 토큰을 노드로 구문분석 (HTML 문자열 Code -> 토큰 -> 노드)
노드를 DOM(문서 객체 모델) Tree로 표현 + 동시에 CSS 코드는 CSSOM(CSS 객체모델)로 변환. (노드 -> DOM Tree, Css 코드 -> CSSOM)
DOM ? HTML, XML 문서의 프로그래밍 interface. 구조화된 Nodes와 Property, Method를 갖는 Object로 문서 표현.
CSSOM ? JavaScript에서 CSS를 조작할 수 있는 API의 집합. HTML 대신 CSS가 대상인 DOM이라고 생각할 수 있음.
Render Tree를 사용하여 최종 웹 페이지 생성
DOM과 CSSOM을 결합하여 Render Tree라는 트리 구조를 만든다.
렌더 트리는 visible 상태인 element들을 브라우저에 채우고 각 요소의 레이아웃을 계산하고 그리기 위해 필요한 스타일 및 콘텐츠 정보를 포함한다.
렌더 트리를 사용해서 각 요소의 위치를 계산한다.
계산된 위치에 맞게 사용자가 볼 수 있도록 화면에 요소를 추가하거나 그린다.
그래서 SSR 이 뭔데 ?
렌더링의 정의가 단순하게 생각해서, 서버가 HTML 파일들을 클라이언트에 제공하면 그걸 그리는 프로세스인데 .
SSR에서 말하는 렌더링 정의는 이 것과 다른 것 같다.
SSR에서 말하는 렌더링은 CSR의 반대 개념으로 이해하는 것이 좋은데. 한마디로 HTML 이 사용자의 눈에 페이지가 들어오기 까지 필요한 레이아웃과 로직들의 정의라고 한다면 이러한 정의를 작성하는 행위를 말한다. (즉, HTML을 작성하는 것). SSR은 그 행위를 서버가 하겠다는 뜻이다.
HTML은 내가 작성하는거 아니냐고 ?
html 파일을 정적으로 그려서 단순히 웹페이지에 게시하였을 때는 그럴 수 있다.
그러나 시대가 바뀌고 웹 기술 수준이 높아지면서 정적인 컨텐츠를 제공하던 웹페이지들이 사용자의 입력에 따라 동적으로 특정 영역만 변경하거나, 어디에도 정의되어 있지 않은 완전히 새로운 화면을 보여주어야 하는 경우도 생겼다.
그래서 HTML의 내용을 직접 작성하지 않고 javascript 언어로 동적으로 작성&변경하는 로직이 나타나게 됐다. (Ajax, jquery 등)
서버사이드 렌더링(일명 SSR)은 서버가 클라이언트에게 HTML 파일을 전달할 때 완전히 내용이 구성된 HTML 페이지로 변환하는 기능이라고 한다.
말이 너무 어렵다.
쉽게 말해서 이 말은 브라우저가 렌더링(HTML -> 사용자 눈) 작업을 안한다는 뜻이 아니고. CSR의 반대 개념으로 기존의 static한 HTML파일을 전송하겠다는 뜻이다.
즉, SSR 은 새롭게 생긴 개념이 아니라, 전통적인 static한 웹 페이지를 제공하는 방법이다.
가장 처음 단순한 문서를 인터넷을 통해 제공할 때, 서버는 접속 url에 따라 static한 html파일을 클라이언트에게 제공했다.
그러나 정적인 텍스트들을 제공하던 웹페이지들이 점차 발전하면서 사용자에게 제공하는 화면과 입출력들이 복잡해지고(무거워지고) 화면변경 횟수가 늘어남에 따라 서버에 화면을 새로 요청해야하는 횟수가 동시에 늘어났다. 웹 서비스를 제공하기 위해 서버의 부하가 커지게 된 것이다. (사용자가 버튼을 누를 때 마다 완전히 새로운 페이지를 불러와야했다.)
게다가 화면을 새로고칠 때 마다 화면이 깜빡이는 flickering Issue도 유저경험에는 좋지 못했다.
그 때 CSR(Client Side Rendering)이 도입되었다. ajax 등이 나오면서 클라이언트는 서버로부터 항상 전체 페이지를 불러오지 않고 json과 같은 정보 데이터를 가져와서 js를 통해 동적으로 html 문서를 작성한다는 개념이다. 쉽게 말하면 클라이언트의 브라우저가 js를 읽고 동작시켜서 html 문서를 작성한다고 이해하면 될 것이다.
결론적으로 SSR은 원래 html 파일을 서버가 제공하던 방식인데. CSR 개념이 도입되면서 javascript를 통해 동적으로 페이지를 클라이언트가 그리게 되었고.
그 반대 개념으로 다시 SSR이란 용어가 대두된 것이다. CSR이 없었다면 SSR이란 말도 없었을 것이다. 왜냐면 그것이 당연한거 였으니까.
그러나, SSR이 옛날에 제공했던 static html 페이지와 다른 것은 서버측에서 미리 정의해둔 html을 단순히 넘겨주는 것이 아니라, CSR 처럼 프로그래밍 언어를 통해 동적으로 새로운 html 파일을 작성할 수 있기 때문에 용어가 붙여진 것 같다. (서버쪽에서 렌더링 한다 !)
CSR과 SSR의 동작차이
 |
|---|
| 상 SSR 하 CSR |
싱글페이지 어플리케이션은 화면을 그리는 주체가 클라이언트기 때문에 서버로부터는 이후 화면에 들어갈 데이터만 심플하게 json 데이터로 넘겨받는다.
즉, 클라이언트 사이드 렌더링은 html 파일은 깡통으로 불러오고 다른 페이지들을 그릴 수 있는 로직과 정보가 담긴 js를 다운로드해 클라이언트 측에서 js를 통해 화면을 그리고.
서버 사이드 렌더링은 html파일에 사용자가 컨텐츠를 보기위한 모든 정보가 담긴 채로 파일을 받아서 바로 렌더링 한다.
***js를 안 받는 것은 아니다 ! 화면을 만드는 것과 관련된 js가 아닐 뿐이다. 서버사이드 렌더링도 html파일에 동작과 관련된 js파일이 존재한다면 추가적으로 서버에 js파일 제공을 요청한다.
코드로 비교해보자.
다음은 크롬 개발자도구로 확인한 현재 블로그 한 페이지의 html 데이터이다.
 |
|---|
| SSR |
body 태그에 li, a, span 태그 및 텍스트들이 모두 존재하고있다. 브라우저는 해당 html파일을 받아서 그리기만 하면 바로 사용자에게 화면을 제공할 수 있을 것이다.
 |
|---|
| CSR |
반면에 CSR 의 html을 상당히 심플하다. body 태그 내부에 어떠한 데이터도 없고. 앱의 시작점인 app.js 요청하고 해당 .js 파일부터 시작해 필요에 따라 모든 페이지를 동적으로 작성한다.
즉 , app.js 부터 파생된 일련의 javascript 로직들이 동작해서 html 문서를 만들기 전까지 사용자는 아무런 화면도 조회할 수 없다. 왜냐면 그것이 .. csr이니까.
SSR (서버 사이드 렌더링) vs CSR (클라이언트 사이드 렌더링)
그렇다면 CSR과 SSR은 왜 달라야 하는 것이고(?) 두 렌더링 방식의 차이는 왜 존재하는 것인가 ..
먼저 CSR은 SPA(Single Page Application)와 같이 인터랙션이 많은 동적인 페이지를 구성해야할 때 유리하다.
사용자 눈에 보이게되는 HTML을 그리는 주체가 클라이언트고 그리는 도구도 클라이언트가 가지고 있기 때문에 클라이언트의 액션이나 상황에 따라 동적으로 페이지를 구현하기에 유리하다. 게다가 데이터에 따라 특정 작은 영역만 화면을 변경할 때도 서버로 부터 전체 html을 불러올 필요없이 변경에 필요한 데이터만 받아와서 클라이언트가 변경 적용할 수 있으므로 서버에 대한 부담을 줄여줄 수 있다.
반면에 SSR은 HTML을 만들어서 사용자에게 제공하기 때문에 (동적으로 그릴 경우에도) 각 요청마다 새롭게 그린 전체 HTML파일을 클라이언트에게 계속 전송하여야 한다. 즉, 하나의 인터랙션에 전송하는 HTML크기가 크다는 것을 의미한다. 변경이 필요없고 중복된 데이터도 모두 포함하여 보내주어야 하기 때문이다. 그러나 화면을 그리기위한 많은 js 파일을 보내주지 않아도 된다는 것은 강점이다.
그럼 CSR이 더 좋은거 아닙니까?
반드시 그렇지는 않다. 각 방식은 장단점이 존재한다.
CSR
- 장점 1. 초기 로딩 이후에 특정 페이지로의 이동, 컨텐츠의 변경작업 등 인터랙션에 대한 처리 속도가 빠르다. (필요한 데이터만 가져오기 때문)
- 장점 2. 특정 영역만 클라이언트가 재구성할 수 있기 때문에 페이지 전환이나 데이터 변경시에 깜빡임 이슈가 없다.
장점 3. 페이지가 로드되면 바로 상호작용 할 수 있다. ( TTV = TTI )
- 단점1. 초기 로딩 속도가 느리다. (서버로 부터 깡통 html 파일을 받고 화면을 그리기위한 js를 받은 다음 이를 동작시켜야 비로소 화면을 그릴 수 있다. 이 작업이 끝날 때 까지 사용자는 흰색 화면만 봐야한다.) 그러나 요즘 기기 성능이 점점 좋아지면서 큰 의미는 없어진 것 같다.
- 단점2. 검색엔진 최적화(Search Engine Optimization, SEO) 에 불리하다. 구글 같이 js내용을 읽을 수 있는 똑똑한 검색엔진이 아니면 일반적인 크롤러는 html 파일밖에 참고하지 못하는데 html파일은 깡통이기 때문에 검색엔진은 빈 페이지로 인식한다. 즉 검색 결과 상단에 노출될 수 없다..)
SSR
- 장점 1. 사용자가 처음 페이지 컨텐츠를 보는데까지 걸리는 시간이 적다. (초기로딩이 빠르다.)
장점 2. SEO에 유리하다. (CSR 단점과 반대)
- 단점 1. 초기 로딩 이후의 단순 변경은 느리다. (서버가 전체 페이지를 그려야하기 때문에)
- 단점 2. 서버 부하가 증가한다. (html을 만드는게 서버이기 때문에)
- 단점 3. (정적 페이지가 아니라면) 컨텐츠를 보는것과 상호작용이 가능한 시간이 다르다. (상호작용을 위해 .js 파일이 필요하다면 클라이언트는 추가적으로 파일을 요청할 것이고 그것이 모두 실행되기 전까지는 상호작용 할 수 없다. TTV != TTI )
TTV : Time to View (볼 수 있는 시간)
TTI : Time to Interact (상호작용 가능한 시간)
 |
|---|
 |
| SSR과 CSR의 TTV, TTI : https://www.omnisci.com/technical-glossary/server-side-rendering |
어떻게 하면 잘 쓸 수 있나요
위와 같이 각 방식의 장단점이 뚜렷하기 때문에 두 렌더링 방식 중 반드시 하나를 선택해야 하는 것은 아니다.
동적인 인터랙션이 많은 페이지는 CSR로 , 정적인 컨텐츠가 많은 페이지는 SSR로 구현할 수 있고.
게다가 빌드 타임에 어플리케이션을 실행하여 초기 상태를 정적 HTMl로 캡쳐하여 파일을 만들어서 SEO에 조금 더 유리해질 수 있는 Prerendering 기법이나
서버에서 렌더링 한 HTML의 돔 트리와 데이터를 재사용하도록 하는 Rehydration 등의 기법도 존재한다. (물론 뭐든지 비용이 든다)
따라서 구동 방식에 대해 이해를 하고, 어떤 방식이 어떤 환경에서 좋을지 고민해야한다.
CSR은 가장 큰 단점이 페이지를 그리고 상호작용하기 위해 많은 .js파일을 요구하고 그 것에 따라 초기 로딩 속도가 느려지는 것이기 때문에 반드시 필요한 영역에 필요한 js 만을 요구할 수 있도록 고려되어야 하고
SSR은 어떻게 하면 서버에서 렌더링하는 시간과 TTV 와 TTI 의 시간차를 단축시킬지를 고민하자.
References
https://developers.google.com/web/updates/2019/02/rendering-on-the-web?hl=ko
https://www.seobility.net/en/wiki/Rendering
https://www.omnisci.com/technical-glossary/server-side-rendering
https://medium.com/walmartglobaltech/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8