HTML 문서(그림 및 텍스트)를 브라우저에서 구문 분석하고 렌더링하는 과정에 대한 자세한 설명

이 문서는 HTML 문서의 브라우저 구문 분석 및 렌더링 과정에 대한 자세한 설명(그림 및 텍스트)을 제공합니다. 필요한 친구가 참조할 수 있기를 바랍니다.

브라우저 작동 방식

1. 브라우저의 상위 구조

브라우저의 주요 구성 요소는 다음과 같습니다.

1. 사용자 인터페이스 - 주소 표시줄, 앞으로/뒤로 버튼, 북마크 메뉴 등 기본 브라우저 창에 표시되는 요청한 페이지 외에도 디스플레이의 다른 모든 부분은 사용자 인터페이스에 속합니다.

2. 브라우저 엔진 - 사용자 인터페이스와 렌더링 엔진 간에 지침을 전송합니다.

3. 프레젠테이션 엔진 - 요청된 콘텐츠를 표시하는 역할을 담당합니다. 요청한 콘텐츠가 HTML인 경우 HTML과 CSS 콘텐츠를 파싱하고 파싱된 콘텐츠를 화면에 표시하는 역할을 담당합니다.

4. 네트워크 - HTTP 요청과 같은 네트워크 호출에 사용됩니다. 해당 인터페이스는 플랫폼 독립적이며 모든 플랫폼에 대한 기본 구현을 제공합니다.

5. 사용자 인터페이스 백엔드 - 콤보 상자 및 창과 같은 기본 위젯을 그리는 데 사용됩니다. 이는 내부적으로 운영 체제의 사용자 인터페이스 방법을 사용하면서 플랫폼 독립적인 공통 인터페이스를 노출합니다.

6. 자바스크립트 인터프리터. JavaScript 코드를 구문 분석하고 실행하는 데 사용됩니다.

7. 데이터 저장. 이것이 지속성 레이어입니다. 브라우저는 쿠키 등 다양한 데이터를 하드 드라이브에 저장해야 합니다. 새로운 HTML 사양(HTML5)은 완전한(그러나 가벼운) 브라우저 내 데이터베이스인 "웹 데이터베이스"를 정의합니다.

대부분의 브라우저와 달리 Chrome 브라우저의 각 탭은 렌더링 엔진 인스턴스에 해당한다는 점은 주목할 가치가 있습니다. 각 탭은 독립적인 프로세스입니다.

2. 주요 프로세스

렌더링 엔진은 처음에 네트워크 계층에서 요청된 문서의 콘텐츠를 가져옵니다. 콘텐츠의 크기는 일반적으로 8000블록으로 제한됩니다.

그러면 기본 프로세스는 다음과 같습니다.

렌더링 엔진은 HTML 문서를 구문 분석하고 각 태그를 "콘텐츠 트리"의 DOM 노드로 하나씩 변환하기 시작합니다. 외부 CSS 파일 및 스타일 요소의 스타일 데이터도 구문 분석됩니다. HTML의 시각적 지침이 포함된 이 스타일 정보는 렌더링 트리라는 또 다른 트리 구조를 만드는 데 사용됩니다.

렌더링 트리에는 색상 및 크기와 같은 시각적 속성을 가진 여러 직사각형이 포함되어 있습니다. 이 직사각형이 배열된 순서는 화면에 나타나는 순서입니다.

프리젠테이션 트리가 구축되면 "레이아웃" 처리 단계로 들어갑니다. 이는 각 노드에 화면에 표시되어야 하는 정확한 좌표를 할당하는 것을 의미합니다. 다음 단계는 그리기입니다. 렌더링 엔진은 렌더링 트리를 탐색하고 사용자 인터페이스 백엔드 레이어는 각 노드를 그립니다.

이것은 점진적인 과정이라는 점을 강조해야 합니다. 더 나은 사용자 경험을 달성하기 위해 렌더링 엔진은 가능한 한 빨리 콘텐츠를 화면에 표시하려고 노력합니다. 렌더링 트리 구축 및 레이아웃 설정을 시작하기 전에 전체 HTML 문서가 구문 분석될 때까지 기다릴 필요가 없습니다. 렌더링 엔진은 네트워크에서 나머지 콘텐츠를 지속적으로 수신하고 처리하는 동안 콘텐츠의 일부를 구문 분석하고 표시합니다.

주요 프로세스 예:

3. 스크립트 및 스타일 시트 처리 순서

1. Script

