브라우저 렌더링 - 이도영

브라우저 렌더링 

브라우저 렌더링이란?

웹페이지를 HTML, CSS, JS 등의 웹 리소스를 파싱하고 처리, 렌더링을 통해 브라우저를 유저들에게 시각적으로 보여주는 과정이다.

 

브라우저 렌더링 방법

1. CSR(Client Side Rendering)

클라이언트 영역에서 렌더링을 수행하는 방식이다.사용자가 웹브라우저를 통해서 웹사이트에 방문 했을 때 웹사이트에서 제공하는 웹페이지에 대한 HTML, CSS, JavaScript와 같은 리소스들을 클라이언트 단에서 다운로드 받고 브라우저에서 페이지 전환을 처리하여 보여주는 방식이다.

CSR rendering 방식에서 서버의 역할은 페이지가 그려질 때 웹리소스 파일을 제공하는 역할과 페이지가 모두 로딩이 되었을 때 클라이언트에서 요청하는 데이터를 전송해주는 역할을 수행한다.

CSR이 작동되는 원리를 좀 더 자세하게 설명하자면,  사용자가 웹페이지를 열면 서버에서 해당 페이지에 대한 HTML파일을 보내주고 브라우저에서 HTML파일을 받아서 동적으로 구성해주며 서버에서 보내주는 초기 HTML파일에는 정보가 거의 없는 형태이다. 해당 HTML파일에는 스크랩트 태그에 자바스크립트 파일만 링크되어 있고, 화면을 실제 구성하는 요소들은 없다.

 

그래서 서버로부터 처음 HTML파일을 받아왔을 때 해당 HTML 파일 만으로는 빈 화면만 그려진다. 서버로부터 HTML파일을 받아온 다음, 웹 사이트 화면을 구성하는데 필요한 추가적인 데이터들을 서버에서 다시 다운로드 받게 된다. 여기서 필요한 추가적인 데이터가 CCS, JS 같은 파일들이며, HTML파일에 링크로 연결되어 있던 자바스크립트 파일과 CSS파일, 데이터를 받아온다. 서버에서 웹페이지에서 렌더링 하기 위해서 필요한 모든 파일에 대해서 다운로드가 왼료되면 다운로드 받은 데이터를 활용하여 브라우저에서 직접 동적으로 HTML을 생성하고 웹 페이지 화면에 보여주는 순서로 작동한다.

 

CSR 방식은 서버에서 빈 HTML 파일을 제공하고, 브라우저에서 HTML을 동적으로 구성한다. 

CSR 방식은 페이지 요청 -> HTML 다운로드 ->  CSS, JS 파일 다운로드 -> HTML 구성하는 순서로 진행된다.

CSR 방식은 웹페이지가 처음 로딩 될 때만 서버에서 파일을 받아오고 이후에는 서버를 거치지 않고 브라우저에서 동적으로 렌더링하기 때문에 초기에 로딩 될 때만 속도가 느리고, 그 외에는 속도가 빠르다. 사용자가 사용하는 과정에서 발생하는 동작에 의해서 페이지 상의 변화가 생겨도 요청하는 부분이 없기 때문에 성능 측면에서 장점이 있다. 페이지가 빠르게 만들어지기 때문에 빠른 사용자 경험을 제공할 수 있다. 여기서 리액트의 렌더링이 빠른데 그 이유가 있다. virtual DOM이라는 것 때문이다. 

 

virtual DOM이란 

1. 내용이 바뀌어 업데이트된 DOM을 새로운 사본으로 만든 뒤, 그 사본에 업데이트된 항목을 표시한다.
2. 사본과 기존의 DOM을 비교하면서 달라진 점이 없는지 확인한다.
3. DOM의 바뀐 부분이 있다면 그 부분만 브라우저가 새로 그린다.

 

단점 : 처음에 HTML과 자바스크립트 파일이 모두 다운로드 되어야지만 웹페이지가 웹 브라우저에 그려져서 표현되기 때문에 처음 화면 로딩 속도에서 걸리는 단점이 있다. 그리고 빈 HTML파일을 받아온 상태에서 브라우저에서 동작하여 HTML을 구성하기 때문에 SEO측면에서 불리한 부분이 있다.

 

