Inside JD.com’s Front‑End: Seajs, Lazy Loading, and Smart Caching

During a casual inspection of JD.com’s homepage in Chrome’s console, a series of familiar code snippets and localStorage entries revealed the underlying front‑end architecture.

JD employs Seajs as its module loader and a custom jd‑jquery library (version 1.6.4), indicating a mature internal front‑end ecosystem with reusable components and plugins.

Front‑End vs. Back‑End Responsibilities

The homepage primarily presents a variety of horizontal and vertical market entrances, with most dynamic content supplied by back‑end services via JSONP. Unlike transaction or detail pages, the homepage’s logic is front‑end heavy, requiring rapid rendering of data maintained by operations teams.

A middle‑layer on the back‑end assembles module‑specific data, which is then pushed to a CDN or application server for the front‑end to consume.

Performance Techniques

To achieve fast loading, JD minimizes request counts, reduces payload sizes, and defers non‑essential content through lazy loading. Each lazy‑load module carries two attributes: data‑path (the URL of the required script and data) and data‑time (a hash‑based version identifier). When a module enters the viewport, the script fetches the resource; if a matching hash exists in localStorage, the cached content is rendered directly.

<div lazyload data-path="moduleA" data-time="{hash}"></div>

This approach separates data from initialization scripts, allowing long‑term caching of the script while only the data payload changes. Updating the version hash forces the browser to reload the updated script.

Project Structure

A typical project layout looks like:

build/
└── src/
    ├── widgets/
    ├── mods/
    │   ├── moduleA/
    │   │   ├── index.js
    │   │   └── index.tpl
    │   ├── moduleB/
    │   └── moduleC/
    ├── index.js
    └── index.tpl

Modules that require synchronous rendering are directly included in src/index.tpl, while asynchronous modules (e.g., moduleA/index.tpl) contain minimal markup that references the lazy‑load hook.

Lazy Loading vs. Combo Loading

Traditional combo loading bundles all module scripts and styles into a few files, reducing request numbers but causing the entire bundle to be re‑downloaded when any module changes. JD’s lazy‑load‑and‑lazy‑execute strategy updates only the affected module’s cache, improving cache efficiency at the cost of additional initial requests for first‑time visitors.

Resource Loading Helpers

Utility functions handle CSS loading from localStorage and conditional inlining based on cookie version checks:

var loadCss = function() {
    var style = loadFromLocalstorage();
    inserCss(style);
};

// Pseudo‑code for version check
if (cookies('cssV') || cookie('cssV') !== 'setsV') {
    echo CSSCode;
}

If the version stored in cookies differs from the expected version, the CSS and JS are inlined to ensure the latest resources are delivered.

Conclusion

The analysis shows that JD.com’s homepage leverages a custom front‑end stack with Seajs, lazy loading, hash‑based caching, and a modular project structure to achieve impressive load performance and maintainability.