How JD.com Scales Its E‑Commerce Homepage with Front‑End Engineering

Challenges of JD.com Homepage

Page DOM elements increased dramatically (tabs per floor from 5 to 9).

Total page height doubled to 14 floors, height from 4820px to 9862px.

Image count surged, 80% of positions now display images.

First‑screen load time must not increase.

Homepage must never be blank or error‑prone.

High traffic and concurrency demand extreme stability.

Frequent temporary and urgent business requirements.

Front‑End Page Staticization

To avoid heavy database queries on each request, JD.com generates static pages. The architecture is:

Access layer: CDN → HAProxy → Nginx

Application layer: PHP + Redis

Storage layer: MySQL

Users request the CDN‑assembled static page, which is cached by Nginx. Nginx forwards to PHP, which uses Redis for caching and MySQL for data. A 2‑minute cron job generates static fragments and distributes them to CDN nodes, ensuring the nearest CDN serves the page.

Overall Front‑End Architecture

JS Layer : Uses jQuery 1.6.4 (chosen for smooth upgrade across thousands of pages) with custom backend‑specific adjustments such as JSONP callback length.

Public Components (JDF) : UI components, business widgets, and common utilities (event handling, localStorage, lazy loading, suggestions, login, search, etc.).

Page Scripts : Specific floor scripts for recommendations, ads, flash sales, etc.

CSS Strategy

Replaced the monolithic base.css with a lightweight ui-base.css. Each floor's CSS is loaded in the first screen and combined into a single request to reduce HTTP overhead.

Page Loading Strategy

Floors are split into separate data interfaces and loaded asynchronously. The first screen contains only essential elements (~900 of 3288 total). Each floor's data file includes an MD5 timestamp; if the timestamp matches the localStorage entry, the cached data is used, otherwise an AJAX request fetches fresh data and updates localStorage.

<div class="w floor lazy-fn" data-title="服饰" id="lazy-clothes" data-path="floor1-floor_index.js" data-time="01d15d664a61ff8f11cf6321f5b7a503"></div>

If the first AJAX request fails, a second attempt is made after a 5‑second delay; if both fail, the floor is hidden to avoid blank space.

Front‑End Tools and Systems (JDF)

JDF is a Node.js‑based command‑line tool that supports project initialization, module compilation, output generation, and deployment. Typical workflow:

Create project with jdf init.

Install or create widgets with jdf widget -install / -create.

Compile modules using jdf build.

Generate static output with jdf output (combines JS/CSS into combo URLs).

Upload compiled files to test servers via jdf upload.

Add front‑end statistics tags, integrate head/footer code, and deploy through Git and the Jone platform.

Front‑End Modules (Widgets)

A widget consists of a folder with:

component.json (configuration)

ui‑product‑list.json (data)

ui‑product‑list.vm (template)

ui‑product‑list.scss (styles)

ui‑product‑list.js (script)

images/ (assets)

Usage in a page: {%widgetname="ui-product-list"%} After compilation, JDF injects the appropriate <link> and <script> tags, and combines them into a single request:

??/widget/ui-product-list/ui-product-list.css,/widget/header/header.css,/widget/footer/footer.css

Front‑End Components

Reusable UI and business components include event handling, lazy loading, carousels, dialogs, dropdowns, and more. An illustration of available components is shown below.

Development Process

Initialize project with jdf init.

Install required widgets from the module cloud.

Build modules via jdf build.

Output static assets with jdf output.

Upload to test servers using jdf upload.

Commit code to Git, package with online JDF, deploy via Deploy system to CDN, clear CDN cache, and monitor performance.

Documentation

Official documentation and command‑line references are available at:

https://github.com/putaoshu/jdf/tree/master/doc

https://github.com/putaoshu/jdd

Performance Optimization

Reduce first‑screen elements via async loading and local cache.

Inline critical CSS when CDN is slow.

Combine CSS/JS requests and use CSS sprites.

Compress static assets (CSS/JS/Images).

DNS pre‑fetching (e.g., <link rel="dns-prefetch" href="//d.jd.com">).

Minimize cookie size.

Disaster Recovery Strategy

Local cache: prioritize data from localStorage.

Secondary request: retry AJAX if no cache.

Dual‑layer interfaces: primary CDN, fallback to origin server.

Fallback data: use preset backup data when origin fails.

Interface deactivation: disable non‑core APIs when necessary.

Q&A Highlights

Q: Is the public module cloud a private npm repository? A: It is a self‑hosted FTP server where modules are stored, versioned via component.json, and managed with JDF commands.

Q: What language is JDF written in? A: Node.js.

Q: How are CDN caches cleared after a release? A: By updating the version prefix of static resources (e.g., product/home/1.0.0/a.js → product/home/1.0.1/a.js) or manually clearing via CDN console.

Q: How does JDF differ from tools like Grunt or FIS? A: JDF is lightweight, bundles only vetted npm plugins, and focuses on Node.js‑only workflows with built‑in Smarty/VM template rendering.