How to Slash H5 Page White‑Screen Time in Mobile Apps

Introduction

As mobile device performance improves, embedded H5 pages in apps become acceptable, but without targeted optimization they still suffer poor experience, mainly white‑screen delay and interaction smoothness. This article focuses on reducing the white‑screen time.

Process

Opening an H5 page involves many steps: initialization, request, download, HTML parsing, resource requests, DOM rendering, JS execution, data fetching, final rendering, and image download.

初始化 webview -> 请求页面 -> 下载数据 -> 解析HTML -> 请求 js/css 资源 -> dom 渲染 -> 解析 JS 执行 -> JS 请求数据 -> 解析渲染 -> 下载渲染图片

Most modules request data via JS after the initial render, so the user sees a white screen until the full page is rendered.

Frontend Optimization

Key points include reducing request count, speeding up requests, caching, and rendering optimizations.

Reduce request volume : combine resources, minify/gzip, use WebP, lazy load.

Accelerate request speed : DNS pre‑resolve, reduce domains, parallel loading, CDN.

Caching : HTTP cache, offline manifest, localStorage.

Rendering : JS/CSS optimization, load order, server‑side rendering, pipeline.

The most impactful factor for first‑screen speed is network request, so caching strategies are emphasized. HTML, JS/CSS/images are cached differently: HTML usually checks for updates (304), while static resources can be served from local cache using versioned URLs or hashes.

JSON data can be cached in localStorage and refreshed in the background.

Client‑Side Optimization

Clients can intercept all H5 requests and manage their own cache, solving the conflict between HTML caching and update freshness.

HTML Cache

First request caches HTML; subsequent loads use the cache. Updates can be triggered later, either in background or at app startup.

Issues

No pre‑load : first visit requires full network fetch.

Uncontrollable cache : system webview cache limits space and may evict important files.

Poor update experience : full‑package download on changes.

Hijacking risk : third‑party interception can cache malicious pages.

Offline Package Solution

Package all pages and resources of a business module into an encrypted zip (offline package). Benefits:

Pre‑download whole package per module, enabling one‑click pre‑load.

Separate core files from dynamic images, allowing memory pre‑load and reduced disk I/O.

Version‑based incremental updates.

Encryption and signature prevent hijacking.

Implementation Steps

Backend builds and signs the package.

Client downloads, decrypts, and verifies it according to a config.

When a module is opened, the client redirects to the package entry page.

Intercept network requests: serve from package if present, otherwise fall back to HTTP cache.

On update, download diff data and merge incrementally.

Additional Optimizations

Common Resource Bundle

Extract shared JS frameworks and CSS into a separate bundle to avoid duplication across packages.

WebView Pre‑load

Initialize a webview early (or maintain a pool) to reduce first‑load latency.

Data Pre‑load

While the webview starts, parallelly fetch required JSON data and cache it for immediate use.

Fallback Strategies

If the offline package is missing or outdated, options include blocking download, using the old package, or falling back to the online version.

Native Interfaces

Expose custom network and storage APIs from the client to JavaScript for DNS pre‑resolve, long connections, and concurrent reads.

Server‑Side Rendering

Render static content on the server to eliminate JS‑driven rendering delays, though it adds server load and changes development patterns.

Conclusion

By combining front‑end caching, client‑side interception, offline packages, pre‑loading, and parallelism, H5 pages can achieve startup times comparable to native modules, leaving only webview rendering overhead for further optimization.