네트워크 모델이 동기화됩니다. 웹 페이지 작성자는 <script> 태그를 발견하면 파서가 스크립트를 즉시 구문 분석하고 실행하기를 원합니다. 스크립트 실행이 완료될 때까지 문서 구문 분석이 중지됩니다. 스크립트가 외부인 경우 계속하기 전에 네트워크에서 리소스를 동기식으로 가져올 때까지 구문 분석 프로세스가 중지됩니다. 이 모델은 수년 동안 사용되었으며 HTML4 및 HTML5 사양에도 지정되어 있습니다. 작성자는 스크립트를 "지연"으로 표시하여 문서 구문 분석을 중지하지 않고 구문 분석이 완료될 때까지 기다렸다가 실행하도록 할 수도 있습니다. HTML5에는 스크립트를 비동기로 표시하여 다른 스레드에서 구문 분석하고 실행할 수 있는 옵션이 추가되었습니다. </script>

2. 사전 구문 분석

WebKit과 Firefox는 모두 이 최적화를 구현했습니다. 스크립트가 실행되는 동안 다른 스레드는 문서의 나머지 부분을 구문 분석하여 네트워크를 통해 로드해야 하는 추가 리소스를 찾아 로드합니다. 이러한 방식으로 리소스를 병렬 연결에 로드하여 전체 속도를 높일 수 있습니다. 준비기는 DOM 트리를 수정하지 않지만 이 작업을 기본 파서에 맡깁니다. 준비기는 외부 리소스(예: 외부 스크립트, 스타일시트, 이미지)에 대한 참조만 구문 분석합니다.

3. 스타일시트

반면에 스타일 시트는 다른 모델을 가지고 있습니다. 이론적으로는 스타일시트를 적용해도 DOM 트리가 변경되지 않으므로 스타일시트를 기다리거나 문서 구문 분석을 중지할 필요는 없을 것 같습니다. 그러나 여기에는 문제가 있습니다. 즉, 스크립트가 문서 구문 분석 단계에서 스타일 정보를 요청한다는 것입니다. 해당 시점에 스타일이 로드 및 구문 분석되지 않은 경우 스크립트는 잘못된 응답을 받게 되며 이는 분명히 많은 문제를 야기합니다. 이것은 비정형적인 경우처럼 보일 수 있지만 실제로는 매우 일반적입니다. Firefox는 스타일 시트를 로드하고 구문 분석하는 동안 모든 스크립트를 비활성화합니다. 반면 WebKit은 아직 로드되지 않은 스타일 시트의 영향을 받을 수 있는 스타일 속성에 액세스하려고 시도하는 경우에만 스크립트를 차단합니다.

4. 프리젠테이션 트리 구축

DOM 트리가 구축되는 동안 브라우저는 또 다른 트리 구조인 프리젠테이션 트리도 구축합니다. 이는 나타나는 순서대로의 시각적 요소 트리이며 문서를 시각적으로 표현한 것입니다. 그것이 하는 일은 올바른 순서로 사물을 그릴 수 있게 해주는 것입니다.

Firefox는 렌더링 트리의 요소를 "프레임"이라고 부릅니다. WebKit이 사용하는 용어는 렌더러 또는 렌더링 객체입니다.
렌더러는 자신과 자식을 배치하고 그리는 방법을 알고 있습니다.

4. 레이아웃

렌더러가 생성되어 렌더링 트리에 추가되면 위치 및 크기 정보가 포함되지 않습니다. 이러한 값을 계산하는 과정을 레이아웃 또는 재배열이라고 합니다.

HTML은 흐름 기반 레이아웃 모델을 사용합니다. 즉, 대부분의 경우 기하학적 정보를 단 한 번의 패스로 계산할 수 있습니다. 흐름의 뒷부분에 있는 요소는 일반적으로 흐름의 앞부분에 있는 요소의 기하학적 구조에 영향을 주지 않으므로 레이아웃은 문서를 왼쪽에서 오른쪽으로, 위에서 아래로 이동할 수 있습니다. 그러나 둘 이상의 패스가 필요한 HTML 테이블 계산과 같은 예외가 있습니다.

좌표계는 상단 및 왼쪽 좌표를 사용하여 루트 프레임을 기준으로 설정됩니다.

레이아웃은 재귀적인 프로세스입니다. 이는 루트 렌더러(HTML 문서의 요소에 해당)에서 시작한 다음 프레임 계층 구조의 일부 또는 전체를 반복적으로 탐색하여 계산해야 하는 각 렌더러에 대한 기하학 정보를 계산합니다.

루트 렌더러의 위치는 왼쪽이 0,0이고 크기는 뷰포트(즉, 브라우저 창의 보이는 영역)입니다.
모든 렌더러에는 "레이아웃" 또는 "리플로우" 메서드가 있습니다. 각 렌더러는 레이아웃해야 하는 하위 항목의 레이아웃 메서드를 호출합니다.

