Analysis of JD.com Homepage Frontend Architecture and Lazy‑Loading Techniques

While browsing JD.com with the Chrome console open, the author discovered code snippets and localStorage entries that reveal the basic structure of JD’s front‑end architecture.

JD uses seajs as its module loader and a custom‑built jd‑jquery library based on jQuery 1.6.4, indicating a mature front‑end ecosystem with many reusable components and plugins.

Front‑end and back‑end situation

The e‑commerce homepage mainly presents entry points to various markets and personalized recommendations, with the back‑end handling data recommendation, validation, and type checking, while the front‑end simply renders the data. The homepage carries many secondary page links and channel recommendations, most of which are static or loaded via JSONP, requiring the front‑end to process large amounts of data efficiently and maintain high security and stability.

It is inferred that JD has a middle‑layer that assembles data per module, pulling content from an operations platform that pushes data to a CDN or application server.

Front‑end technology brief analysis

To achieve fast page loads, JD minimizes request count, reduces payload size, and employs lazy‑loading for non‑critical resources.

Front‑end cache and asynchronous loading

JD implements on‑demand loading and data caching. Each lazy‑load module includes two attributes: the content needed for rendering (data + JS) and an expiration time, identified by a file hash. When a module enters the viewport, the browser requests the data‑path URL; if a matching hash exists in localStorage, the module renders directly, otherwise the data is fetched and the cache updated.

Example of the script generated for a module:

<script> var data = { JSONSting }; seajs.use('path/to/$version$/script.js', function(Script){ Script.init(data); }); </script>

This separation allows the script to be cached long‑term while data changes trigger only small requests.

Engineering structure

A typical project layout looks like:

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

Modules are referenced in src/index.tpl ; synchronous modules are directly included, while asynchronous modules (e.g., moduleA/index.tpl ) contain a simple lazy‑load placeholder:

<div lazyload data-path="<%moduleA%>" data-time="<%md5(moduleA+getData())%>"></div>

Horizontal technology comparison

Unlike the common practice of bundling all JS/CSS into a few files for combo loading, JD adopts a more aggressive lazy‑load and lazy‑execute approach, reducing the impact of a single module change to a small cache update.

Sample functions for loading resources from localStorage:

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

When the required version is not present in cookies, the server outputs the CSS/JS inline.

Conclusion

The analysis shows that JD’s homepage employs sophisticated front‑end techniques—module loading with SeaJS, custom jQuery, lazy loading, hash‑based caching, and fine‑grained resource control—to achieve fast load times and efficient updates.