Portfolio

⭐

updated: 09/21

1. 브라우저란

1.1 정의

브라우저란 사용자가 선택한 자원을 서버에 요청하고, 화면에 표시하는 소프트웨어 이다.

자원은 HTML 문서, PDF, 이미지 등의 형태를 가지며, 자원의 주소는 URI에 의해 정해진다.

브라우저는 HTML과 CSS 명세에 따라서 파일을 해석하고 표시한다.

이 명세는 웹 표준화 기구 W3C에서 정한다.
+@ 브라우저의 UI는 표준을 정하지 않았지만, 서로의 장점을 모방하며 유사한 기능을 가지고 있다.

1.1 브라우저 구성 요소

1) 사용자 인터페이스

2) 브라우저 엔진

3) 렌더링 엔진

4) 통신

5) UI 백엔드

6) 자바스크립트 해석기

7) 자료 저장소

2) 브라우저 엔진은 1)사용자 인터페이스와 3)렌더링 엔진 사이의 동작을 제어 한다.

3) 렌더링 엔진은 요청한 컨텐츠를 표시한다.

HTML을 요청하면, HTML과 CSS를 파싱하여 화면에 표시하는 일
모질라에서 만들어 파이어폭스에서 사용 중인 개코(Gecko)엔진과 크롬과 사파리가 사용하는 웹킷(Webkit)엔진이 존재

+@ 크롬 브라우저는 다른 브라우저와 달리, 각 탭 마다 별도의 렌더링 엔진 인스턴스를 유지하여 독립된 프로세스로 처리된다.

2. 렌더링 엔진의 동작과정

2.1 기본 동작 과정

요청한 문서를 획득 > 1) DOM트리 구축 > 2)렌더트리 구축 > 3) 렌더트리 배치 > 4) 렌더트리 그리기

일련의 과정은 점진적으로 진행된다.
모든 HTML 파싱되기를 기다리지 않고, 먼저 배치와 그리기 과정을 시작한다.
네트워크로 부터 파일을 기다리는 동시에, 일부를 화면에 먼저 표시할 수 있다.

HTML 문서를 파싱하여, HTML의 태그를 1)DOM 노드로 변환한다.

이 때 CSS 파일과 같은 스타일 요소도 파싱한다.

DOM 트리와 CSSOM은 화면을 그리기 위한 “2)렌더트리”를 생성한다.

렌더트리는 색상 또는 면적과 같은 Box모델을 포함하고 있다.
이 Box모델은 정해진 순서에 따라 화면에 표시된다.

렌더트리 생성 이후 3)렌더트리 배치가 시작된다.

배치는 렌더트리의 각 노드(box모델)들이 화면에 표시될 위치를 지정하는 일이다.

배치가 완료되면 UI 백엔드에서 렌더트리의 노드들을 4)실제 화면에 그려낸다.

2.2 DOM 트리 구축

[2.1 파싱이란]

브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것

주로 트리 형태로 표현

‘어휘분석 + 구문분석’ 의 반복

[2.2 HTML 파싱]

HTML 파서는 HTML 마크업 문서를 파싱 트리(parse tree)로 변환

HTML은 너그러운 규칙이 적용되기 때문에 정규 파서로 파싱할 수 없다.

파싱알고리즘

‘토큰화와 트리 구축’의 반복

1)토큰화는 ‘어휘 분석’으로 입력 값을 토큰으로 파싱
2)트리 구축은 토큰화 단계에서 만들어진 토큰 값을 입력으로 받아, 알고리즘에 따라 일련의 과정을 거치며 DOM 트리를 수정(추가)한다.

3) 파싱이 종료되면 브라우저는 문서와 상호작용할 수 있게 된다.

따라서 문서 파싱 이후 실행되어야 하는 ‘지연 모드 스크립트’를 파싱하기 시작한다.
문서 상태는 ‘완료’가 되고, ‘로드’ 이벤트가 발생

[2.3 CSS 파싱]

CSS는 문맥 자유 문법이다.

파싱 결과 CSS 파일은 ‘스타일 시트 객체’로 파싱 된다.

스타일 시트의 객체는 각각 자신의 CSS 규칙을 포함한다.

CSS 규칙은 1) 선택자, 2) 선언 객체, 3)CSS 문법이 일치하는 다른 객체를 포함한다.

[2.4 스크립트 파일과 스타일 시트진행 순서]

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

스크립트 파일의 파싱 순서

문서파싱 중 <script> 태그 를 만날 경우 1) 진행되던 문서 파싱을 중단하고 2) <script>의 파싱, 다운로드, 실행이 진행된다.