5. 드로잉

드로잉 단계에서 시스템은 렌더링 트리를 순회하고 렌더러의 "paint" 메서드를 호출하여 렌더러의 내용을 화면에 표시합니다. 그리기 작업은 사용자 인터페이스의 기본 구성 요소를 사용하여 수행됩니다.

개인 이해 요약

1. 파서 및 사전 파싱 메커니즘

렌더링 엔진은 네트워크 계층에서 요청한 문서의 내용을 얻은 다음 HTML 문서를 파싱하기 시작하고 각 태그를 하나씩 변환합니다. DOM 트리(컨텐츠 트리) 의 DOM 노드는 외부 CSS 파일과 스타일 요소의 스타일 데이터도 구문 분석합니다. HTML의 시각적 지시문이 포함된 이 스타일 정보는 또 다른 트리 구조인 렌더 트리(렌더 트리) 를 만드는 데 사용됩니다. 프리젠테이션 트리가 구축된 후 프리젠테이션 엔진은 프리젠테이션 트리를 배치하고 그립니다.

프레젠테이션 엔진의 구문 분석에는 HTML 구문 분석과 CSS 구문 분석이 포함됩니다. HTML 구문 분석기의 출력 "분석 트리"는 DOM 요소와 속성 노드로 구성된 트리 구조입니다. 이는 HTML 문서의 객체 표현이자 외부 콘텐츠(예: JavaScript)와 HTML 요소 간의 인터페이스입니다. 구문 분석 트리의 루트 노드는 "문서" 개체입니다. CSS 파서는 CSS 스타일 파일과 스타일 요소의 스타일 데이터를 CSS 규칙 트리로 구문 분석하고, 브라우저는 CSS 규칙 트리와 DOM 트리를 결합하여 렌더링 트리를 생성합니다.

JavaScript Interpreter는 JavaScript 코드를 구문 분석하고 실행하는 데 사용됩니다.

일반적으로 우리는 브라우저가 네트워크 계층에서 HTML 문서 콘텐츠를 받은 다음 문서를 구문 분석하여 DOM 트리를 생성한다고 생각합니다. CSS 스타일 시트 태그나 JS 스크립트 태그를 만나면 새 스레드가 시작됩니다. 이를 다운로드하고 계속해서 DOM 트리를 구축하면 브라우저는 DOM 트리를 기반으로 렌더링 트리를 구축하고 마지막으로 브라우저는 렌더링 북을 사용자 인터페이스에 그립니다.

위 설명에서 HTML 문서의 구문 분석 및 렌더링은 점진적인 과정이라는 점을 지적하는 것이 중요합니다. 더 나은 사용자 경험을 달성하기 위해 렌더링 엔진은 가능한 한 빨리 콘텐츠를 화면에 표시하려고 노력합니다. 렌더링 트리 구축 및 레이아웃 설정을 시작하기 전에 전체 HTML 문서가 구문 분석될 때까지 기다릴 필요가 없습니다. 렌더링 엔진은 네트워크에서 나머지 콘텐츠를 계속 수신하고 처리하는 동안 콘텐츠의 일부를 구문 분석하고 표시합니다.

브라우저 사전 구문 분석. WebKit과 Firefox 모두 이 최적화를 구현합니다. 스크립트가 실행되는 동안 다른 스레드는 HTML 문서의 나머지 부분을 구문 분석하여 네트워크를 통해 로드해야 하는 추가 리소스를 식별하고 로드합니다. 이러한 방식으로 리소스를 병렬 연결에 로드하여 전체 속도를 높일 수 있습니다. 준비기는 DOM 트리를 수정하지 않고 이 작업을 기본 파서에게 맡깁니다. 준비기는 외부 리소스(예: 외부 스크립트, 스타일시트, 이미지)에 대한 참조만 구문 분석합니다.

브라우저의 사전 구문 분석으로 인해 렌더링 차단 속도가 느려질 수 있습니다. 예를 들어 프리로더가 문서 구문 분석 중에 <script src="last.js"></script> 태그를 발견하면 last.js 파일을 로드하여 브라우저 캐시에 배치하므로 구문 분석기가 이를 발견할 때 <script>가 표시되어 있습니다. 프리로더가 이미 last.js 파일을 로드했기 때문에 네트워크에서 리소스를 가져올 때까지 기다리지 않고 즉시 last.js가 실행되므로 렌더링 차단 속도가 느려집니다. </script>

2. CSS 및 JS의 처리 순서 및 차단 분석

