Browser Engine Architecture and Rendering Process: From WebKit to Blink

Browser Engine

Browser engines are the core part of a browser, responsible for parsing web content (HTML, CSS, JavaScript) and presenting it to the user. Different browsers may use different engines, which leads to subtle rendering differences.

IE: Trident

WebKit: Safari

Blink: Chrome, Edge

WebKit

webKit

WebKit is an open‑source web browser engine that powers browsers such as Apple’s Safari. It originated from KDE’s KHTML and KJS libraries and was later expanded by Apple. The codebase is mainly written in C++, with some C and assembly.

Main components:

WebCore: The core of WebKit that renders HTML and CSS, based on the original KHTML.

JavaScriptCore: Executes JavaScript, based on the original KJS.

After WebKit’s success, Google initially used WebKit for Chrome but later forked it to create its own engine, Blink.

Timeline

WebCore

WebCore is the core part of the WebKit engine that transforms web content into a visual representation that users can see and interact with.

It implements most Web APIs, parses HTML and CSS, computes layout, and renders the page. It handles text, images, video, SVG, Canvas, WebGL, animations, audio, and includes a CSS JIT compiler.

Rendering Process

The rendering process of WebCore involves several steps, from receiving raw HTML, CSS, and JavaScript resources to producing the final pixels on the screen.

Parse (CPU):

WebCore parses HTML to generate a DOM tree.

CSS is also parsed to generate a CSSOM (CSS Object Model).

Merge DOM and CSSOM (CPU): The DOM and CSSOM are combined into a Render Tree, which excludes elements such as display: none .

Layout (CPU): Determines the exact position and size of every visible element.

Layer Creation (CPU): Layers are created to improve performance; certain CSS properties trigger separate layers.

Painting (CPU + GPU): WebCore traverses the render tree and paints each element’s pixels using the UI backend.

Compositing (GPU): Layers are composited in the correct order and presented to the user, handling scrolling, transforms, and opacity efficiently.

Painting and Compositing

Most painting and compositing happen on the GPU, which is familiar territory for graphics developers.

Painting

The painting stage may call GPU APIs depending on the rendering scenario and browser optimizations.

Typically, painting starts on the CPU, producing a bitmap that can be uploaded to the GPU as a texture for the compositing stage.

Modern browsers often perform painting directly on the GPU for complex effects such as CSS filters or gradients, invoking APIs like OpenGL or DirectX.

The UI backend abstracts platform‑specific drawing, allowing the engine to “write once, run everywhere.”

Windows: UI backend may use DirectX.

macOS: Core Graphics, Metal.

Linux: X11 or Wayland.

iOS: Core Graphics and Metal.

Android: OpenGL ES or Vulkan.

Painting Process

During painting, WebCore performs the following steps:

Determine painting order: Paint bottom‑most elements first, then those above them.

Clipping and culling: Skip elements outside the viewport or fully occluded.

Call platform drawing APIs: Use Core Graphics, Direct2D, etc., to draw.

Background and border: Paint background color/image, then borders.

Text and images: Render fonts, colors, and images, applying scaling or transforms as needed.

Child element painting: Recursively paint children of container elements such as <div> .

Transparency and compositing effects: Apply opacity, shadows, and other effects.

Interactive states: Ensure :hover, :active, etc., are rendered correctly.

When all visible objects have been painted, the painting stage ends.

Compositing

When CSS properties like transform , opacity , or filters are used, browsers may create a separate compositing layer for the element, allowing the GPU to move or animate it without re‑painting the whole page.

Compositing mainly occurs on the GPU, which excels at parallel pixel and layer operations, greatly improving animation smoothness and scroll performance.

During compositing, each layer is stored as a texture; the GPU then combines these textures in the correct order to produce the final view.

Comparison with Graphics Engines

3D graphics engines such as three.js provide frameworks for creating, rendering, and manipulating 3D content, including physics, lighting, animation, and model loading.

three.js uses the WebGL API to render 3D scenes in the browser, while the browser’s 2D rendering pipeline (WebCore) focuses on layout, style, and painting of HTML/CSS.

Core Concept Comparison

Although the contexts differ, many core concepts are analogous.

Elements / Objects

CCS Box Model

Simple 3D Object

2D page rendering: HTML elements such as <div> , <img> , <p> .

three.js/3D rendering: Objects like THREE.Mesh , THREE.Group .

Style / Material

2D page rendering: CSS styles define background, font, borders, etc.

three.js/3D rendering: Materials define surface appearance, color, shininess, textures.

Hierarchy / Scene

2D page rendering: DOM tree represents element hierarchy.

three.js/3D rendering: A THREE.Scene contains all objects and defines their spatial relationships.

View / Camera

2D page rendering: The viewport shows the portion of the page currently visible.

three.js/3D rendering: A camera defines the perspective and position from which the scene is viewed.

Lighting / Color

2D page rendering: Color defines background, text, and border colors.

three.js/3D rendering: Lights affect object colors and shading, combined with materials and textures.

Animation / Transform

2D page rendering: CSS animations and transforms modify position, size, color, etc.

three.js/3D rendering: Animation libraries and transform methods change object position, scale, rotation.

Interaction / Event

2D page rendering: Event listeners capture clicks, hover, focus, etc.

three.js/3D rendering: Raycasting can detect clicks, intersections, drag‑and‑drop on objects.

Rendering Process Comparison

Changes and Constants in Evolution

Graphics Engine Evolution

From Unity’s debut in 2005, to three.js in 2010, to Babylon.js in 2013, new graphics engines continuously emerge and serve their niches.

What changes: Underlying rendering technologies (forward rendering, deferred rendering, global illumination, PBR) and APIs (WebGL1, WebGL2, WebGPU).

What stays the same: Core concepts such as meshes, materials, textures, and lights.

Browser Evolution

Browser history starts with IE in 1995, Safari in 2003, and Chrome in 2008.

What changes: Front‑end frameworks (jQuery, Angular, React) and underlying rendering optimizations.

What stays the same: Core models like the box model, DOM tree, style tree, and render tree.

Thus, whether it is a graphics engine or a browser, a solid conceptual foundation remains constant while implementation details evolve.

Join Us

🚕 DCarFE is a front‑end team of over 100 engineers building cutting‑edge automotive web experiences. We focus on 3D immersive car viewing, WebAR/VR, AI‑front‑end integration, and more, using React, TypeScript, Web3D, Golang.

We have offices in Beijing, Chongqing, and Hangzhou. Click the links below to apply:

Frontend Engineer – https://job.toutiao.com/s/idwN1FqS

Senior Web3D Engineer – https://job.toutiao.com/s/rweXPdL

References

https://github.com/WebKit/WebKit/blob/main/Introduction.md

https://webkit.org/blog/3271/webkit-css-selector-jit-compiler