이것은 파싱시간의 증가 및 예상치 못한 오류의 발생 가능성을 높인다.
해결 1) HTML5에서 <script defer> 속성을 통해, 문서 파싱 완료 이후 스크립트를 실행되도록 할 수 있다.

문서의 다운로드는 비동기적으로 바로 진행되고, 문서 파싱 이후에 스크립트가 실행된다.

스타일 시트의 파싱 순서

기본적으로 스타일 시트는 DOM 트리에 영향을 주지 않기 때문에, ’문서파싱’과 ‘CSS 파싱’은 병렬적으로 이루어질 수 있다.
단, 스크립트가 실행 중 문서의 스타일 정보를 요청하는 경우가 존재한다.

로드되지 않은 스타일 시트 중 문제가 될만한 속성이 있다면 스크립트를 중단 (웹킷)
로드 중이거나 파싱 중인 스타일 시트가 있는 경우, 모든 스크립트를 중단 (파이어폭스)

2.3 렌더트리 구축

렌더트리는 화면에 요소들을 올바른 순서로 그려내기 위한 목적을 가진다.

렌더트리의 요소는 1) 표시 순서 및 2) 문서의 시각적인 구성 요소 를 가지고 있다.

2) 문서의 시각적 구성 요소를 렌더러/렌더객체(웹킷) 혹은 형상(파이어폭스) 이라고 부른다.

[3.1 렌더객체(Render Object)]

렌더 객체는 자신과 자식요소를 어떻게 배치하고, 그려내야 하는지에 대한 정보를 가진다.

DOM node, RenderStyle, RenderLayer, layout() , paint() , repaintRect()

어떤 돔 노드에, 어떤 스타일을 가지고, 몇 번째 layer에 그려질 요소인가
배치(layout), 그리기(paint), 다시 그리기(repaint)의 동작

렌더트리에 존재하는 렌더 객체는 이후 기하학적 정보(너비, 높이 위치등)을 포함한 ‘box-model’ 로 변환되어 그려진다.

이 때, 실제로 보여질 수 있는 렌더 객체만이 렌더트리에 추가되어, box-model로 변환된다.

display:none 은 렌더트리에 담기지 않고, box-model로 변환되지 않음
visibility:hidden 은 렌더트리에 담기며, box-model로 변환됨

[DOM트리와 렌더트리의 관계]

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

display: none & visibility: hidden
select 요소는 3개의 렌더객체를 가짐 (표시영역, 드롭다운목록, 버튼)

[트리의 구축과정]

렌더트리의 최상단 요소(root)는 뷰포트(RenderView)이다.

스타일을 계산하여 결정하고, 렌더러를 만드는 과정을 어태치먼트(attachment)라고 한다. 웹킷

html태그 및 body태그가 처리되면서 렌더 트리의 최상단 요소가 생성된다.

나머지 렌더트리 요소는, DOM노드가 추가되며 생성된다.

🤨

해당 내용은 아직 온전히 이해하지 못하여, 포스팅에서 제외함

스타일 계산

[스타일 계산]

problem 스타일 계산은 ‘CSS파일이 파싱된 스타일시트, 인라인스타일 요소, HTML의 시각적 속성등’을 모두 고려해야하고, 이에 따라 복잡한 처리 및 성능/메모리 문제를 발생시킨다.

solution

1) 스타일 정보의 공유

노드가 형제/사촌일 경우 공유
공유 조건

2) 자식으로의 속성 상속 (구조체 분리)

특정 구조안에서의 속성은 상속 받는다.
reset 속성을 통한 사용여부 관리
선, 색상 , 글자크기 등

3) 규칙트리 사용

스타일 객체는 전체 또는 일부를 공유

4) 선택자 규칙 적용

클래스맵 & 아이디맵 & 태그 맵 활용

2.4 렌더트리 배치

배치란 렌더러가 생성되어 트리에 추가될 때, 크기와 위치 정보는 없는데 이런 값을 계산하는 것을 배치 또는 리플로라고 부른다.

즉 리플로(reflow)단계는 렌더 객체의 기하학적인 정보(크기,위치)를 계산하는 단계

[ HTML 은 흐름 기반의 배치모델 ]

단일 경로를 통해 크기와 위치정보를 계산한다는 것

나중에 등장한 요소가, 앞서 등장한 요소의 위치와 크기에 영향을 미치지 않는다는 것을 의미

배치는 왼쪽에서 오른쪽, 위쪽에서 아래로 흐름
표와 같이 예외도 존재 (자식요소가 상위요소의 크기에 영향을 미침)

모든 렌더객체는 layout() 메서드를 가지고, 메서드 실행 시 자식의 layout 메소드를 실행한다.

[더티 비트체계]

소소한 변경을 위해 전체를 다시 배치하지 않기 위해 사용하는 체제

