How Baidu App Cut Landing‑Page Load to Sub‑Second with Hybrid Optimizations

Background

Baidu App introduced a Feed‑style flow in early 2016. By late 2017 the landing page used a hybrid H5 approach, but users experienced up to three seconds before the first screen appeared. Reducing this first‑screen latency became a core performance goal.

Methodology

Performance metrics were defined for first‑screen with and without images. Instrumentation was added to the native kernel (NA), the H5 layer, and the hybrid framework to collect timing data across devices. Average and 80th‑percentile reports were generated and A/B experiments validated each optimization.

Hybrid Architecture and Bottlenecks

The hybrid solution consists of a native container hosting a WebView that loads an HTML template and then fetches content via native APIs. Profiling identified four major cost stages:

NA component initialization – WebView creation (≈500 ms on first launch).

Hybrid initialization – template verification and parsing (≈100 ms).

Content loading & rendering – JSON fetch, DOM construction, CSS application (≈1400 ms).

Image loading – network download, cache write, final rendering (≈700 ms).

These stages summed to roughly 2600 ms for the 80th‑percentile.

CloudHybrid Solution

1. Server‑Side Static Rendering

The server (using Smarty) renders the first‑screen HTML with data and CSS embedded, so the kernel can render immediately. Non‑critical sections (recommendations, ads) are loaded asynchronously with Preact.

Result: first‑screen time dropped from ~2600 ms to under 2000 ms.

2. Dynamic Information Fill‑Back

Placeholders are inserted in the static HTML for client‑specific values (cover image URL, font size, night mode). Before loading the URL, the client replaces these placeholders via regex, ensuring the rendered page contains all required information.

3. Animation‑During‑Transition Fix

On Android 4.2–N the system flag setDrawDuringWindowsAnimating is false, causing a white screen during activity transitions. Using reflection to set the flag to true eliminates the visual glitch.

/**
 * Enable rendering during activity transition animation */
private void setDrawDuringWindowsAnimating(View view) {
    if (Build.VERSION.SDK_INT > Build.VERSION_CODES.M ||
        Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
        return; // No issue on Android N+ or <4.1
    }
    if (Build.VERSION.SDK_INT < Build.VERSION_CODES.JELLY_BEAN_MR1) {
        handleDispatchDoneAnimating(view);
        return;
    }
    try {
        ViewParent rootParent = view.getRootView().getParent();
        Method method = rootParent.getClass()
                .getDeclaredMethod("setDrawDuringWindowsAnimating", boolean.class);
        method.setAccessible(true);
        method.invoke(rootParent, true);
    } catch (Exception e) {
        e.printStackTrace();
    }
}
/** Android 4.2 specific handling */
private void handleDispatchDoneAnimating(View paramView) {
    try {
        ViewParent localViewParent = paramView.getRootView().getParent();
        Class<?> localClass = localViewParent.getClass();
        Method localMethod = localClass.getDeclaredMethod("handleDispatchDoneAnimating");
        localMethod.setAccessible(true);
        localMethod.invoke(localViewParent);
    } catch (Exception e) {
        e.printStackTrace();
    }
}

New Optimization Attempts

1. WebView Pre‑Creation

Creating a WebView ahead of time using MutableContextWrapper and storing it in a cache pool reduces first‑screen latency by over 200 ms. The cached instance is retrieved on page load and its context is swapped to the current activity.

/** Create WebView instance using application context */
public void prepareNewWebView() {
    if (mCachedWebViewStack.size() < CACHED_WEBVIEW_MAX_NUM) {
        mCachedWebViewStack.push(new WebView(new MutableContextWrapper(getAppContext())));
    }
}
/** Acquire a suitable WebView from the pool */
private WebView acquireWebViewInternal(Context context) {
    if (mCachedWebViewStack == null || mCachedWebViewStack.isEmpty()) {
        return new WebView(context);
    }
    WebView webView = mCachedWebViewStack.pop();
    MutableContextWrapper wrapper = (MutableContextWrapper) webView.getContext();
    wrapper.setBaseContext(context);
    return webView;
}

2. NA Component Lazy Loading

Load the WebView and call loadUrl immediately after initialization, avoiding waiting for activity lifecycle callbacks.

Delay initialization of the comment component until pageFinish or first‑screen paint, saving 60–100 ms on the 80th‑percentile.

3. Kernel Optimizations

Rendering thread split: An IOThread fetches HTML, a ParserThread parses it, and the MainThread renders. When a parsed div with a special class exceeds screen height, the kernel renders the first screen without waiting for the whole document, shaving 100–200 ms.

Pre‑load JS: After WebView creation, a lightweight JS stub runs to initialize the WebView logic, cutting another ~80 ms.

Balancing Traffic and Speed

Frequent prefetch consumes bandwidth; hit rate exceeds 90 % but effective usage is only ~15 %.

Compress prefetch packages (inline CSS, icons) – size reduced by ~40 %.

Intelligent prefetch: score resources to decide 4G prefetch, yielding a 9.5 ms improvement for images.

Video prefetch throttling during peak traffic – cuts video traffic by ~7 % and peak bandwidth by 3 % with <100 ms start‑up degradation.

AI‑driven prefetch prediction based on user behavior to further reduce waste.

Summary & Outlook

Combining server‑side static rendering, dynamic fill‑back, animation‑fix, WebView pre‑creation, NA lazy loading, and kernel tweaks achieved sub‑second first‑screen times. The 80th‑percentile improved by 80–150 ms.

Do work early: pre‑create WebView and prefetch data.

Parallelize: image direct‑out & request interception, async data preparation.

Lightweight: trim HTML/CSS/JS size.

Simplify: use static output for purely informational pages.

Future Work

Support dynamic page updates for highly interactive content.

Open‑source the optimization framework and gather community feedback.