How browsers Work

    1. Browser internals

    • 1. User interface – including address bar, forward/back button, bookmark menu, etc. All parts of the display belong to the user interface, except for the page you requested displayed in the browser’s main window.

    • 2. Browser engine – Passes instructions between the user interface and the rendering engine.

    • 3. Rendering engine – Responsible for displaying the requested content. If the requested content is HTML, it is responsible for parsing the HTML and CSS content and displaying the parsed content on the screen.

    • Network – Used for network calls, such as HTTP requests. Its interfaces are platform independent and provide an underlying implementation for all platforms.

    • 5. User interface back end – Used to draw basic widgets such as combo boxes and Windows. It exposes a common interface that is platform-independent, while underneath it uses the operating system’s user interface approach.

    • JavaScript interpreter. Used to parse and execute JavaScript code.

    • 7. Data storage. This is the persistence layer. Browsers need to keep all kinds of data, such as cookies, on their hard drives. The new HTML specification (HTML5) defines a “web database,” which is a complete (but lightweight) in-browser database.

    1. Browser processes

    • 2.1 Processes and Threads

      • Process: A process is a running instance of a program. When a program is started, the operating system creates a block of memory for the program, which is used to store code, running data and a main thread to perform tasks. We call such a running environment a process.

      • Thread: The smallest unit of program execution

      • The relationship between process and thread: thread is attached to the process, and the use of multi-thread parallel processing in the process can improve the computing efficiency \

      • Process and thread features:

        • Relevance:

          • A task in the thread reported an error, blocking the execution of subsequent tasks

          • The failure of any thread in the process will cause the entire process to crash.

          • A program has multiple processes, and the crash of one does not affect the others.

        • When a process is shut down, the operating system reclaims the memory occupied by the process.

        • Data sharing: Sharing between threads The contents of data processes in a process are isolated from each other.

    • 2.2 Browser Processes

      • Modern browsers are multi-process and each TAB is an independent renderer, such as writing an endless loop where only the current page crashes

      • Browser process: mainly responsible for interface display, user interaction, sub-process management, and storage.

      • Render process: The core task is to turn HTML, CSS, and JavaScript into web pages that users can interact with. Both the typography engine Blink and JavaScript engine V8 run in this process. By default, Chrome creates a rendering process for each Tab Tab.

      • GPU process: Actually, Chrome didn’t have a GPU process when it was first released. The original intention of using GPU was to achieve 3D CSS effect, but later the UI interface of web page and Chrome were drawn on GPU, which made GPU become a common requirement of browser. Finally, Chrome has introduced GPU processes on top of its multi-process architecture.

      • Web process: responsible for loading web resources on a page. It used to run as a module in the browser process until recently, when it became a separate process.

      • Plug-in process. It is mainly responsible for the running of plug-ins. Plug-ins are prone to crash. Therefore, plug-ins need to be isolated through the plug-in process to ensure that the plug-in process crash does not affect the browser and page

    1. Rendering process

    • The core job of a rendering process is to turn HTML,CSS, and JavaScript into a web page that users can interact with. It mainly includes the following threads:

    • 3.1 Browser GUI rendering thread

      • 3.1.1 Rendering process

      • The purpose of layering: avoid rendering the whole page, divide the page into multiple layers, especially for animation, separate the animation into one layer, render only the layer ok, transform, Z-index, etc., the browser will automatically optimize the generated layer

      • Rasterization: If the page is long but the viewable area is small, to avoid wasting resources by rendering non-viewable styles, divide each layer into smaller grids and currently render only areas near the viewable area

    • 2.1.2 rearrangement

      • Rearrangement: When a DOM change affects the geometry of an element (its position and size), the browser needs to recalculate the element’s geometry and place it in the correct position in the interface, a process called rearrangement

      • Rearrangement features: All processes after style are updated

      • Method that triggers a rearrangement

        • Page initial rendering, which is the most expensive rearrangement

        • Add/remove visible DOM elements

        • Change element position

        • Change element dimensions, such as margins, padding, borders, width, and height

        • Change the content of the element, such as the number of words, image size, etc

        • Change the element font size

        • Change the browser window size, such as when the resize event occurs

        • Activate CSS pseudo-classes (such as: :hover)

        • Set the value of the style property, because changing the node style by setting the style property triggers a reflow every time

        • Query some properties or call some calculation methods: offsetWidth, offsetHeight, etc

    • 2.1.3 redraw

      • Redraw: The process of redrawing the appearance of an element when its appearance has been changed without changing its layout

      • Redraw features: Skip layout and layering stages

      • Rearrangements must be redrawn

    • 2.1.4 Methods to avoid rearrangement

      • Style set changes

      • Use absolute or fixed to exit the document flow

      • Using absolute positioning makes the element a separate child of the body in the rendering tree, with low rearrangement overhead and not much impact on other nodes. When you place this element on these nodes, some other nodes in the region may need to be redrawn, but not rearranged

      • GPU acceleration: the transform

    • 2.2 JavaScript Engine threads

      • The JS engine thread is responsible for parsing Javascript scripts, running the code, waiting for tasks to arrive in the task queue, and then processing them. At any time in a Tab page (renderer process) there is only one JS thread running the JS program

      • The GUI rendering thread and the JS engine thread are mutually exclusive, so if the JS execution time is too long, the page rendering will be incoherent and the page rendering load will block

    • 2.3 Timing trigger Thread of the Browser

      • The browser timing counter is not counted by the JavaScript engine, because the JavaScript engine is single-threaded. If the JavaScript engine is blocked, the timing accuracy will be affected. Therefore, it is more reasonable to use a separate thread to time and trigger the timing

    • 2.4 Browser events trigger threads

      • When an event is triggered, the thread adds the event to the end of the queue, waiting for the JavaScript engine to process it. These events can be currently executing code blocks such as scheduled tasks, or other threads from the browser kernel such as mouse clicks, AJAX asynchronous requests, etc., but due to the single-threaded nature of JavaScript all of these events have to be queued up for the JavaScript engine to process.

    • 2.5 Browser HTTP asynchronous request thread

      • If a callback function is set, the asynchronous thread generates the state change event and places it in the JavaScript engine’s processing queue to wait for processing when the XMLHttpRequest is detected after the connection by opening a new thread through the browser.