Unlock Browser Rendering: Deep Dive into WebKit, Chromium & Performance

0. Introduction

After publishing the previous article "Website Performance Optimization: From 12.67s to 1.06s", I realized that my coverage of page rendering performance was still incomplete. To clarify the browser's rendering mechanism and help readers understand the deeper principles of rendering optimization, I revisited the book WebKit Technical Insider and share my notes here.

Feel free to follow my GitHub for updates: https://github.com/jerryOnlyZRJ .

1. Browser Engine

Below is the relationship diagram of the browser rendering engine, HTML interpreter, and JS interpreter mentioned in the previous article:

The user interface you see in a browser is the UI layer. The term "browser engine" usually refers to the rendering engine. The most famous ones are WebKit (used by Safari) and its predecessor Blink (used by Chrome). Most mobile products (Android, iOS, etc.) use WebKit‑based engines, which is why we can implement CSS animations and JS interactions on mobile web and hybrid apps. Blink is a fork of WebKit that pairs with the V8 JS engine. Other engines include IE's Trident and Firefox's Gecko. Different engines require vendor prefixes for CSS due to varying rendering mechanisms.

The rendering engine contains an HTML parser, a CSS style parser, and a JS interpreter. The JS interpreter has become a separate component (e.g., V8) because JavaScript’s role has grown.

2. Browser Architecture

Before digging into the internals, you need to know that modern browsers use a multi‑process, multi‑thread model. Using Chromium (Blink‑based) as an example, the common processes are:

Browser process: the main process responsible for the UI and managing pages. Closing this process exits the browser.

Renderer process: handles page rendering; typically one renderer per page.

GPU process: created only when hardware acceleration is enabled, and at most one exists.

These processes share the following characteristics:

The Browser process and page rendering are separated, preventing a page crash from crashing the UI.

Each page runs in an isolated process, so pages do not affect each other.

The GPU process is also isolated.

For a visual example, here is a screenshot of Chrome’s multi‑process view on Windows (open Task Manager, sort by "Command line", locate "Google Chrome" entries):

The process without a "type" parameter is the Browser (main) process.

Each process contains many threads. The UI thread (main thread in the Browser process) remains responsive because heavy work is offloaded to other threads. JavaScript execution also occurs in its own thread, which is why JS is considered single‑threaded.

3. Overview of HTML Structure and Rendering Mechanism

Before understanding the rendering mechanism, you must grasp the browser’s layer hierarchy. Rendering occurs in multiple compositing layers, not a single flat layer. The process resembles a layered cake: resources are parsed, styles are computed, layout is performed, painting happens, and finally layers are composited.

If you open Chrome DevTools → Performance, record a short session, and switch to the Event Log view, you can see the sequence: style calculation → layer tree update → painting → compositing.

The rendering process can be divided into three stages:

Stage 1 – Resource loading and script execution: large portions of time are spent on network loading (blue) and scripting (yellow).

Stage 2 – Layout: the purple "Rendering" segment corresponds to layout work. Enabling hardware acceleration can reduce layout‑related reflows.

Stage 3 – Paint and Composite: final drawing and compositing of layers.

4. DOM Tree and Event Mechanism

When a page is requested, the byte stream is parsed into an HTML document, then transformed into a DOM tree. The root of the DOM tree is the

document

object, and each HTML tag becomes an element node.

Event handling in the browser consists of two phases: event capture (top‑down) and event bubbling (bottom‑up). The

addEventListener()

method accepts a third Boolean argument

useCapture

. When

true

, the listener runs during the capture phase; when

false

(default), it runs during bubbling.

5. Construction of RenderObject and RenderLayer

Not all DOM nodes are visual. Nodes like

head

or

script

are non‑visual. Visual nodes (e.g.,

body

,

div

) are turned into

RenderObject

instances by WebKit, which store style and layout information needed for painting.

WebKit then creates

RenderLayer

objects for certain nodes to reduce repaint cost. A

RenderLayer

may correspond to one or many

RenderObject

s. Layers are created when:

the document node creates a

RenderView

the HTML node creates a

RenderBlock

an element has

position:absolute

or

fixed

an element has opacity

an element uses CSS 3D transforms

the element is a

canvas

or

video

tag

Using layers reduces the complexity of the render tree and can lower repaint costs. The following diagram illustrates the construction process:

The final result is stored in WebKit’s internal data structures (illustrated by the next diagram).

Each "layer at (x, x)" line represents a distinct

RenderLayer

, and the listed

RenderObject

s belong to that layer.

6. Browser Rendering Methods

Browsers render either via software (CPU) or hardware (GPU). Software rendering produces a bitmap; when a region changes, WebKit recomputes only the affected area and repaints the intersecting

RenderObject

s. This is essentially a CPU cache mechanism.

Hardware rendering offloads drawing to the GPU, creating compositing layers that the GPU can transform without triggering full re‑layout or repaint.

7. In‑Depth Look at Hardware Rendering

When a

RenderLayer

meets certain criteria, WebKit groups it into a compositing layer cached on the GPU. If a layer does not form its own compositing layer, it inherits its parent’s layer, ultimately falling back to the document layer.

Conditions that cause a

RenderLayer

to become a compositing layer include:

the root document layer

layers with CSS 3D transforms or perspective (e.g.,

translateZ()

or

backface-visibility:hidden

)

layers containing accelerated

video

or

canvas

elements

layers with CSS opacity or transform animations

layers that overlap other composited elements (as indicated by the "Compositing due to association with a element that may overlap other composited elements" reason)

Chrome DevTools → Layers shows the list of compositing layers and their details. For example, Baidu’s homepage has only the root document layer because it lacks heavy animations.

Understanding why a second compositing step occurs: first, WebKit creates

RenderLayer

s; second, the compositor merges them into GPU‑cached compositing layers to reduce memory usage and minimize repaint work when only a layer changes (e.g., position, scale, opacity).

8. [Extension] JS Performance Monitoring

JavaScript can block rendering, and optimizing JS performance is a substantial effort. Below are two popular tools for measuring JS execution speed.

8.1. Benchmark.js

Benchmark.js is a well‑known library for micro‑benchmarking JavaScript code. Install it via npm:

<code>npm i --save benchmark</code>

Import it in your test file:

<code>var Benchmark = require('benchmark');</code>

Create a suite, add functions with

add()

, and listen to events such as

cycle

to see results like ops/sec and statistical error.

Ops/sec indicates how many times the code runs per second; higher is better.

8.2. JsPerf

JsPerf provides the same functionality as Benchmark.js but as an online service. Log in with GitHub, create a new test, paste code snippets, and view comparative results.

9. Conclusion

It took three days to compile this deep dive into browser rendering mechanisms. The material is dense, but understanding the theory helps avoid misuse of hardware acceleration and improves real‑world performance. Feedback and corrections are welcome in the comments.