-
브라우저 렌더링 되짚기카테고리 없음 2021. 1. 30. 20:42
1. HTML 마크업 처리 -> DOM 트리 빌드
2. CSS 마크업 처리 -> CSSOM 트리 빌드
3. DOM 및 CSSOM을 결합 -> 렌더링 트리 형성
4. 렌더링 트리에서 레이아웃을 실행하여 각 노드의 기하학적 형태 계산
5. 개별 노드를 화면에 페인팅
# 브라우저 기본 구조
1. 사용자 인터페이스: 주소 표시줄, 이전/다음 버튼, 북마크 메뉴 등. 요청한 페이지를 보여주는 창을 제외한 나머지 모든 부분
2. 브라우저 엔진: 사용자 인터페이스와 렌더링 엔진 사이의 동작을 제어
3. 렌더링 엔진*: 요청한 콘텐츠를 표시
- HTML을 요청하면 HTML과 CSS를 파싱하여 화면에 표시
4. 통신: HTTP 요청과 같은 네트워크 호출에 사용
5. UI 백엔드: 콤보 박스와 창 같은 기본적인 장치를 그림. 플랫폼에서 명시하지 않은 일반적인 인터페이스 OS 사용자 인터페이스 체계를 사용
6. 자바스크립트 해석기: 자바스크립트코드를 해석하고 실행
7. 자료 저장소: 자료를 저장하는 계층으로 쿠키를 저장하는 등의 모든 종류의 자원을 하드 디스크에 저장할 필요가 있다.
# 렌더링 엔진
파이어폭스: 모질라의 게코
사파리, 크롬: 웹킷
# 렌더링 엔진 동작 과정
1~4 단계의 점진적인 과정이라는 것을 이해하는게 중요.
렌더 트리를 빌드하고 레이아웃을 하기 전에 모든 HTML 구문이 분석 될 때까지 기다리지 않게 해야함.
콘텐츠의 일부가 구문 분석되고 표시되는 동안 네트워크에서 계속 들어오는 나머지 콘텐츠로 프로세스가 계속됩니다.
# 파싱
<html> <body> Hello world </body> </html>
파싱이 끝난 다음 동작은? 로드 이벤트 발생
# 스크립트와 스타일 시트의 진행 순서
1. 스크립트
웹은 파싱과 실행이 동시에 수행되는 동기화 모델
파서가 <script> 태그를 만나면 즉시 파싱하고 실행하기를 기대한다.
스크립트가 실행하는 동안 문서의 파싱은 중단된다.
스크립트가 외부에 있는 경우 우선 네트워크로부터 자원을 가져와야하는데 이 또한 실시간으로 처리되고 자원을 받을 때까지 파싱은 중단된다.
제작자는 스크립트를 defer로 표시할 수 있는데 지연으로 표시하게 되면 문서 파싱은 중단되지 않고 문서 파싱이 완료된 이후에 스크립트가 실행된다. HTML5는 스크립트를 비동기로 처리하는 속성을 추가했기때문에 별도의 맥락에 의해 파싱되고 실행된다.
2. 예측파싱
웹킷과 파이어폭스는 예측 파싱과 같은 최적화를 지원한다. 스크립트를 실행하는 동안 다른 스레드는 네트워크로부터 다른 자원을 찾아 내려받고 문서의 나머지 부분을 파싱한다. 이런 방법은 자원을 병렬로 연결하여 받을 수 있고 전체적인 속도를 개선한다. 참고로 예측 파서는 DOM 트리를 수정하지 않고 메인 파서의 일로 넘긴다. 예측 파서는 외부 스크립트, 외부 스타일 시트와 외부 이미지와 같이 참조된 외부 자원을 파싱할 뿐이다.
3. 스타일 시트
한편 스타일 시트는 다른 모델을 사용한다. 이론적으로 스타일 시트는 DOM 트리를 변경하지 않기 때문에 문서 파싱을 기다리거나 중단할 이유가 없다. 그러나 스크립트가 문서를 파싱하는 동안 스타일 정보를 요청하는 경우라면 문제가 된다. 스타일이 파싱되지 않은 상태라면 스크립트는 잘못된 결과를 내놓기 때문에 많은 문제를 야기한다. 이런 문제는 흔치 않은 것처럼 보이지만 매우 빈번하게 발생한다. 파이어폭스는 아직 로드 중이거나 파싱 중인 스타일 시트가 있는 경우 모든 스크립트의 실행을 중단한다. 한편 웹킷은 로드되지 않은 스타일 시트 가운데 문제가 될만한 속성이 있을 때에만 스크립트를 중단한다.
# 렌더 트리 구축
DOM 트리가 구축되는 동안 브라우저는 렌더 트리를 구축한다.표시해야 할 순서오 ㅏ문서의 시각적인 구성 요소로 올바른 순서로 내용을 그려낼 수 있또록 하기 위한 목적이다.
파이어폭스: 형상웹킷: 렌더러, 렌더 객체
# DOM 트리와 렌더 트리의 관계
렌더러는 DOM 요소에 부합하지만 1:1 관계는 아님.
# 스타일 계산
- 스타일 계산의 몇 가지 어려움:
- 스타일 데이터는 구성이 매우 광범위한데 수 많은 스타일 속성들을 수용하면서 메모리 문제를 야기할 수 있다.
-
최적화되어 있지 않다면 각 요소에 할당된 규칙을 찾는 것은 성능 문제를 야기할 수 있다. 각 요소에 할당된 규칙 목록을 전체 규칙으로부터 찾아내는 것은 과중한 일이다. 맞는 규칙을 찾는 과정은 얼핏 보기에는 약속된 방식으로 순탄하게 시작하는 것 같지만 실상 쓸모가 없거나 다른 길을 찾아야만 하는 복잡한 구조가 될 수 있다.
예를 들어 이런 복합 선택자가 있다.div div div div { … }
이 선택자는 3번째 자손<div>에 규칙을 적용한다는 뜻이다. 규칙을 적용할 <div> 요소를 확인하려면 트리로부터 임의의 줄기를 선택하고 탐색하는 과정에서 규칙에 맞지 않는 줄기를 선택했다면 또 다른 줄기를 선택해야 한다.
- 규칙을 적용하는 것은 계층 구조를 파악해야 하는 꽤나 복잡한 다단계 규칙을 수반한다.
- 스타일 정보 공유:
- 동일한 마우스 반응 상태를 가진 요소여야 한다. 예를 들어 한 요소가 :hover 상태가 될 수 없는데 다른 요소는 :hover가 될 수 있다면 동일한 마우스 상태가 아니다.
- 아이디가 없는 요소.
- 태그 이름이 일치해야 한다.
- 클래스 속성이 일치해야 한다.
- 지정된 속성이 일치해야 한다.
- 링크(link) 상태가 일치해야 한다.
- 초점(focus) 상태가 일치해야 한다.
- 문서 전체에서 속성 선택자의 영향을 받는 요소가 없어야 한다. 여기서 영향이라 함은 속성 선택자를 사용한 경우를 말한다(속성 선택자 예 input[type=text]{...})
- 요소에 인라인 스타일 속성이 없어야 한다(인라인 스타일 예 <p style="...">...</p>).
- 사용중인 형제 선택자가 없어야 한다. 웹 코어는 형제 선택자를 만나면 전역 스위치를 열고 전체 문서의 스타일 공유를 중단한다. 형제 선택자는 + 선택자와 :first-child 그리고 :last-child를 포함한다.