렌더링, DOM 개념, 서버 사이드 렌더링(SSR) vs 클라이언트 사이드 렌더링(CSR), SPA

티스토리 뷰

Web/Vue.js

렌더링, DOM 개념, 서버 사이드 렌더링(SSR) vs 클라이언트 사이드 렌더링(CSR), SPA

Caminante 2020. 11. 6. 15:14

렌더링

어떠한 웹 페이지 접속시, 그 페이지를 화면에 그려주는 것
서버로부터 HTML 파일을 받아 브라우저에 뿌려주는 과정
브라우저는 서버로부터 HTML 문서를 다운 받는다. 렌더링 엔진은 HTML 문서를 파싱해서 DOM 트리를 만든다.
(브라우저는 렌더링을 수행하는 렌더링 엔진(Rendering Engine)을 가지고 있다.
크롬의 경우 웹킷(Webkit)을 사용하다가 웹킷을 Fork하여 블링크(Blink) 엔진을 자체적으로 구현하여 사용하고 있다.)

렌더링 과정

1. DOM(Document Object Model), CSSOM(CSS Object Model) 생성

가장 첫 번째 단계는 서버로부터 받은 HTML, CSS를 다운로드 받는다. 그리고 HTML, CSS 파일은 단순한 텍스트이므로 연산과 관리가 유리하도록 Object Model로 만들게 된다. HTML, CSS 파일은 각각 DOM Tree와 CSSOM으로 만들어진다.

2. Render Tree 생성

DOM Tree와 CSSOM Tree가 만들어졌으면 그 다음으로는 이 둘을 이용하여 Render Tree를 생성한다. 순수한 요소들의 구조와 텍스트만 존재하는 DOM Tree와는 달리 Render Tree에는 스타일 정보가 설정되어 있으며 실제 화면에 표현되는 노드들로만 구성된다.

3. Layout

Layout 단계는 브라우저의 뷰포트(Viewport) 내에서 각 노드들의 정확한 위치와 크기를 계산한다. 풀어서 얘기하자면 생성된 Render Tree 노드들이 가지고 있는 스타일과 속성에 따라서 브라우저 화면의 어느 위치에 어느 크기로 출력될지를 계산하는 단계라고 할 수 있다. Layout 단계를 통해 %, vh, vw와 같이 상대적인 위치, 크기 속성은 실제 화면에 그려지는 pixel 단위로 변환된다.

뷰포트(Viewport) : 그래픽이 표시되는 브라우저의 영역, 크기

4. Paint

Layout 계산이 완료되면 이제 요소들을 실제 화면을 그리게 된다. 이전 단계에서 이미 요소들의 위치와 크기, 스타일 계산이 완료된 Render Tree를 이용해 실제 픽셀 값을 채워넣게 된다. 이 때 텍스트, 색, 이미지, 그림자 효과 등이 모두 처리되어 그려진다.

DOM

텍스트 파일로 만들어져 있는 웹 문서를 브라우저에 렌더링하려면 웹 문서를 브라우저가 이해할 수 있는 구조로 메모리에 올려야 한다.

브라우저의 렌더링 엔진은 웹 문서를 로드한 후, 파싱하여 웹 문서를 브라우저가 이해할 수 있는 구조로 구성하여 메모리에 적재하는데 이를 DOM이라 한다. 즉, 모든 요소와 요소의 어트리뷰트, 텍스트를 각각의 객체로 만들고 이들 객체를 부자 관계를 표현할 수 있는 트리 구조로 구성한 것이 DOM이다. 이 DOM은 자바스크립트를 통해 동적으로 변경할 수 있으며 변경된 DOM은 렌더링에 반영된다.

브라우저의 구성 요소

사용자 인터페이스
브라우저 엔진 : 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어
렌더링 엔진 : 요청한 콘텐츠를 표시
통신 : HTTP 요청과 같은 네트워크 호출
UI 백엔드 : OS 사용자 인터페이스 체계를 사용
자바스크립트 해석기
자료저장소 : 웹 스토리지(로컬 스토리지, 세션 스토리지), 쿠키

SSR, 서버사이드 렌더링 방식 (전통적인 방식에서의 웹페이지 구동 방식)

요청시마다 새로고침이 일어나며 서버에 새로운 페이지에 대한 요청을 하는 방식
마치 필요한 물건이 있을때마다 사러 가는것과 비슷하다.
사용자가 페이지를 이동할 때 마다 서버에 페이지에 대한 요청을 하며 서버에서는 html, css, js 와 같은 리소스들을 어떻게 보여질지 해석하고 렌더링하여 사용자에게 반환한다.
하지만 기술의 발전으로 웹에서 제공되는 정보량이 많아지고, 여러 문제점이 발견되면서 전통적인 방식의 웹페이지 구동방식과는 다른 SPA (Single Page Application) 기법이 등장하게 되었다.

