Front-end Performance Optimization of Baidu App Personal Homepage

By redefining performance metrics, analyzing bottlenecks, and applying targeted front‑end code and engineering optimizations—including early iOS onload, reduced first‑screen dependencies, merged and pre‑loaded APIs, bundle splitting, and modern‑mode delivery—the Baidu App personal homepage achieved over 100 ms reductions in white‑screen and first‑screen times across iOS and Android.

Baidu App Technology
Baidu App Technology
Baidu App Technology
Front-end Performance Optimization of Baidu App Personal Homepage

Performance is a key concern for every front‑end engineer. While many generic optimization techniques have been widely covered, this article presents a case study of the Baidu App personal homepage, focusing on business‑specific performance improvements.

Defining Metrics and Building Reports

Accurate data is essential for effective optimization. Common front‑end performance metrics include DOM ready, First Contentful Paint, white‑screen time, user‑operable time, and onload time. For the personal homepage, these metrics are re‑defined to reflect real user experience, such as considering the header area and the first tab list rendering as the first‑screen completion.

The personal homepage is a web page inside the Baidu App client, available in two modes: a hybrid version (loaded via the file protocol) and a web version (opened via a URL). All data is fetched asynchronously.

The loading process can be divided into three major parts: client‑side time, network & server time, and front‑end rendering time.

First‑screen is defined as the moment when the header area and the first tab list finish rendering (i.e., the user can operate the page).

Because the page is built with san as a SPA, the initial DOM is empty; white‑screen ends when the DOM is populated with content.

On iOS, requestAnimationFrame is used to trigger onload earlier, while Android waits for all first‑screen resources before firing onload.

Data Analysis and Optimization Directions

Analysis of the collected data identified the main bottlenecks: client‑side time, loading of profile.js, first‑screen API latency, and data processing/rendering time. The optimization plan targets three areas:

Client‑side time – collaborate with native teams to find improvements.

First‑screen API latency – work with backend to optimize endpoints.

JS internal time – refactor front‑end code.

Front‑end Code Optimizations

Trigger iOS onload Early

Method: nest requestAnimationFrame with setTimeout to fire onload before resource loading blocks rendering.

Benefit: first‑screen becomes independent of load blocking.

Reduce First‑Screen Dependencies

Key findings:

Multiple native calls before the first screen cause excessive latency.

The outer App component mounts only after the first API returns, which is fine for the web version (synchronous) but delays the hybrid version (asynchronous).

Excessive telemetry requests before the first screen compete with image loading.

Implemented changes:

Reorder native calls, keeping only essential ones for the first screen.

Initialize runtime logic early and decouple App mounting from API data.

Move critical logic to the store for early execution.

Postpone non‑essential telemetry until after the first screen.

Result: >100 ms reduction in the 80th percentile.

Merge First‑Screen APIs

Combining two asynchronous APIs into one saved at least one network‑connection overhead, yielding >110 ms improvement for the hybrid version.

Pre‑load First‑Screen API

A minimal inline script is bundled to fetch the first API before the main JS finishes loading. On iOS this saved >260 ms, and on Android ~60 ms.

Engineering Optimizations

Packaging and Splitting

Balancing bundle size and request count is crucial. By splitting the code into three similarly sized bundles (vendors, main, and a secondary bundle) and leveraging caching, the number of HTTP requests is reduced while keeping cache hits high.

Modern Mode

Modern browsers load ES modules via <script type="module">, while older browsers fall back to a transpiled nomodule bundle. Approximately 75 % of Baidu App traffic supports modern mode, delivering the following gains:

White‑screen (ms)

First‑screen (ms)

Experiment group

1055

1913

Control group

1136

2081

Benefit

81

168

Optimization Results

After the changes, JS initialization time decreased, the first‑screen JSONP request is sent early, and the App component mounts before data arrives, allowing immediate rendering. Telemetry is postponed, freeing bandwidth for images. The overall flow is illustrated below:

Post‑Optimization Data Analysis

Both iOS and Android first‑screen times dropped significantly. Server‑side API improvements contributed >80 ms, while native hybrid framework enhancements on Android yielded even larger gains.

Conclusion

Effective optimization starts with reliable data collection and metric definition. Through iterative code review, experiments, and close collaboration across front‑end, backend, and native teams, the personal homepage achieved noticeable performance improvements. The methods described are tightly coupled with the specific business context and may not be universally applicable, but they illustrate a data‑driven approach to identifying and addressing bottlenecks.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

engineeringFrontendmobileperformanceWebSPA
Baidu App Technology
Written by

Baidu App Technology

Official Baidu App Tech Account

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.