브라우저의 기본 구조


  1. 사용자 인터페이스 : 주소표시줄, 이전/다음 버튼, 북마크 메뉴 등 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분
  2. 브라우저 엔진 : 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어합니다.
  3. 렌더링 엔진 : 요청한 콘텐츠를 표시. ex) HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시합니다.
  4. 통신 : HTTP요청과같은 네트워크 호출에 사용됩니다.
  5. UI 백엔드 : 콤보박스와 창같은 기본적인 장치를 그림.
  6. 자바스크립트 해석기 : 자바스크립트 코드를 해석하고 실행합니다.
  7. 자료 저장소 : 자료를 저장하는 계층입니다.

브라우저의 주요 구성 요소


렌더링엔진


렌더링엔진의 주역할은 요청받은 내용을 브라우저 화면에 표시 하는 일입니다.

렌더링엔진은 통신으로부터 요청한 문서의 내용을 얻는것으로 시작하는데 문서의 내용은 보통 8kb단위로 전송됩니다.

렌더링 엔진의 기본적인 동작과정은 다음과 같습니다.

  1. DOM트리 구축을위한 HTML파싱
  2. 렌더 트리 구축
  3. 렌더 트리 배치
  4. 렌더 트리 그리기

렌더링 엔진은 HTML문서를 파싱하고, “콘텐츠 트리” 내부에서 태그를 DOM노드로 변환합니다.

그 다음, 외부 CSS파일과 함께 포함된 스타일 요소도 파싱합니다.

스타일 정보와 HTML표시 규칙은 “렌더 트리”라고 부르는 또 다른 트리를 생성합니다.

렌더 트리는 색상이나 면적같은 시각적 속성이 있는 사각형을 포함하고 있으며 정해진 순서대로 화면에 표시됩니다.

이 다음에 각 노드가 화면의 정확한 위치에 표시되도록 배치가 시작됩니다.

그 다음엔 그리기 과정이 시작됩니다.

렌더링 엔진은 좀 더 나은 사용자경험 을 위해서 모든 HTML을 파싱할때까지 기다리지않고 배치와 그리기과정을 시작합니다.

네트워크로부터 나머지 내용이 전송되기를 기다림과 동시에 받은 내용의 일부를 화면에 먼저 표시하는 것입니다!


파싱과 DOM트리 구축


문서 파싱은 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것을 의미합니다.

파싱의 결과는 보통 문서구조를 나타내는 노드 트리입니다.

이것을 파싱트리, 또는 문법트리라고 부릅니다.


HTML파서


HTML파서는 HTML마크업을 파싱트리로 변환합니다.


CSS파싱


CSS파싱


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


웹은 파싱과 실행이 동시에 수행되는 동기화모델입니다.

파서가 script태그를 만나면 즉시 파싱하고 실행하려고 합니다.

그리고 스크립트가 실행되는 동안에는 문서의 파싱은 중단되죠.

스크립트가 외부에 있는 경우엔, 네트워크로부터 자원을 가져와야하는데 이때에도 자원을 받을때까지 파싱은 중단됩니다.


렌더 트리 구축


DOM트리가 구축되는 동안 브라우저는 렌더트리를 구축한다고 합니다.

표시해야할 순서와 문서의 시각적인 구성요소로써 올바른 순서대로 내용을 그려낼 수 있도록 하는 행위입니다.

이러한 구성요소를 “렌더러”라고 하는데요.

렌더러는 자신과 자식요소를 어떻게 배치하고 그려내야하는지 알고있습니다.

각 렌더러는 CSS명세에따라서 노드의 CSS박스에 부합하는 사각형을 표시합니다.

그리고 렌더러는 높이, 너비, 위치와같은 기하학적 정보를 포함하고 있습니다.

이러한 박스 유형은 노드와 관련된 “display”스타일 속성의 영향을 받습니다!(오오.. 이렇게 멋진 역할을 하던 녀석이었네요;)


DOM트리와 렌더 트리의 관계


렌더러는 DOM요소에 부합하지만 1:1로 대응하는 관계는 아니라고합니다.

예를들어 head요소와 같은 비시각적 DOM요소는 렌더 트리에 추가되지 않습니다.

그리고 위에서 살펴본 display속성에 ‘none’값이 할당된 요소또한 렌더 트리에 나타나지 않습니다.

(여기서 잠깐! visibility 속성에 ‘hidden’값이 할당된 요소는 트리에 나타납니다!)


트리를 구축하는 과정


html태그와 body태그를 처리함으로써 렌더 트리 루트를 구성하게됩니다.

트리의 나머지 부분은 DOM노드를 추가함으로써 점차 완성되어갑니다!


스타일계산


렌더 트리를 구축하려면 각 렌더 객체의 시각적 속성에대한 계산또한 필요하겠죠?

이것은 각 요소의 스타일 속성을 계산함으로써 처리됩니다.


배치


렌더러가 생성되어 트리에 추가될때 크기와 위치에대한 정보는 없습니다.

이런 값을 계산하는 행위를 배치 또는 리플로 라고 합니다!

HTML은 “흐름 기반의 배치 모델”을 사용한다고합니다.

단일 경로를 통해 크기와 위치정보를 계산할 수 있다는 소리인데요(어렵네여..)

쉽게 풀어보면, “흐름에 따르면”, 나중에 등장하는 요소는 앞에서 등장한 요소의 위치와 크기에는 영향을 미칠 수 없기 때문에 배치는 왼쪽에서 오른쪽으로, 또는 위에서 아래로 흐른다는 의미라고합니다.

배치는 HTML문서의 html요소에 해당하는 최상위 렌더러에서부터 시작됩니다.

최상위 렌더러의 위치는 좌표계 0,0이며 브라우저 창의 보이는 영역에 해당하는 뷰포트만큼의 면적을 갖습니다.

배치는 일반적으로 다음과같은 형태로 진행됩니다.

  1. 부모 렌더러가 자신의 너비를 결정
  2. 부모가 자식을 검토
    1. 자식 렌더러를 배치(자식의 좌표 x, y를 설정)
  3. 부모는 자식의 누적된 높이와 여백, 패딩을 사용하여 자신의 높이를 설정


그리기


그리기단계에서는 화면에 내용을 표시하기위한 렌더 트리가 탐색됩니다.

그리기의 순서는 다음과 같습니다.

  1. 배경색
  2. 배경이미지
  3. 테두리
  4. 자식
  5. 아웃라인


동적변경


브라우저는 굉장히 효율적으로 일을 하려고합니다.

따라서 변경에대해 가능한 한 최소한의 동작으로 반응하려고 노력합니다.

그렇기때문에 요소의 색깔이 바뀌면 해당 요소의 리페인팅만 발생합니다.

요소의 위치가 바뀌면 요소의 자식, 그리고 형제의 리페인팅과 재배치가 발생합니다.

DOM노드를 추가하면 노드의 리페인팅과 재배치가 발생합니다.

따라서, html요소의 글꼴크기를 변경하는것과같은 큰 변경은 캐시를 무효화하고 트리 전체의 배치와 리페인팅을 발생시킵니다.


렌더링 엔진의 스레드


렌더링 엔진은 통신을 제외한 거의 모든 경우에 단일 스레드로 동작합니다.

(통신의 경우에는 보통 2개~6개의 병렬 스레드에의해 진행될 수 있습니다.)


즐겨찾기해두고… 항상 안읽었던글을 이제서야 읽었습니다..

바닷물에 발가락 하나 담근 기분이네요.

시간이 흘러서 보면 더 잘 이해할 수 있겠죠!?


자료출처 :

https://d2.naver.com/helloworld/59361