서버에서 무슨 렌더링을 한다는거지? ~~그럼 .html이 아니라 DOM 트리를 그린 형태로 클라이언트로 넘긴단건가? 아님!!!~~

: 클라이언트에서 요청이 들어오면 서버에서 화면 구성에 필요한 데이터를 구성한 뒤, 템플릿 엔진이 파일과 데이터를 가지고 렌더링한다.

렌더링이 완료되면 데이터가 바인딩 된 형태로 변환되고 결과물을 클라이언트로 서빙한다.

= 클라이언트에서는 초기 웹 페이지 구성에 필요한 데이터를 요청하지 않아도 된다.
서버에서 'Ready to be rendered HTML or Fully rendered HTML'을 클라이언트로 응답한다고 하는데 이게 어떤 상태인지 구체적으로는 모르겠다. 데이터 바인딩까지 완료된, 읽기만 하면 되는 HTML인 것 같긴하다. (O)

자문자답 ↓

서버 사이드 렌더링

완벽하게 그려진 HTML 페이지를 브라우저에서 받는 것
서버에서 브라우저로 HTML 파일을 넘겨줄 때 화면에 나타낼 텍스트 값과 <ul>, <li> 태그가 이미 완벽하게 그려져 있다. 따라서 브라우저에서는 그냥 해당 파일을 표시하기만 하면 되고, 별도의 자바스크립트를 이용한 화면 렌더링은 필요하지 않다.

클라이언트 사이드 렌더링

다 그려져 있지 않은 HTML 페이지를 브라우저에서 받고 프론트엔드 프레임워크와 같은 자바스크립트를 이용하여 나머지 부분을 그리는 것
우리가 일반적으로 생각하는 .vue 파일(<template>, <script>, <style>)이 "다 그려져 있지 않은 HTML 페이지"이다.
서버에서 보내준 HTMl 파일을 받았을 때 브라우저가 이 HTML 파일을 화면에 로딩하면서 뷰 프레임워크(자바스크립트)를 이용하여 인스턴스를 생성한다. 그리고 <ul>과 <li> 태그를 템플릿 속성에 생성하여 화면에 붙여 넣는다. 이제 화면이 완성되어 브라우저에 최종 형태가 표시된다.

SSR의 장점

사용자가 처음으로 컨텐츠를 볼 수 있는 시점을 앞당길 수 있음
다 그려져 있는 상테에서 화면에 단순히 나타내기만 하는 것(SSR)과 자바스크립트 라이브러리를 로딩하고 데이터와 화면 요소를 계산하여 화면에 나타내는 것은 속도에서 많은 차이가 있다. 화면을 그리기 위한 자바스크립트 라이브러리를 몇 개 더 다운로드하는 시간부터 이미 추가로 발생하기 때문이다.
검색엔진최적화(SEO) 적용이 용이

SSR의 단점

모든 요청에 관해 필요한 부분만 수정하는 것이 아닌, 완전히 새페이지를 로딩하고 렌더해줌 (새로고침)
전체를 로딩하다보니 CSR보다 느리고, bandwitdh를 많이 쓰고, 사용자 경험이 좋지 않음
(사용자가 처음으로 컨텐츠를 볼 수는 있으나, 화면단에는 html요소들이 나오나 js파일이 다 다운로드 되지않아서 버튼이 클릭되지않는 등의 현상이 있을 수 있음)

SPA 구동방식 (CSR, 클라이언트사이드 렌더링 방식)

미리 해당 페이지들을 받아 놓고 페이지 이동 시에 클라이언트의 라우팅을 이용하여 화면을 갱신하는 패턴을 적용한 애플리케이션

(웹 서버가 처음에 모든 파일 다 줌. 페이지를 이동할 때마다 서버에 웹 페이지를 요청하여 새로 갱신하는 것이 아님.)

최초 한번 페이지 전체를 로딩한 이후 부터는 데이터만 변경하여 사용할 수 있는 웹 어플리케이션
(하나의 html파일로만 동작함, 리액트 프로젝트 파일도 보면 다 html파일 하나로 작업)
HTML을 반환한 후에, JS가 동작하면서 데이터만을 주고 받아서 클라이언트에서 렌더링을 진행하는 것
점점 더 복잡해지는 웹페이지를 구현하기 위해서 전통적인 방식의 SSR보다는 CSR로 웹을 구현하는 경우가 많아짐

SPA는 한 종류의 화면만 존재하는 것이 아니다.
화면에 따라 다른 주소를 가진다. 주소가 있어야 사용자들이 북마크도 가능하고, 서비스에 구글을 통해 유입될 수 있기 때문이다(SEO).