HTML 문서의 구문 분석 및 렌더링 프로세스 중에 외부 스타일 시트 및 스크립트 가 순차적으로 실행되고 동시에 로드됩니다.

JS 스크립트는 DOM 트리 구성 및 렌더링 트리 구성을 포함한 HTML 문서의 구문 분석을 차단합니다. CSS 스타일 시트는 렌더링 트리 구성을 차단하지만 DOM 트리는 계속 구성됩니다. (스크립트 태그가 발견되고 CSS 파일이 아직 로드되지 않은 경우 제외) 페이지에 렌더링되지 않습니다.

HTML 문서의 구문 분석 과정에서 파서는 <script> 태그를 발견하면 즉시 스크립트를 구문 분석하고 실행합니다. 스크립트가 실행될 때까지 HTML 문서의 구문 분석이 차단됩니다. 스크립트가 외부인 경우 네트워크에서 리소스를 가져와서 구문 분석하고 실행할 때까지 구문 분석 프로세스가 중지되고 이후 내용이 구문 분석됩니다. </script>

이론적으로 스타일시트를 적용해도 DOM 트리가 변경되지 않으므로 스타일시트를 기다리거나 문서 구문 분석을 중지할 필요는 없을 것 같습니다. 그러나 여기에는 문제가 있습니다. 즉, 스크립트가 문서 구문 분석 단계에서 스타일 정보를 요청한다는 것입니다. 해당 시점에 스타일이 로드 및 구문 분석되지 않은 경우 스크립트는 잘못된 응답을 받게 되며 이는 분명히 많은 문제를 야기합니다. 이것은 비정형적인 경우처럼 보일 수 있지만 실제로는 매우 일반적입니다. Firefox는 스타일 시트를 로드하고 구문 분석하는 동안 모든 스크립트를 비활성화합니다. 반면 WebKit은 아직 로드되지 않은 스타일 시트의 영향을 받을 수 있는 스타일 속성에 액세스하려고 시도하는 경우에만 스크립트를 차단합니다.

그러나 어떤 상황에서 차단이 발생하더라도 로드할 외부 리소스(예: 외부 스크립트, 스타일 시트, 이미지)는 계속 로드됩니다. HTML 문서의 구문 분석은 차단될 수 있지만 외부 리소스 로딩은 차단되지 않습니다.

CSS 외부 스타일 시트를 로드하면 외부 스크립트 실행이 차단되지만 외부 스크립트 로드는 차단되지 않습니다. 이는 크롬 디버깅 도구의 Network - Waterfall을 통해 확인할 수 있지만 크롬의 최대 동시 연결(동일 도메인 이름) 수는 6개라는 점에 유의해야 합니다.

위의 두 스크린샷에서 볼 수 있듯이 jquery.min.js 스크립트 파일은 bootstrap.css와 같은 스타일 파일과 병렬로 로드됩니다. 그러나 Chrome에서는 동시 최대 6개까지 허용됩니다. 연결, bootstrap.min .js 스크립트 및 xxx.css 스타일과 같은 파일 로드는 이전 파일이 로드될 때까지 기다린 다음 사용 가능한 연결이 있을 때 로드를 시작합니다.

위 정보를 이해한 후 CSS 파일 압축, CDN 사용, 여러 도메인 이름으로 리소스 배포, CSS 파일 병합, HTTP 요청 수 줄이기 등 그에 따라 페이지를 최적화할 수 있습니다. 로딩 개선 CSS 속도를 높이고 HTML 문서 구문 분석 및 렌더링의 차단 시간을 줄입니다.

브라우저는 HTTP 1에서 원본당 6개의 TCP 연결만 허용합니다.

동시 요청 수에 대한 브라우저의 제한은 동일한 도메인 이름에 대한 것입니다. 따라서 CDN 가속 기술을 사용하면 웹 사이트에 접속하는 사용자의 응답 속도를 향상시켜 CDN을 사용한 리소스 로딩이 현재 도메인 이름에서 동시 연결 수를 차지하지 않아 차단 시간을 줄일 수 있습니다.

웹페이지 성능

HTML 문서를 구문 분석하고 렌더링하는 과정을 이해하는 것은 웹페이지 성능에 영향을 미치는 핵심 요소를 찾는 데 매우 중요합니다. 예를 들어, JS 외부 스크립트를 실행하면 문서 구문 분석이 차단되고, 무거운 타사 플러그인이 홈페이지 로딩 속도에 영향을 미칠 수 있다는 것을 알고 있습니다. 이것이 사용자 경험에 영향을 미치는 경우 비용을 고려해야 합니다. 이 타사 플러그인을 사용하는 비율이 너무 높습니다. 다른 경량 플러그인을 대신 사용할 수 있습니까? 아니면 일부 모듈만 사용할 수 있습니다.

