Performance Optimization of H5 Pages on TV Devices: Challenges, Solutions, and Results

Background: With continuous innovation in Internet technology and rapid development of the TV industry, watching online videos on TV has become an important entertainment method. The Kiwi App is one of the most active applications on TV devices, providing rich content playback services as well as high‑efficiency membership operations and special activities. To meet these high‑efficiency requirements, the team investigated mainstream dynamic and cross‑platform technologies (H5, Flutter, React Native) and chose an H5 solution based on development efficiency, manpower cost, dynamic capability, and performance. However, H5 pages load slowly on TV devices, affecting user experience.

Challenges:

1. Fragmented TV OS versions: about 30% of devices run Android 5.0 or lower, requiring compatibility across a wide version span.

2. Low‑end hardware: many TV sets, boxes and projectors have CPUs of 4‑core A53 with ≤1.5 GB RAM, or even A7 CPUs with 512 MB RAM.

3. App version fragmentation: many customized SDKs, cautious OTA updates, and a large number of cheap devices that are rarely maintained, making SDK‑level optimization difficult.

Optimization Process:

1. Preparation – unified performance metrics The team defined new metrics that reflect real user experience: page‑visible time (click → visible), total interactive time (visible + response to remote‑control), native page time, WebView initialization, H5 load start, H5 execution to visible, and H5 interactive time. These metrics were instrumented in the Web SDK and collected online.

2. H5 load‑time optimization Conventional front‑end techniques were applied: resource merging, request merging, business‑logic optimization, DOM structure optimization, and async route loading.

3. Server‑Side Rendering (SSR) SSR was introduced to generate the initial HTML on the server, reducing the amount of work the TV device must perform. Although SSR can hinder progressive loading, experiments showed a significant reduction in overall load time.

4. Offline resource caching Critical static resources (css, js, png, ttf) are pre‑downloaded via CDN and stored in a local cache. WebView’s shouldInterceptRequest callback serves resources from the cache when available, dramatically speeding up loading.

Additionally, the team switched from HttpUrlConnection (HTTP/1.0) to a custom TV‑specific network library that supports HTTP/2.0, improving request performance on low‑end devices.

5. Parallel loading While the native activity transition is occurring, the app intercepts the user’s click and starts loading the SSR data in parallel, using a token‑based cache and multi‑thread synchronization to reduce perceived latency.

6. WebView container pre‑heating When the app is idle, a pool of pre‑initialized WebView instances is created, allowing instant reuse and cutting container startup time.

7. Page pre‑rendering For scenarios such as a 6‑minute free trial that automatically jumps to an H5 page, the team triggers pre‑rendering during the countdown, achieving a “second‑open” effect. GIFs illustrate the before/after loading experience.

Results: After the series of optimizations, the average H5 load time dropped from ~5.5 s (non‑SSR) and 3.5 s (SSR) to about 2 s. AB tests showed a 21 % increase in order‑generation conversion rate and a 2.4 % increase in payment success rate. The improvements also lifted the average loading time to 2 s, with a target of staying under 2 s in future work.

Future Plans: Continue to explore techniques to keep average page load time under 2 seconds, address tail‑user experience (90th percentile), and further optimize critical business pages such as the checkout flow.