How JD.com Scales Its Homepage: Frontend Architecture, Static Rendering, and Engineering Practices

JD.com Homepage Frontend Architecture Design and Implementation

In March 2016 the Internet Technology Alliance launched a Front‑end Technology Month, and JD.com senior frontend architect Liu Wei shared the design and implementation of the JD.com homepage.

Challenges

DOM element count increased dramatically (5→9 tabs per floor, total height doubled, image count rose to 80%).

First‑screen load time must not increase despite higher traffic and many concurrent requests.

Frequent urgent business requirements and high stability demands.

Frontend Page Staticization

To avoid costly database queries on each request, the homepage is rendered as static HTML. The stack is CDN → HAProxy → Nginx (dynamic cache) → PHP → Redis → MySQL. Static files are generated every two minutes and distributed to CDN nodes.

Overall Frontend Architecture

JS Layer : jQuery 1.6.4 (chosen for compatibility), JDF public components (UI, business widgets, lazy‑load, etc.), and page‑specific scripts such as recommendation and advertisement floors.

CSS Layer : Light reset file ui-base.css; per‑floor styles are combined into a single request and placed in the first‑screen bundle.

Page Loading Strategy

Pages are split by floor; the first screen loads the framework, each floor loads asynchronously via its own data API and is cached in localStorage. If cached data matches the server MD5, it is used directly; otherwise an Ajax request refreshes the content. Fallback logic ensures no blank area on failure.

Basic Infrastructure

Tools and System (JDF)

JDF is a Node.js‑based command‑line tool that handles project initialization, module compilation, output packaging, CDN prefixing, asset compression, sprite generation, base64 conversion, and file encoding normalization.

Typical workflow: jdf init → jdf build → jdf output → upload to test server → git commit → online JDF pack → CDN deployment → cache purge.

Disaster Recovery Strategy

Prefer local localStorage cache.

Retry failed requests.

Use CDN fallback before origin.

Provide fallback data when origin is unreachable.

Disable non‑core interfaces when necessary.

Performance Optimization

Reduce first‑screen elements via lazy‑load and local cache.

Inline critical CSS.

Combine CSS/JS requests and use sprites.

Compress assets.

DNS pre‑fetch.

Minimize cookie size.

Engineering Practices

Modules (widgets) consist of configuration, data, template, style, script, and images. They are built, installed, published, and previewed with JDF commands such as jdf widget -install, -create, -publish, -preview, and -list. Components are shared across the site, and documentation is maintained in the GitHub repository.

Q&A Highlights

JDF is written in Node.js.

Static pages are refreshed every two minutes; personalized data is loaded via Ajax.

CDN cache is cleared by versioned URLs or manual purge.

Image compression uses the jdf-png-native package.

Dependency handling follows the CMD specification.

DNS pre‑fetch is supported by modern browsers.