Revamping JD.com’s Homepage: Athena Front‑End Architecture & Performance Hacks

Overall Architecture

The JD.com 2016 homepage redesign was built on the existing jQuery + Seajs stack because many legacy components could not be upgraded quickly. To improve productivity, the team created the Athena front‑end engineering suite, a Node.js‑based CLI that automates compilation, code processing, dependency analysis, and file compression.

Athena consists of several sub‑systems:

Athena Engine – command‑line tool for project scaffolding, one‑click preview, and full build deployment.

Athena Management Platform – collects statistics about projects, modules, pages, components and resources, and provides templates for new projects.

Athena Component Platform – a reusable business component library.

Athena Base Library – a jQuery + Seajs based JS library that abstracts common UI patterns.

Athena Mock API – generates fake data for front‑end development, removing backend dependencies.

Athena Fallback Service – periodically fetches real API data, generates static fallback JSON, and publishes it to CDN.

Athena Front‑End Monitoring – injects page‑level performance, environment, and error reporting.

These tools form a cohesive pipeline that covers development through production, and the same architecture is reused across multiple JD.com services.

Development Mode

Athena

Athena defines a unified project structure: an app is split into business modules, each containing pages and reusable widgets. Developers create a new project with a single CLI command, then focus solely on business logic while Athena handles file handling, compilation, and deployment.

Typical workflow:

Run athena init to scaffold the project.

Write component and page code.

Execute athena dev for live preview; Athena watches files, recompiles, and serves them.

Run athena build to generate optimized assets and upload them to the server.

Front‑Back Separation

Previously the homepage was split into a directly rendered first‑screen and asynchronously loaded floor sections, with the floor HTML generated on the backend. The new approach renders floor templates on the front‑end using a template‑plus‑data model, while the backend only provides JSON data. A mock data platform supplies fake APIs during development.

Performance tests on modern PCs showed negligible difference between front‑end and back‑end rendering, while the decoupled workflow dramatically improved development speed.

Performance Optimizations

First‑Screen Direct Output & Slimming

The first‑screen still uses direct HTML output, but only the essential CSS and a minimal set of scripts are inlined. Non‑essential styles are moved to floor‑specific bundles that load on demand.

Athena automatically extracts widget‑level CSS/JS during the build phase, generating a single bundled file per floor. This keeps the first‑screen payload dramatically smaller, as shown by the before/after size comparison images.

First‑Screen Carousel First Frame Direct Output

The carousel’s first frame data and rendering logic are now inlined, eliminating the blank period caused by slow CDN or low‑bandwidth connections.

Floor On‑Demand Loading & Scroll Optimization

Floors are loaded only when they enter the viewport. Athena compiles each floor’s template into an independent JS file; a scroll listener triggers lazy loading. To keep scrolling smooth, the system pre‑collects floor heights and offsets, avoiding DOM queries during scroll.

Script Deferred Loading

During the build, Athena replaces local paths with CDN URLs and uses Seajs.require.async to load scripts asynchronously. Example:

// Development
require.async(__uri('APP_JS_ROOT/header.js'));

// After build
require.async('https://misc.360buyimg.com/mtd/pc/index/js/header.js');

Non‑critical analytics are executed after window.onload to reduce the page’s onload time.

Template & Data Separate Caching

Both templates and data are cached in localStorage. Each resource carries an MD5 version hash; the front‑end checks the hash before deciding whether to use the cached copy or request a fresh one.

Template version hashes are injected by Athena during compilation, while data version hashes are supplied by the backend.

WebP Image Usage

Most images are served in WebP format, cutting file size to roughly two‑thirds of JPEG. Since Chrome accounts for about 60% of JD.com’s traffic, the bandwidth and load‑time savings are significant.

Experience Optimizations

HD Screen Adaptation

High‑resolution displays receive scaled‑down images generated on the fly by JD.com’s image service. Only a single high‑resolution source is uploaded; the service creates appropriate sizes via URL parameters, reducing operational overhead.

Forced WebKit Rendering

For browsers with dual engines (e.g., 360, QQ), a meta tag forces the WebKit engine to improve rendering consistency:

<meta name="renderer" content="webkit" />

OpenSearch Integration

OpenSearch descriptors are added so users can search JD.com directly from the browser address bar.

Icon Font

Icon fonts replace image sprites, offering better scalability, compression, and cross‑browser consistency.

Idle‑Time Floor & Image Auto‑Load

When the user stops scrolling for three seconds, a queue loads remaining floors and images. Scrolling clears the queue and restarts the timer.

var scrollTimer = null;
var isScrolling = false;
$(window).bind('scroll.loadFloor', function (e) {
  isScrolling = true;
  clearTimeout(autoLoadTimer);
  clearTimeout(scrollTimer);
  autoLoadingQueue = [];
  resourceLoader && resourceLoader.pause();
  scrollTimer = setTimeout(function () {
    isScrolling = false;
    if (pageConfig.idleTimeLoad) {
      autoLoadTimer = setTimeout(autoLoad, 3000);
    }
  }, 200);
});

function autoLoad () {
  if (!isScrolling) {
    runFloorLoadQueue();
  }
}

Reliability and Monitoring

Disaster Recovery Strategy

All API calls are wrapped with a custom ajax wrapper that adds caching, timeout, retry, and fallback logic. If a request fails or returns invalid data, a pre‑defined backup endpoint is invoked automatically.

var ajax = require('load_async');
ajax({
  url: '//f.3.cn/index-floor/?argv=aggr',
  jsonpCallback: 'jsonpCallbakcAggr',
  params: {},
  needStore: true,
  storeSign: '3aad2efsdf',
  timeout: 3000,
  times: 2,
  backup: '//www.3.cn/bak/aggr',
  dataCheck: function (result) {
    return result && result.code === 0;
  }
});

Data‑Driven Improvement

The Athena measurement system collects page load timings, user network speed, OS, browser, resolution, and error statistics. These metrics guide decisions such as extending timeout thresholds for slow networks or identifying flaky APIs that need backend attention.

Future Exploration

Static Resource Pre‑Loading

Critical resources for high‑traffic activity pages (e.g., Double‑11 promotions) could be pre‑loaded on the homepage to reduce subsequent navigation latency.

Architecture Upgrade

The team plans to gradually replace the jQuery + Seajs stack with modern module bundlers and frameworks, removing Seajs and adopting more efficient packaging solutions.

Middle‑Layer Exploration

Introducing a middle‑layer service that performs server‑side rendering of selected floors would further decouple front‑end and back‑end, improve first‑screen performance, and simplify caching strategies.