How JD Optimized Its WeChat Shopping Homepage for Lightning‑Fast Performance

JD's WeChat shopping homepage (formerly the primary entry) required extremely high performance; this article shares the optimization experience.

The product iterates based on user feedback, so webpage optimization starts with monitoring.

Introduction to JD Monitoring System

JD front‑end monitoring consists of two systems: a speed‑test system and an intelligent monitoring platform.

Speed‑Test System

The page uploads timestamps of key nodes; the system aggregates data by province, time, network type, client type, etc., and provides visual analysis for easy load monitoring.

Intelligent Monitoring Platform

Pages report data in a predefined format; the platform aggregates and analyses it, offering alerts when results deviate from expectations.

Key nodes such as CSS load, HTML load, JS load, first‑screen image load, and first image load are instrumented, and business‑specific metrics (e.g., first‑screen DOM existence, API response rates) are reported to obtain a comprehensive health view.

Two Phases of WeChat Homepage Monitoring

Phase 1: First‑Screen Load Optimization (2014 ~ 2019.5)

Focus was on reducing first‑screen image load time, monitoring CSS, HTML, JS, and the first image. The target was to keep the first‑screen image load under 1000 ms.

1. First‑Screen Direct Output (SSR)

Server‑side rendering using a high‑performance C++ template generates the first‑screen content.

SSR reduced first‑screen image load by about 1200 ms compared with client‑side rendering.

2. Critical Render Path (CRP) Optimization

CRP refers to the sequence of events required for first‑screen rendering. Its three attributes are critical resources, path length, and total bytes.

Critical resources: assets that block initial rendering (HTML, CSS, JavaScript).

Path length: number of round‑trips needed to fetch critical resources.

Critical bytes: total size of those resources.

Optimization approaches:

Minimize resources needed for first paint.

Reduce path length (fewer requests).

Reduce resource size.

2.1 Split First‑Screen and Non‑First‑Screen

Define the area above the bottom tab as first‑screen; load non‑first‑screen assets lazily (async JS/CSS, lazy‑load images).

2.2 Reduce Path Length

Critical render path length equals the number of network requests for critical resources.

Inline first‑screen CSS and JS.

Merge JS files into a single bundle.

Inline first‑screen icon images.

Combine bottom navigation icons into a sprite.

2.3 Reduce Resource Size

HTML is minified with

html‑minifier

. JS undergoes tree‑shaking via Webpack (ES6 modules). Unused CSS is removed with PurifyCSS, saving ~58 KB. Legacy JSON configuration data is trimmed and APIs are optimized to eliminate stale entries.

3. Image Optimization

3.1 Use WEBP and DPG Formats

Client‑side detection switches to WEBP/DPG; server also provides conversion. Both formats achieve >60 % compression, DPG slightly better; combined DPG+WEBP yields ~30 % extra reduction.

3.2 Lossless Image Compression

During deployment, images are losslessly compressed; designers’ extra data is removed, halving size.

JD’s image service further compresses images on demand.

3.3 Replace GIF with MP4

MP4 files are significantly smaller than GIFs; examples show reductions of 31 % and 55 %.

4. Resource Preloading

4.1 Preload

Preload loads critical resources (images, CSS, JS, fonts) before they are needed, overcoming the limitations of older subresource prefetch.

JD preloads the homepage banner and header background to show full first‑screen earlier.

4.2 Preconnect

Preconnect performs DNS resolution, TLS handshake, and TCP handshake before the actual request, reducing latency for frequently used domains.

4.3 DNS Prefetch / Link‑Prefetch / Prerendering

DNS prefetch resolves hostnames in the background. Link prefetch fetches resources during idle time. Prerendering fully renders a page in the background, improving navigation speed when supported.

Phase 2: Multi‑Dimensional Optimization Based on the RAIL Model (2019.5 ~ now)

The single metric “first‑screen image load time” cannot capture issues like long white‑screen, slow progress bar, or delayed modules. JD adopted Google’s RAIL model, which defines four performance goals: Response ≤ 100 ms, Animation ≤ 10 ms per frame, Idle (maximizing idle time), and Load ≤ 1000 ms for key content.

RAIL‑Based Metrics

First Paint (FP)

First Contentful Paint (FCP)

First Meaningful Paint (FMP)

Time to Interactive (TTI)

Long Tasks (monitored but not emphasized)

Phase‑2 Optimizations

Deepen CRP optimization: prioritize banner, search box, and bottom navigation; inline CSS for search box and navigation; merge JS files.

Animation improvements: replace

setInterval

with

requestAnimationFrame

to eliminate frame drops.

Scroll optimization: throttle scroll handlers to limit execution frequency.

Image lazy‑loading: use

IntersectionObserver

instead of polling timers to detect visibility.

Conclusion

Front‑end technologies evolve rapidly, and optimization rules must adapt. Classic guidelines (e.g., Yahoo’s rules) still hold value, but some become counter‑productive in the HTTP/2 era (e.g., resource concatenation). JD’s optimizations may not suit every project, but they provide valuable insights for performance‑focused development.