How We Cut Event Page Load Time by Up to 700 ms for Millions of Shoppers

Background

Event pages for Tmall, Taobao and other large‑scale promotions are critical carriers. With billions of consumers, the performance of these pages directly influences the shopping experience.

Changes and Challenges

Previously, performance metrics only measured front‑end latency. The new full‑link metric measures the time from user click to visual display, requiring unified data across the client container, WebView and front‑end. This introduces challenges in aligning data definitions and integrating information across stages.

Solution and Practice

We decomposed the user journey into four stages: routing, PHA container, WebView, and the page framework. Optimizations such as pre‑rendering, data pre‑request, accelerated resource download, and offline resources were applied, reducing average load time by 200‑700 ms and increasing the instant‑open rate by 10‑14 %.

Statistical Metric

Earlier metrics focused on front‑end timing only. The new metric, based on user perception, measures the entire chain from click to visual rendering, requiring unified data collection and integration.

Performance Goal

The goal is to achieve the “one‑second rule”: within one second of a click, the first screen of the event page should be visible, improving the proportion of users who experience a sub‑second load.

Implementation Details

Client Side

Routing stage: short latency, limited optimization impact.

PHA container: a Progressive Hybrid App framework that bridges native and web, offering pre‑rendering, data pre‑request, offline resources and NSR features.

Navigation animation: stable 15‑30 ms, limited room for improvement.

Container white‑screen: time spent creating the container and configuring the page.

WebView stage: high cost of creation and resource loading, especially on low‑end devices.

Front‑End Side

Multi‑segment terminal rendering: load HTML and entry JS, then request data, finally load and render modules.

Use ZCache and PHA resource cache to accelerate HTML and module JS loading.

Data pre‑request: shift data requests to the moment of click and execute them in parallel.

Resource loading acceleration: preload static resources via ZCache and implement offline resource rules with LRU eviction.

WebView Pre‑Rendering

Pre‑rendering creates the WebView and loads resources off‑screen before the user navigates, caching the rendered result for instant display. Scheduling avoids busy periods and uses idle time or user actions to trigger the task.

During pre‑rendering, the WebView renders with placeholder data and caches the result. When the user finally clicks, the cached WebView is consumed, eliminating white‑screen time.

Data Snapshot

To achieve true “instant‑open”, the previous visit’s data is cached locally. During pre‑rendering, this snapshot is used as placeholder content; after the real navigation, a hydrate process updates only changed nodes, avoiding flicker.

Snapshot write‑back: front‑end stores last visit data via JSBridge or localStorage.

Static fallback: when no snapshot exists, static module lists and resource versions are fetched from CDN.

Cache invalidation: module data defaults to one‑hour validity, configurable for time‑sensitive content; module resources are cached indefinitely.

Full‑Link Performance Data

Unified performance data collection links all sub‑stages and tasks, enabling consistent reporting of key metrics.

Conclusion and Reflections

The optimization of the main event page demonstrates significant gains, but scaling these improvements across the entire Taobao ecosystem remains a long‑term challenge. Future work includes lighter pre‑rendering solutions, standardized performance metrics, and better developer tooling.