인수
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 참조 (브라우저는 어떻게 동작하는가)
- CSS 그리기 순서
![[CSS] Stacking context](https://www.notion.so/image/https%3A%2F%2Fmiro.medium.com%2F1*m-R_BkNf1Qjr1YbyOIJY2w.png?table=block&id=2a6e0f3c-21fe-4947-ab8d-00b6006c32e6&cache=v2)
![[CSS] Stacking context](https://www.notion.so/image/https%3A%2F%2Fmiro.medium.com%2Fmax%2F1200%2F1*VozAopQ214m5_J8DjC8Eyg.jpeg?table=block&id=2a6e0f3c-21fe-4947-ab8d-00b6006c32e6&cache=v2)
창민
HTML 파싱 중단 시점에 대한 의문점
렌더링 엔진은 DOM을 생성해 나가다가 CSS를 로드하는 link 태그나 style 태그를 만나면 DOM 생성을 일시 중단한다. - 모던 자바스크립트 Deep Dive
위 글에서 이해한 바로는 “HTML 파싱을 직접적으로 멈추지는 않는다”라고 합니다
조금 더 설명하자면,
- 외부 스타일시트를 불러오는 과정에서는 파싱을 멈추지 않는다
- 내부 style 태그를 만나는 경우에는 CSSOM 트리를 생성을 마치고 다시 HTML 파싱을 이어간다
대부분의 글에서도 CSS는 렌더링을 차단하는 것이지 HTML 파싱을 차단하지는 않는다고 합니다
“CRP가 차단된다”와 “파싱이 중단된다”를 구분할 필요가 있을 것 같아요
“CSS 파일이 로드되는 과정에서 HTML 파싱을 멈춘다” 에 대한 여러분의 생각이 궁금해요
아래에 각자의 지식? 생각? 을 적어주시면 감사합니다
[ 수경 ]
[ 인수 ]
- 말 그대로 HTML 파싱 과정 중 CSS Link 혹은 script 태그(async, defer가 없는) 를 만나면, HTML 파싱과정이 블로킹된다.
- HTML 파싱과정이 블로킹된다는 것은 ‘파싱’과 ‘렌더링’ 과정 모두를 차단(block)하는 것을 의미
- CSS 파일 로딩 및 처리 이후, HTML 파서는 CSS Link 다음 문서들을 ‘파싱’하기 시작하고 렌더링 역시 진행된다.
- 수정
- 요거 찬찬히 읽어보고, 다시 생각해볼게요.
- 이 글에서
- 이 부분이 제일 헷갈리네요..
Now the Render Tree nodes generated with older CSSOM will be repainted with new styles and it could also lead to Flash of Unstyled Content (FOUC) which is is very bad for UX. Hence browsers will wait until the stylesheet is loaded and parsed.
But 최신 브라우저는 '프리로드 스캐너'를 가지고 있어 !
- 참고
[ 준혁 ]
참고 자료
브라우저하면 가장 유명한 네이버의 그 글
개인적인 소감으로 아직도 이해하기 어려워요..
누군가가 브라우저 렌더링을 물어본다면? 위 글이 딱 적당한 것 같아요
![[10분 테코톡] ☕️ 체프의 브라우저 렌더링](https://www.notion.so/image/https%3A%2F%2Fwww.google.com%2Ffavicon.ico?table=block&id=513cf634-239b-4c3a-8b5b-2b8c2084fd8c&cache=v2)
![[10분 테코톡] ☕️ 체프의 브라우저 렌더링](https://www.notion.so/image/https%3A%2F%2Fi.ytimg.com%2Fvi%2FsJ14cWjrNis%2Fhqdefault.jpg?table=block&id=513cf634-239b-4c3a-8b5b-2b8c2084fd8c&cache=v2)
브라우저 렌더링 발표 영상인데 이 분도 핵심과 함께 최적화까지 직접 보여주시면서 좋은 영상이라고 생각합니다
이 글도 👍
준혁
velog 트렌드에 해당 주제에 관련하여 글들을 보게 되었다. 이 글들을 보면서 이전의 글이 너무 빈약했던 것도 있고, 정리는 했는데 제대로 이해하지 못한 것 같아 다시 한번 흐름에 맞게 정리를 해 보려고 한다.
브라우저 검색창에 URL을 검색하면 어떤 과정을 통해 우리에게 보여주는 것일까?
TL;DR
브라우저의 검색창에 검색을 하게 되면, 크게 다음의 세 과정을 통해 우리에게 전달된다.
- URL 검증 및 네임 서버 탐색
- 네트워크 요청
- 렌더링
URL 검증 및 네임 서버 탐색
우선 브라우저 검색 창에 검색을 한 문자열이 URL인지, 아니면 단순 검색어인지 확인하는 작업을 거쳐야 한다. (최신 브라우저들은 검색 바와 검색엔진이 연결되어 있기 때문이다.)
- 만약 문자열이 URL의 형태를 띄고 있지 않다면, 연결된 검색 엔진의 결과를 보여준다.
- 만약 문자열이 URL이라면, 네임(DNS)서버에서 해당 도메인과 연결된 IP를 검색한다.
URL일 경우
만약 이전에 캐싱된 DNS 기록이 있다면, DNS 서버에 해당 도메인에 연결된 IP를 요청하지 않고 캐싱된 IP를 반환한다.
네트워크를 호출한다.
- DNS: 도메인 이름 시스템을 의미하며, 기본적으로 웹에서 도메인을 정리하고 확인하는 전화번호부와 같은 역할을 한다.
네트워크 호출
네트워크 호출은 크게 세 단계로 이루어진다.
- TCP/IP 연결 시도
- 데이터 전송
- TCP/IP 세션 종료
TCP(transmission control protocol)은 데이터의 전송을 제어하고, 어떻게 보낼 지, 어떻게 맞출 지 정하게 된다.
IP Protocol만으로 통신을 할 수 없는 이유는, IP 프로토콜은 비신뢰성, 비연결성의 특징을 갖고 있기 때문에 데이터를 전달하기에는 부적합하다. 그렇기 때문에 신뢰성과 연결성의 특징을 갖는 TCP 프로토콜을 이용하여 통신을 진행한다.
TCP/IP 연결 시도
클라이언트와 서버간 3 way handshake 과정을 통해 연결을 초기화한다.
- 클라이언트가 서버에 접속을 요청하는 SYN(synchronize sequence number) 패킷을 보낸다.
- 서버가 패킷을 받으면, 다시 클라이언트로 접속을 수락하는 패킷인 ACK(Acknowlegement) 패킷을 보낸다. 이때 SYN flag와 함께 클라이언트로 발송한다.
- 클라이언트가 서버에 ACK 패킷을 발송하고, 연결이 이루어진다. 이 시점부터 데이터 교환이 이루어진다.
데이터 전송
현재 글에서 데이터 전송이란, 브라우저에 웹 사이트를 띄우기 위한 html, css javascript 등의 데이터를 의미한다.
TCP/IP 세션 종료
모든 데이터 송신이 끝났으면, 세션을 종료한다.
세션 종료는 4 way handshake로 이루어진다.
- 클라이언트가 연결을 종료하겠다는 FIN 패킷을 전송한다. (
- 서버는 확인 메시지를 보내고(ACK), 자신의 통신이 끝날 때까지 기다린다(CLOSE_WAIT). 클라이언트는 서버로부터 FIN 패킷을 받을 때 까지 기다리는 (FIN_WAIT)상태가 된다.
- 서버가 통신이 끝났으면 FIN 플래그를 클라이언트에 전송한다.
- 클라이언트는 확인했다고 ACK 플래그를 서버에 보낸다.
- 패킷: 정보 기술에서 패킷 방식의 컴퓨터 네트워크가 전달하는 데이터의 형식화된 블록
렌더링
이제 브라우저가 웹 페이지를 띄우기 위한 데이터는 클라이언트에게 전달된 상태다. 그러나 데이터를 전달받았다고 해서, 바로 브라우저가 웹 페이지를 사용자에게 보여줄 수 있는 것은 아니다. 렌더링과정을 거쳐야만 비로소 사용자가 볼 수 있는 웹 페이지가 만들어진다.
렌더링 과정은 브라우저 엔진에서 진행하는 것이 아닌, 브라우저의 렌더링 엔진에서 모든 과정을 수행하며, 모든 과정을 수행한 뒤 페이지를 띄워주면 모든 과정이 완료되었다는 신호를 브라우저 엔진에게 보낸다. 이 이벤트가 ‘load’ 이벤트이다.
파싱
서버로부터 전송된 데이터는 바이트코드로 이루어진 텍스트 형식이다. 그러나 브라우저는 이를 읽을 수 없으므로, 파싱이라는 과정을 통해 브라우저가 읽을 수 있는 형식으로 변환하여야 한다.
파싱은 두 단계로 나눌 수 있다.
- 어휘 분석: 문자열을 의미 있는 작은 단위인 토큰으로 분해하는 작업
- 구문 분석: 분해한 토큰을 바탕으로 파싱 트리를 만드는 작업
html, css, JavaScript 모두 파싱이 진행된다.
html 파싱
렌더링 엔진이 html 문서를 전달 받으면, html 파서는 위에서부터 읽어들여 파싱을 진행하고, 최종적으로 DOM Tree를 구성하게 된다.
- 서버로부터 바이트 형식의 html 문서를 전달받는다.
- 지정된 인코딩 방식에 따라 이를 문자열로 변환한다.
- 변환한 문자열을 토큰으로 분해한다.
- 토큰을 바탕으로 노드(객체)를 생성한다.
- 객체를 트리 구조로 구성하여 DOM Tree를 만든다.
이 때, 렌더링 엔진은 html이 전부 파싱이 끝날 때까지 기다리지 않고, 파싱이 완료된 순서대로 파싱 이후의 과정인 배치 과정과 그리기 과정을 미리 진행한다.
css 파싱
html을 파싱하면서
<link> 태그를 만나게 되면, 브라우저는 DOM 생성을 중지하고 css 파싱을 진행한다.최종 결과물은 CSSOM Tree를 구성하게 되며, 그 과정은 html 파싱 과정과 동일하다. (물론 어휘를 분석하고 구문을 분석하는 방식은 html과 는 약간 다르다.)
CSSOM Tree 노드는 DOM 요소의 선택자에 맞춰 적용될 CSS 스타일 정보가 포함된다.
JavaScript 파싱
html을 파싱하면서
<script> 태그를 만나게 되면, 브라우저는 DOM 생성을 중지하고 자바스크립트 서버에서 해당 JavaScript 리소스를 브라우저 엔진으로부터 받아온다. 그리고 JavaScript 엔진에 제어권을 넘겨준다.JavaScript 엔진은 JS 리소스를 파싱하여 추상 구문 트리를 만들고, 이를 바이트 코드로 변환하여 실행된다.
JavaScript가 실행되는 동안은 DOM 생성이 중지되므로,
<body> 중간에 <script> 태그를 작성한다면, DOM이 완전히 생성되지 않은 상태에서 DOM 조작이 이루어질 수 있기 때문에 에러가 발생할 위험이 있다. 그래서 일반적으로 <script> 태그는 <body> 태그의 가장 아래 부분에 배치하는 것이 일반적이다.
물론,
<script async>, <script defer> 옵션을 통해서 DOM 생성이 블로킹 되는 것을 방지할 수 있다.- async:
- 백그라운드에서 JavaScript 코드를 다운로드한다.
- 다운로드가 완료되면 DOM 생성을 중지하고, 다운로드받은 JavaScript 코드를 실행한다.
- 작성 순서대로 실행을 보장하지 않는다.
- defer:
- 백그라운드에서 JavaScript 코드를 다운로드한다. 그리고 DOM 생성이 끝날 때까지 실행이 지연된다.
- defer 옵션 스크립트 태그가 여러개 있어도, 작성한 순서대로 실행되는 것을 보장한다.
Render Tree 구성
DOM Tree와 CSSOM Tree가 모두 구성이 끝나면, 이를 결합하여 렌더 트리를 형성한다.
- html 태그와 body 태그를 처리하여 렌더 트리 root를 구성한다.
- 이 때, 실제 보여지지 않는 태그들은 렌더 트리에서 제외한다.
- 화면에 보여지는 나머지 노드들에 CSSOM 규칙들을 찾아 스타일을 적용한다.
배치하기 (Layout)
렌더트리의 각 노드의 위치와 크기를 계산하고, 이를 화면에 배치하는 작업을 말한다.
항상 루트에서부터 계산을 시작하며, x, y 좌표를 사용한다.
그리기 (Paint)
계산된 위치와 크기를 바탕으로 DOM을 화면에 그린다. (실제 픽셀로 변환한다)
특정 위치에 여러 개의 노드가 함께 그려지는 경우, 여러 레이어를 만들고 이를 다시 합성하는 방식으로 작업이 이루어진다.
페인트 과정이 끝나면 우리가 보는 웹사이트가 나타난다.
재배치 (Reflow)
그러나 아직 끝난게 아니다! 화면을 리사이즈 하거나, 특정 이벤트에 따라서 DOM의 크기 또는 위치가 바뀔 수 있는데, 이를 반영해 주어야 한다. 이를 Reflow라고 하며, 실제로 비용이 많이 드는 과정이다.
다시 그리기 (Repaint)
reflow 과정에 따라 화면에 다시 반영하는 repaint 과정이 진행된다. reflow가 일어나야만 repaint 과정이 일어나는 것은 아니며, 경우에 따라 repaint 과정만 일어나는 경우도 있다.
레이아웃에는 영향을 주지 않지만, 다시 그려야하는
visibility, background-color 등이 포함된다.
![[ 네트워크 쉽게 이해하기 22편 ] TCP 3 Way-Handshake & 4 Way-Handshake](https://www.notion.so/image/https%3A%2F%2Ft1.daumcdn.net%2Ftistory_admin%2Fstatic%2Ftop%2Ffavicon_0630.ico?table=block&id=0e4ff385-2a43-4df5-a199-cf7223fc419b&cache=v2)
![[ 네트워크 쉽게 이해하기 22편 ] TCP 3 Way-Handshake & 4 Way-Handshake](https://www.notion.so/image/https%3A%2F%2Fimg1.daumcdn.net%2Fthumb%2FR800x0%2F%3Fscode%3Dmtistory2%26fname%3Dhttps%253A%252F%252Ft1.daumcdn.net%252Fcfile%252Ftistory%252F225A964D52F1BB6917?table=block&id=0e4ff385-2a43-4df5-a199-cf7223fc419b&cache=v2)