SEO란 검색 엔진 최적화(Search Engine Optimization)의 약자로 웹사이트나 웹페이지를 검색 엔진 결과에서 높은 순서로 노출 시키기 위한 다양한 기법과 전략을 사용하는 프로세스다.

 

2. SSR(Server Side Rendering)

서버에서 렌더링 과정을 수행하는 개념이다. 사용자가 웹페이지에 방문을 해서 접속하면 서버로 해당 페이지에 대한 요청이 진행되고, 서버에서는 필요한 HTML, CSS, JS를 이용해서 페이지를 서버에서 렌더링 한 후 브라우저에 보내주게 된다. SSR 방식은 서버에서 완전한 HTML파일 직접 만들어서 제공한다.

사용자가 웹 사이트에서 방문해서 페이지를 접속하게 되면 페이지가 요청되고 서버로부터 완전 HTML 파일을 다운로드 받아서 화면에 페이지를 바로 띄어서 보여준 다음에 웹페이지를 동적으로 작동하고 제어하기 위해 필요한 자바스크립트 파일을 서버로부터 다운로드 받게 된다. 자바스크립트 파일까지 다운로드가 완료되면 웹페이지를 동적으로 제어할 수 있게 된다. 이후 페이지에 대해서 변경 사항이 있거나 다시 새로운 페이지로 접속했을 때 서버에서는 렌더링 과정을 수행한 다음 웹 사이트 화면을 브라우저를 통해 웹 페이지를 그려준다.

 

SSR방식은 페이지 요청 -> HTML 다운로드 -> 자바스크립트 다운로드 순서로 진행된다.

SSR방식은 웹 페이지 요청이 발생할 때 서버에서 완성된 형태의 HTML파일을 보내주고 이를 브라우저 상에서 표현하는 것이기 때문에 첫 화면 로딩 속도가 상대적으로 빠르다. 서버에서는 HTML파일을 만들고 그 파일 안에는 웹페이지 내용까지 담겨져 있기 때문에 SEO측면에서는 유리하다.

 

하지만 해당 방식은 화면에 변화가 생길 때마다 서버에서 HTML파일을 보내주고 다시 화면을 그리기 때문에 화면 전환을 할 때 깜빡임(Blinking)현상이 발생하는 문제가 있다. 화면의 전환이 있을 때마다 서버에 요청해서 받아오기 때문에 만약 방문수가 많고, 사용량이 많은 웹사이트일 경우에는 서버 과부하도 예상할 수 있다.

 

브라우저 렌더링 원리

브라우저가 HTML, CSS, JS로 작성한 문서를 어떻게 파싱하고 렌더링하는지 보여드리겠습니다.

 

파싱이란 ?

프로그래밍 언어의 문법에 맞게 작성된 텍스트 문서를 읽고 실행하기 위해 텍스트 문자의 문자열을 분해하고 구조를 생성하는 일련의 과정

1. HTML 파싱

브라우저는 HTML 문서를 파싱하여 문서 구조를 이해하고 DOM트리를 생성함

2. CSS 파싱

브라우저는 CSS 스타일 시트를 파싱하여 각 요소에 적용될 스타일 규칙을 계산함

 

렌더링이란?

HTML, CSS, JS로 작성된 문서를 파싱하여 브라우저에 시각적으로 출력하는 것

 

1. 불러오기
로더(Loader)가 서버로부터 전달받은 리소스 스트림을 읽는 과정

 

2. DOM, CSSOM 생성
웹 엔진의 HTML/XML 파서가 문서를 파싱해 DOM Tree를, CSS 파서가 CSSOM 트리를 생성

 

3. 생성된 DOM과 CSSOM으로 렌더링 트리 생성(Render Tree)
DOM Tree + CSSOM Tree, 렌더링에 필요한 노드만 선택해 페이지를 렌더링하는데 사용

 