다시 배치할 필요가 있는 변경요소 및 추가된 요소와 자식들을 ‘더티’라고 표시한다

자신의 배치가 필요할 경우 ‘더티’ 플래그
자식 중 하나라도 다시 배치가 필요할 경우 ‘자식 더티’ 플래그

[전역배치와 점증배치]

전역배치는 1) 전역스타일 변경과 2) 화면 크기 변경 에서 발생

전역스타일 변경은 글꼴 크기 변경과 같이 모든 렌더러에 영향을 미치는 속성의 변경

점증배치는 오직 더티 렌더객체와 그 자식 객체들이 배치되는 것을 의미

렌더러가 ‘더티’상태 일 때 비동기적으로 발생
네트워크 요청으로 부터 받은 추가 내용으로 DOM 트리의 변화가 발생할 경우, 새로운 렌더러가 렌더트리에 붙으면서 발생하는 경우

전역배치는 보통 동기적으로 실행

점증배치는 비동기적으로 실행된다.

점증배치를 위해 리플로(reflow)명령을 쌓아놓고, 타이머에 따라 한 번에 실행
혹은 네트워크로 부터 자원을 받은 이후, DOM 트리 추가 직후 배치

[최적화]

배치가 “크기 변경” 혹은 “렌더러 위치 변화” 로 실행되는 경우 렌더러의 크기는 다시 계산하지 않고 캐시로 부터 가져옴

input태그의 텍스트를 입력하는 경우

변화 범위가 한정적이고, 주변에 영향을 미치지 않기 때문에, 하위트리만 배치가 발생

[배치과정]

1) 부모 렌더러가 자신의 너비를 결정 (width)

2) 부모가 자식을 검토

자식 렌더러의 배치(x,y 좌표 결정)
더티 상태, 전역 배치 상태인 경우, 자식의 배치를 호출하여 높이를 계산

3) 자식의 누적된 높이,여백, 패딩을 계산하여 자신의 높이를 설정 (height)

4) 더티 비트 플래그를 제거

2.5 렌더트리 그리기

그리기 단계에서는 1) 화면에 내용을 표시하기 위한 렌더 트리가 탐색되고 2) 렌더러의 "paint" 메서드가 호출된다.

[그리기 순서 ]

쌓임맥락 (stacking contexts)라고도 함

block 속성을 가진 렌더객체는 다음과 같이 그려진다.

아웃라인 > 자식> 테두리 > 배경 이미지 > 배경 색,

[ 리페인트(repaint) ]

웹킷의 경우, 리페인팅 전의 사각형들을 비트맵으로 저장한다.

리페인팅이 발생했을 때, 새로운 사각형과 비교하여 차이가 있는 부분만을 다시 그린다.

파이어폭스는 사각형을 위한 적적할 렌더러를 포함하여 한 번에 그려낸다.

여러번 리페인팅 하지 않고, 한 번의 탐색을 거쳐 배경색, 배경이미지, 테두리 등을 그린다.

[동적변경 - 리플로우와 리페인팅]

리페인트 발생 조건

특정 요소의 색깔만 바뀔 경우, 해당 요소만 리페인팅 발생

리플로우 발생 조건

요소의 위치만 변경될 경우, 1) 해당 요소와 2) 자식, 3)형제 렌더 객체에서 리플로우 및 리페인팅이 발생

2.6 위치 결정 방법

🤨

해당 내용은 아직 온전히 이해하지 못하여, 포스팅에서 제외함 - 위치 결정은 언제 되는건지? 페인트단계에 고려되며 그려지는 것인가?

[위치 결정 방법]

위치는 3가지 방법에 따라 결정된다.

Normal : DOM트리와 자리가 같아, 박스유형과 크기에 따라 배치됨

position: static(기본값), position : relative

Float : Normal로 배치 후, 왼쪽/오른쪽으로 흐르며 배치

float: right | left

Absolute : 기존 DOM 트리의 렌더트리와는 다른 별도의 렌더트리에 놓임

position: absolute | fixed , top, bottom, left, right

참고

Main 참조 (브라우저는 어떻게 동작하는가)

NAVER D2

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

CSS 그리기 순서

[CSS] Stacking context

3개의 div 에 span 으로 각각 bg color 를 적용하였고, position 은 absolute 입니다. red 는 z-index가 1입니다. 나머지는 없습니다. 여기서 아래 조건을 지키면서 red를 green 과 blue 뒤로 보내보세요. z-index 는 아주 간단해 보입니다. 높은 z-index를 가지고 있는 element 는 낮은 것보다...

https://dongmin-jang.medium.com/css-stacking-context-172f9bd1af8b

브라우저 렌더링