Optimization of T7 Browser Kernel Cache Mechanism in Baidu App

Reading Gains

Understand the underlying mechanism of browser kernel cache and explore optimization directions.

Learn about the challenges and practical applications of resource caching and memory management by Baidu App's browser kernel team.

Term Definition

T7 Browser Kernel – A high‑performance browser kernel customized and deeply optimized for mobile devices by Baidu App's kernel team, based on the Chromium project.

1. Introduction

When using Baidu App to browse pages, user experience largely depends on how fast and smooth the page is rendered. The resource loading stage is the bottleneck that consumes most time, while pre‑loading and cache reuse can significantly improve loading performance. This article describes how the T7 browser kernel team optimizes the page cache mechanism to boost performance and speed up page display.

2. Background

Before discussing the cache optimizations, we first introduce the T7 browser kernel's page resource loading flow.

2.1 Resource Loading Flow

The main document and sub‑resources follow the process illustrated below:

Resource Loading Flowchart

The UI thread and Blink thread initiate the HTML main‑document request via BeginNavigation . If a network request is needed, the IO thread fetches the resource, receives the first byte, and passes the data to the Blink thread, which creates the Document objects.

After the network library obtains the main‑document content, the IO thread transfers it to the Blink thread, which parses, layouts, and renders the document.

When the main document references sub‑resources, the Blink thread sequentially requests each sub‑resource. JavaScript resources block parsing until execution finishes; CSS resources block layout until they are loaded. Only after both JS and CSS are ready does the kernel proceed to layout and render the page.

2.2 Resource Loading Time Analysis

Data analysis shows that the most time‑consuming stage is network loading, accounting for about 50% of the total page‑load time (including main document and sub‑resources). Reducing network latency is crucial, and the T7 kernel addresses this by implementing a resource cache that can reuse already cached data without issuing network requests.

The cache mechanism consists of HTTPCache and MemoryCache , both treated as strong caches.

3. T7 Browser Kernel Cache Mechanism Introduction

3.1 HTTPCache and MemoryCache

HTTPCache (also called DiskCache) receives HTTP(S) requests and decides when and how to fetch data from DiskCache or the network.

MemoryCache is an in‑memory cache implemented in the Blink thread.

Chrome’s official comment on these caches:

The HTTP Cache is the module that receives HTTP(S) requests and decides when and how to fetch data from the DiskCache or from the network. The cache lives in the browser process, as part of the network stack. It should not be confused with Blink's in‑memory cache, which lives in the renderer process and it's tightly coupled with the resource loader.

Comparison of the two cache types:

Cache Type

HTTPCache

MemoryCache

Storage

Disk cache (original resource content)

Memory cache (Resource objects)

Max Capacity

20 MB

8 MB

Load Efficiency

<100 ms

Almost no delay

Stored Resource Types

Main document + sub‑resources

Sub‑resources only

Cleanup Timing

When cached size exceeds threshold

Garbage‑collected at any time

Implementation Thread

IO thread

Blink thread

3.2 Cache Strategy in Resource Loading Flow

Main Document Loading Flow

Main Document Loading Flow

Check HTTPCache; if the resource is cached, return it directly; otherwise proceed to step 2.

Issue a network request and store the returned content into HTTPCache.

Sub‑Resource Loading Flow

Sub‑Resource Loading Flow

Check MemoryCache; if cached, return it directly; otherwise continue.

Check HTTPCache; if cached, return it; otherwise continue.

Issue a network request and store the result into both HTTPCache and MemoryCache.

Because MemoryCache resides in the Blink thread, it is faster than HTTPCache and avoids additional network‑library hops, providing the shortest possible resource‑fetch path.

4. MemoryCache Optimization and Customization

4.1 Expanding Cache Capacity

4.1.1 Main‑Document Cache Capability

The original design did not allow the main document to be cached in MemoryCache. We added a main‑document MemoryCache so that before a network request is issued, the kernel can query MemoryCache for a cached main document and reuse it directly.

4.1.2 File‑Protocol Resource Cache

File‑protocol sub‑resources were previously excluded from MemoryCache. We extended MemoryCache to store file‑protocol resources, eliminating IO read latency.

4.2 Optimized Cleanup Strategy

MemoryCache originally stored only weak references, causing cached resources to be cleared together with the page lifecycle. To improve reuse across pages, we allocated a dedicated fixed‑size space within MemoryCache and applied an LRU‑based cleanup policy, increasing the reuse rate of cached resources.

4.3 Custom MemoryCache API

The original kernel only allowed sub‑resources referenced by the main document to be cached, with no external API. We now provide APIs for business teams to preload resources, query cache status, and delete entries.

5. Custom MemoryCache Implementation

5.1 NoState Prefetch

The kernel’s prefetch interface now uses the customized MemoryCache. The recommended approach is NoState Prefetch, which preloads HTML, JS, and CSS into MemoryCache + HTTPCache without parsing or maintaining page state.

NoState Prefetch – A mechanism that pre‑fetches a webpage (HTML) and its JS/CSS sub‑resources into Cache (MemoryCache + HTTPCache) without parsing, executing JavaScript, or maintaining page state.

Usage:

Insert <link rel="prerender"> into the HTML.

Call startPrerender(url) in the WebView.

Deployed in Baidu App H5 landing pages, achieving >30% speed improvement.

5.2 API Calls

addToWebCache : Preload a URL into MemoryCache (configurable request headers).

removeFromWebCache : Delete a cached resource by URL.

isInWebCache : Check whether a URL is present in MemoryCache.

6. Outlook

The optimizations described above have significantly improved page‑on‑screen performance. Future work will continue to explore deeper kernel enhancements to support business growth.

Recruitment Information

Baidu App Product R&D Department is hiring various development positions (PHP/Go/C++, mobile, front‑end, network library, etc.). Interested candidates may send their resumes to [email protected] .