4. CSS, 레이아웃(Layout)
렌더트리를 토대로 그려질 노드와 스타일, 크기를 계산
렌더링 트리에서 위치, 크기등을 알 수 없기 때문에 객체들에게 위치,크기 등을 정해주는 과정

CSS는 선택자에 따라서 적용되는 태그가 다르기 때문에 모든 CSS 스타일을 분석해 태그에 스타일 규칙이 적용되게 함

 

5. 그리기(paint)
렌더트리의 각 노드를 실제 픽셀로 변환 ➡️ 실제로 그리는 작업을 실행

 

자바스크립트가 DOM, CSSOM을 변경하는 경우에는 리렌더링

리플로우: 레이아웃 계사늘 다시 하는 것

리페인트: 재결합된 렌더 트리를 기반으로 다시 페인트하는 것

 

브라우저의 기본 구조

1. 사용자 인터페이스
주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분

 

2. 브라우저 엔진
사용자 인터페이스와 렌더링 엔진 사이 동작을 제어

 

3. 렌더링 엔진
요청한 콘텐츠를 표시 (ex, HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시)

 

4. 통신
HTTP/HTTPS 요청과 같은 네트워크 호출에 사용(이것은 플랫폼 독립적인 인터페이스이고 각 플랫폼 하부에서 실행됨)

 

5. UI 백엔드
콤보 박스와 창 같은 기본적인 장치를 그림. 플랫폼에서 명시하지 않은 일반적인 인터페이스로서, OS 사용자 인터페이스 체계를 사용

 

6. 자바스크립트 해석기
자바스크립트 코드를 해석하고 실행

 

7. 자료 저장소
자료를 저장하는 계층. 쿠키를 저장하는 것과 같이 모든 종류의 자원을 하드 디스크에 저장할 필요가 있다. HTML5 명세에는 브라우저가 지원하는 '웹 데이터 베이스'가 정의되어 있음

➡️ 크롬은 대부분의 브라우저와 달리 각 탭마다 별도의 렌더링 엔진 인스턴스를 유지

여기서 렌더링 엔진이 요청받은 내용을 브라우저 화면에 표시하는 일을 수행

스크립트와 스타일 시트의 진행 순서

스크립트

웹은 파싱과 실행이 동시에 수행되는 동기화(synchronous) 모델

스크립트가 실행되는 동안 문서(HTML)의 파싱은 중단 ➡️ script 태그를 만나면 코드 실행을 위해 DOM 생성 프로세스 중단

스크립트가 외부에 있는 경우 우선 네트워크로부터 자원을 가져와야 하는데 이 또한 실시간으로 처리되고 자원을 받을 때까지 파싱은 중단 됨

스크립트를 "지연(defer)" 으로 표시할 수 있는데 지연으로 표시하게 되면 문서 파싱은 중단되지 않고 문서 파싱이 완료된 이후에 스크립트가 실행됨 ➡️ 즉, HTML 구문 분석이 완료되면 스크립트 파일이 실행

HTML5는 스크립트를 비동기(asynchronous)로 처리하는 속성을 추가했기 때문에 별도의 맥락에 의해 파싱되고 실행

 

"async" 도 자주 사용하지는 않지만 사용하기도 한다. 이것은 defer랑 같은 원리이지만 함수를 비동기적 동작으로 처리해준다.

스타일 시트

이론적으로 스타일 시트는 DOM 트리를 변경하지 않기 때문에 문서 파싱을 기다리거나 중단할 이유가 없음

그러나 스크립트가 문서를 파싱하는 동안 스타일 정보를 요청하는 경우라면 문제
➡️ 스타일이 파싱되지 않은 상태라면 스크립트는 잘못된 결과를 내놓기 때문에 많은 문제를 야기함

이런 문제는 흔치 않은 것처럼 보이지만 매우 빈번하게 발생한다고 한다.
(파이어폭스는 아직 로드 중이거나 파싱 중인 스타일 시트가 있는 경우 모든 스크립트의 실행을 중단한다. 한편 웹킷은 로드되지 않은 스타일 시트 가운데 문제가 될만한 속성이 있을 때에만 스크립트를 중단한다)