How JD Built a Scalable H5 Observability Platform to Boost Performance and Reduce Costs

Background of JD H5 Observation System

Hybrid app development now commonly uses a Native+H5 approach. H5 offers cross‑platform efficiency and easy updates, but suffers from poorer user experience and difficult quality control.

JD identified several problems during H5 rollout:

Business characteristics : Over 20,000 H5 pages, 90% built via CMS, involving more than 20 business teams.

R&D testing pain points : Developers lack direction for technical upgrades; business teams have no unified performance standards.

Online user feedback : Some activities experience slow page loads, especially on specific Android models.

Untimely detection of user‑experience issues can lead to user loss.

JD's Solution

JD built a self‑developed UEM observation platform in three phases:

Entry level : Proactive observation with full‑coverage data probes.

Initial achievements : Passive observation to reduce testing costs and improve efficiency.

Business enablement : End‑to‑end observation and H5 quality control to guarantee application quality.

Deep Active Observation

Active Observation Infrastructure

Active observation focuses on three foundations:

Collect metrics from JavaScript probes on user pages and define measurement standards.

Report data to a log server.

Process, store, and visualize data on the observation platform.

H5 Probe Metric Construction

Metrics should serve defined measurement standards. JD's user‑experience metrics consist of two parts: a comprehensive performance score and an exception rate.

The comprehensive score aggregates weighted performance indicators, inspired by Google Lighthouse and extended for JD's needs.

H5 Probe Quality Assurance

Quality is ensured through two "S" and two "O":

Speed : Tree‑shaking and hybrid offline packages keep probe load time minimal.

Stable : Standardized release and control processes prevent platform trust erosion.

Optional : Configurable plug‑in style, reporting frequency, and gray‑release controls.

Observable : Built‑in monitoring detects compatibility and CDN performance issues.

Log Server Architecture

During peak events, the platform must handle high traffic, ensure fault tolerance, and support diverse query needs. The architecture routes mobile requests through NSQ queues to downstream services, stores raw logs in Elasticsearch, uses MySQL for result sets, and ClickHouse for large‑scale aggregation.

A Sourcemap reverse‑parsing pipeline uploads map files to OSS and provides a Node.js service for developers to resolve stack traces efficiently.

First‑time exception alerts link new events to potential version releases, while minute‑level threshold alerts trigger work orders for rapid response.

Observation Platform Pitfalls

Common mistakes include lacking unified standards and insufficient cross‑team collaboration. JD addressed this by aligning the Frontend Committee and QA to define internal UX standards and an indicator system, enabling semi‑automated ticket generation and iterative improvement.

Case Studies

During the 618 promotion, slow page loads were traced to low comprehensive scores; targeted optimizations (e.g., skeleton screens) reduced first‑screen load from 1.98 s to 1.68 s.

Another case involved CDN node anomalies detected by the platform, prompting a resilience strategy that improved success rates from 99 % to over 99.3 %.

Automated Passive Observation for Cost Reduction

Passive observation complements active monitoring by detecting issues that probes cannot capture, such as missing pages or 404 errors.

The solution uses Puppeteer and Lighthouse on the server side to gather performance data without requiring developer instrumentation.

Core Capabilities of Passive Observation

Fifty checks cover functional problems (e.g., expired activities, 404 detection) and performance issues (e.g., resource compression, load thresholds).

Detection Efficiency

Scalable architecture runs ~100,000 URL checks daily across container farms, leveraging multi‑Chrome processes, reduced IPC overhead, and workload‑aware machine allocation.

Business Problem Detection Example

High‑volume H5 shares to a mini‑program caused crashes; pre‑emptive monitoring of share counts and OCR‑based post‑event scans helped mitigate the issue.

Performance Problem Detection Example

Passive checks aligned with active metrics to produce a unified health score; Lighthouse‑derived suggestions highlighted image size problems for remediation.

Full‑Link Observation and Quality Assurance

JD's end‑to‑end H5 quality system links client‑side data (crashes, network, user feedback) across a single session to enable rapid root‑cause analysis.

Quality gates before release incorporate passive checks (performance, compliance, security) into CI pipelines, while post‑release daily inspections combine probe data with custom monitoring.

During major sales events, daily quality dashboards increase platform visibility and drive continuous improvement.

In summary, JD progressed from proactive to passive observation, unified standards, and full‑link monitoring to ensure H5 application quality and operational efficiency.