데이터 테이블을 예로 들어 보겠습니다.

위 그림은 프로젝트 페이지의 네트워크 스크린샷입니다. 빨간색 상자 안의 부분이 페이지가 로드될 때 왜 발생하는지 알아야 합니다. 이 단락 유휴 시간에 브라우저는 무엇을 하고 있나요?

이 기간 동안의 브라우저의 구체적인 정보를 알아보기 위해 타임라인 그래프를 분석하면 다음과 같습니다.

타임라인 차트를 보면 250ms~900ms의 시간 간격 내에서 브라우저가 datatables.min.js 스크립트 코드를 실행하고 있는 것을 확인할 수 있습니다. 이 스크립트를 실행하면 문서의 파싱이 차단되고 약 700ms가 소요됩니다. , 이는 그림의 네트워크 공백에 해당합니다.

우리는 계속해서 페이지를 완료하는 데 걸리는 총 시간을 살펴보고 700ms의 영향을 다음과 같이 평가합니다.

페이지를 완료하는 데 걸리는 총 시간은 1.66초이며, 이는 datatables.min.js의 실행 시간 소모가 큰 부분을 차지합니다. 이 플러그인을 사용해야 하는지, 다른 경량 플러그인을 사용하여 교체할 수 있는지, 불필요한 모듈을 간소화할 수 있는지 신중하게 고려해야 합니다. 플러그인을 삭제하거나 플러그인 사용을 포기하세요.

References-1
브라우저는 완전한 문서 또는 덩어리일 수 있는 html 코드를 수신하고 구문 분석을 시작합니다. 구문 분석 프로세스는 먼저 DOM 트리를 구축한 다음 DOM 트리를 기반으로 렌더링 트리를 구축하고 마지막으로 브라우저가 렌더링 트리를 페이지에 그리는 것입니다.
dom 트리를 구축하는 과정은 html 코드를 기반으로 위에서 아래로 구축하는 것입니다. 스크립트 파일이 로드/실행되면 이후의 dom 트리 구성이 차단됩니다(javascript가 dom 트리를 변경할 수 있음). CSS 파일이 발견되면 렌더링이 차단됩니다. 즉, DOM 트리는 계속해서 생성되지만(스크립트 태그가 발견되고 CSS 파일이 여전히 로드되지 않은 경우) 페이지에 렌더링되거나 그려지지 않습니다. 어느 것이 차단되더라도 HTML 문서의 다른 css/js/image 파일과 같이 로드된 파일은 계속 로드됩니다.
또한 자바스크립트는 로드된 후 실행되며 실행 프로세스도 트리 구성을 차단합니다. 실행 후 다른 콘텐츠를 로드하는 것이 아니라 실행이 완료된 후 다른 콘텐츠를 구문 분석합니다.

저자: Jiabing
링크: https://www.zhihu.com/questio...

Reference-2
우선, 오픈 소스 브라우저는 일반적으로 블록당 8k로 html 페이지를 다운로드합니다.
그런 다음 페이지를 구문 분석하여 CSS 태그 또는 JS 스크립트 태그가 나타나면 새 스레드를 시작하여 이를 다운로드하고 계속해서 DOM을 구축하세요.
다운로드 후 CSS는 CSS 규칙 트리로 구문 분석되고, 브라우저는 CSS 규칙 트리와 DOM 트리를 결합하여 렌더 트리를 생성합니다.
참고: CSSOM(CSS 개체 모델)을 구축하면 JavaScript 실행이 차단됩니다. JavaScript를 실행하면 DOM 구성도 차단됩니다.
JavaScript를 다운로드한 후 DOM API를 통해 DOM을 수정하고 CSSOM API를 통해 스타일 범위 렌더 트리를 수정할 수 있습니다.
수정할 때마다 렌더 트리가 다시 레이아웃되고 다시 그려집니다. DOM이 수정되거나 요소의 모양이나 크기가 수정되는 한 Reflow가 트리거됩니다. 단순히 요소의 색상을 수정하려면 Repaint(운영 체제 Native GUI의 API를 호출하여 그려야 함)만 필요합니다.

저자: Chen Jin
링크: https://www.zhihu.com/questio...

이 기사는 여기서 끝났습니다. 더 흥미로운 내용을 보려면 PHP 중국어 웹사이트의 JavaScript 비디오를 시청하세요. 튜토리얼 칼럼!

위 내용은 HTML 문서(그림 및 텍스트)를 브라우저에서 구문 분석하고 렌더링하는 과정에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!