Multi-Platform Storefront Integration and Performance Optimization at JD.com

Keywords: store, multi‑end integration, webview, Taro, JDHybrid, performance optimization, ISV openness

After the store browsing loop, code reuse across different terminals was impossible, leading to increased development costs and outdated technology; the team therefore launched a multi‑end integration project to rewrite rendering from a fragmented 1.0 era to a unified 2.0 codebase.

The store team provides rapid page building for hundreds of thousands of merchants on various platforms (APP, M‑site, JD mini‑program) and enables ISV partners to create custom floor templates, generating significant additional revenue for JD.

Problems identified include inconsistent UI across terminals, heterogeneous technology stacks (including C‑based back‑ends and various front‑end frameworks), high maintenance overhead, and limited resources to support all three browsing ends simultaneously.

Competitors have adopted self‑developed mini‑program rendering, achieving higher development efficiency; JD's RN‑based rendering cannot embed external floors, further highlighting the need for change.

The multi‑end integration aims to unify code across terminals, abandon RN, align with competitors, and boost both internal development efficiency and ISV partner productivity.

Current rendering flow uses an "XML template to JSON dynamic delivery" approach, which, while allowing APPs to update templates without redeployment, forces separate parsing libraries for H5 and mini‑programs, leading to duplicated effort and inconsistent data formats.

The integration must solve four key issues: unified server data format, unified front‑end rendering across terminals, maintain first‑screen performance, and improve ISV template development efficiency.

Frontend Rendering Integration – Solution 1: A dual‑parsing‑library approach where a unified parser contains two logics—RN for JD APP and JDReact for H5/M‑site, plus a separate mini‑program parser. This reduces work by 30‑40% but still requires two parsers and does not fully resolve performance or ISV efficiency.

Solution 2 (Preferred): A "multi‑end unified Taro solution" that builds a static resource project, packages an offline H5 bundle delivered via JDHybrid, injects it into the native webview, and uses Taro to generate H5 pages for M‑site/PC and mini‑program packages. This cuts development effort by 60‑70%, improves rendering performance, and enables ISV partners to develop a single template for all three terminals.

Currently, the APP store page displays both native and webview floors; work is underway to embed JD mini‑programs and ensure webview reuse for optimal performance, achieving a hybrid native+H5+mini‑program capability.

The overall "multi‑end unified Taro" scheme comprises four core components (H5‑APP fusion, H5‑mini‑program fusion, Node.js services, ISV cross‑end openness) plus extensions for exception handling, disaster recovery, performance monitoring, and observability.

First‑screen performance benchmarks before integration: iOS/Android ~0.7‑1 s, M‑site ~4 s, JD mini‑program ~2.5 s.

Core performance measures: Use of Hybrid offline packages to pre‑download resources, early webview initialization, lazy loading of heavy images, and pre‑fetching data at store entry, reducing perceived first‑screen time to ~800 ms on iOS while matching native+RN performance.

Android applies similar pre‑fetching and Hybrid package strategies, achieving comparable first‑screen times.

Additional optimizations include static resource merging, skeleton screens, lazy loading of floors and images, and offline caching for H5.

Benefits of integration: First‑screen performance parity with native+RN, significant ISV efficiency gains (single‑codebase supporting three terminals), reduced human effort (56 % fewer people, 66 % fewer man‑hours), server‑side data unification (30‑50 % cost reduction), and the creation of three technical patents and several technical articles.

Technical outlook: Front‑end technology evolves rapidly; supporting many display ends with duplicated code is unsustainable. The industry seeks a best‑practice combination that enables a single codebase to adapt across platforms, though a universal standard remains elusive.