浏览器工作原理与实践pdf_现代浏览器工作原理 part3

现代浏览器工作原理 - part1

现代浏览器工作原理 - part2

最近看到几篇浏览器工作原理的文章，写的非常好，决定与朋友们分享下，由于原文需要 FQ，故对原文进行重新排版，搬到公众号方便学习。本文来源：

https://developers.google.com/web/updates/2018/09/inside-browser-part3

Inner workings of a Renderer Process

This is part 3 of 4 part blog series looking at how browsers work. Previously, we covered multi-process architecture and navigation flow. In this post, we are going to look at what happens inside of the renderer process.

Renderer process touches many aspects of web performance. Since there is a lot happening inside of the renderer process, this post is only a general overview. If you'd like to dig deeper, the Performance section of Web Fundamentals has many more resources.

Renderer processes handle web contents

The renderer process is responsible for everything that happens inside of a tab. In a renderer process, the main thread handles most of the code you send to the user. Sometimes parts of your JavaScript is handled by worker threads if you use a web worker or a service worker. Compositor and raster threads are also run inside of a renderer processes to render a page efficiently and smoothly.

The renderer process's core job is to turn HTML, CSS, and JavaScript into a web page that the user can interact with.

Figure 1: Renderer process with a main thread, worker threads, a compositor thread, and a raster thread inside

Parsing

Construction of a DOM

When the renderer process receives a commit message for a navigation and starts to receive HTML data, the main thread begins to parse the text string (HTML) and turn it into a Document Object Model (DOM).

The DOM is a browser's internal representation of the page as well as the data structure and API that web developer can interact with via JavaScript.

Parsing an HTML document into a DOM is defined by the HTML Standard. You may have noticed that feeding HTML to a browser never throws an error. For example, missing closing

tag is a valid HTML. Erroneous markup like Hi! I'm Chrome! (b tag is closed before i tag) is treated as if you wrote Hi! I'm Chrome !. This is because the HTML specification is designed to handle those errors gracefully. If you are curious how these things are done, you can read on "An introduction to error handling and strange cases in the parser" section of the HTML spec.

Subresource loading

A website usually uses external resources like images, CSS, and JavaScript. Those files need to be loaded from network or cache. The main thread could request them one by one as they find them while parsing to build a DOM, but in order to speed up, "preload scanner" is run concurrently. If there are things like or in the HTML document, preload scanner peeks at tokens generated by HTML parser and sends requests to the network thread in the browser process.

Figure 2: The main thread parsing HTML and building a DOM tree

JavaScript can block the parsing

When the HTML parser finds a