주소에 따라 다른 뷰를 렌더링하는 것을 라우팅이라고 한다. 라우터는 사용자가 요청한 URL에 따라서 다른 결과물을 렌더링해준다. 일반 Apache, Nginx 등의 웹 서버에서 각 페이지마다 다른 디렉토리 및 파일을 제공하여 여러 페이지를 구현하는것과 달리, 리액트 라우터(react-router)를 사용하는 프로젝트에서는 어떤 경로로 들어오던 똑같은 html 파일과 자바스크립트 파일을 제공한다.

여기서 제공되는 js 파일에서는 웹 어플리케이션에서 사용 할 모든 컴포넌트들이 담겨있고, URL에 따라서 지정된 컴포넌트를 렌더링해준다. 그리고, 페이지가 한번 로드 된 다음에 다른 페이지로 이동 시, 이동 될 때 마다 페이지를 처음부터 로딩하지 않고 기존에 불러왔었던 자바스크립트 파일을 이용하여 페이지에서 기존 컴포넌트를 언마운트 시키고 다른 컴포넌트를 마운트한다. React자체에는 이 기능이 내장되어있지않기 때문에 라이브러리 react-router를 사용해서 설정해야 한다.

동작과정 : html 다운로드 → js 다운로드 → js 실행 → data 서버로부터 받기 → content 확인 가능

CSR의 장점

클라이언트 사이드 렌더링은 사용자의 행동에 따라 필요한 부분(페이지 전체 요청 X)만 다시 읽어들이기때문에 SSR 보다 조금 더 빠른 인터랙션이 가능
Lazy loading을 지원한다.
Lazy loading: 페이지 로딩 시 중요하지 않은 리소스의 로딩을 늦추는 기술 (ex. 스크롤 내려야만 해당 이미지 보이게 하는 것)
뷰 렌더링을 유저의 브라우저가 담당하도록 하고, 먼저 웹앱을 브라우저에 로드 한 다음에 정말 필요한 데이터만 전달받아 보여주는 CSR은 트래픽을 감소시키고, 사용자에게 더 나은 경험을 제공한다.
서버는 단지 JSON파일만 보내주고, html을 그리는 역할은 자바스크립트를 통해 클라이언트 측에서 수행한다 → 백엔드를 API서버로 사용하여 프론트엔드와 완전히 분리할 수 있음

CSR의 단점

Googlebot과 Searchconsole에 검색 노출이 되지 않음 (동적 페이지 렌더링을 하기 때문에)
서버에서 view를 렌더하지 않고, html을 다운받은 다음 js 파일이나 각종 리소스를 다운받은 후 브라우저에서 렌더링하여 보여주기 때문에 초기 구동 속도가 느리다. (허나 view가 보여진 시점에서 바로 인터랙션이 가능하다.)

SSR & CSR

어떤것이 더 좋은 방식이라고 말할수 없다. 어쨌든 사용자가 체감하는 로드 시점은 거의 차이가 없기 때문이다.

하지만 SEO 문제에 대해서는 많은 생각을 해봐야한다.

CSR방식으로 이루어진 사이트는 View를 생성하는데 자바스크립트가 필요하다. 그 전까지는 HTML의 내용은 비어있기때문에 웹 크롤러들은 내용을 알수 없고, 제대로 된 데이터를 수집할 수 없다. (Google은 자바스크립트를 해석해서 크롤링 해준다고 한다.)
SEO가 잘 되지 않는다면, 자신이 만든 웹 어플리케이션의 내용이 검색엔진에 제대로 표시되지 않고, 그만큼 사용자의 유입이 줄어들기 때문이다.

최근에는 이 두가지 방법들을 적절하게 융합한 방법들도 나온다.

첫번째 페이지 로드에는 서버사이드 렌더링을 사용하고, 그 후에 모든 페이지 로드에는 클라이언트 사이드 렌더링을 활용하는 방안이다.

특히 Isomorphic JavaScript 라는 말이 있는데 서버와 클라이언트가 같은 코드를 사용한다는 뜻으로, ReactJS가 여기 포함된다.

(ReactJS는 처음부터 서버사이드 렌더링을 염두하고 개발되었다고 한다.)

즉, ReactJS를 서버사이드렌더링을 적용한다면, 웹앱이 가지는 대부분의 단점들을 극복할수 있게 된다. (ex.SEO)

http://isomorphic.net/

REFERENCE

https://2dubbing.tistory.com/86

velog.io/@haileyself/SPA-Client-Side-Rendering-%EA%B7%B8%EB%A6%AC%EA%B3%A0-Server-Side-Rendering-90k4ar8is1

boxfoxs.tistory.com/408

velog.io/@ru_bryunak/%EB%A0%8C%EB%8D%94%EB%A7%81%EC%9D%B4%EB%9E%80

brownbears.tistory.com/411