How Fliggy Cut Double‑11 Frontend Load Time by 25% with Rax, SSR, and Snapshot

Background

In front‑end development, performance directly influences user experience and business conversion; a one‑second increase in page load time can cause a 10% drop in users. For the Double‑11 event, Fliggy aimed to surpass the performance of its previous Weex implementation.

Challenges

The migration from Rax 0.6 on Weex to Rax 1.0 on Web introduced new performance constraints. The venue module includes videos, animations, multiple tabs, and long lists, with high request latency and limited server‑side optimization opportunities. Travel‑industry specifics such as location and user data further slowed first‑screen rendering, and the team set a target of a 25% performance improvement over daily venues.

Optimization Directions

The team collaborated across client, server, and other business units, focusing on three main areas:

Pre‑render, offline packages, and Data‑Prefetch with the client team.

Serverless‑side rendering (SSR) to shift rendering load to the server.

Snapshot caching (both HTML and interface caches) and SPA techniques to improve perceived speed.

Technical Implementations

1. End‑side Pre‑render

By initializing a WebView off‑screen and rasterizing the page before it becomes visible, the first contentful paint (FCP) dropped from 1–2 seconds to under 100 ms, creating an almost imperceptible opening experience.

2. Serverless‑side Rendering (SSR)

SSR delivers a complete HTML page from the server, reducing module loading and rendering time. In the Double‑11 scenario, SSR cut first‑screen visible time by more than 1 second and increased the “instant‑open” rate to over 60% for most venues.

3. Snapshot Caching

Two Snapshot strategies were applied: HTML cache for venues with stable content and interface cache for dynamic venues, eliminating loading states and achieving near‑instant page display.

4. SPA‑style Tab Navigation

By aggregating multiple sub‑venues into a single page and rendering each tab’s DOM directly, the team removed white‑screen flashes during tab switches, delivering seamless navigation especially on high‑end devices.

5. Resource & Data Pre‑caching

Using the Fcache mechanism, static resources were pre‑downloaded to the client, while Data‑Prefetch initiated data requests ahead of navigation, reducing network latency.

6. Monitoring & Diagnosis

Real‑time performance dashboards, hourly venue performance charts, and slow‑session tracing tools were built to continuously track and troubleshoot performance anomalies.

Results

All Double‑11 venues achieved the target: first‑screen time decreased by 25% compared to daily venues and by 20% versus the 618 and National Day events. SSR‑enabled venues reached sub‑1‑second first‑screen times, with the ticket venue achieving a 75% instant‑open rate.

Future Plans

Further SSR optimization (including A/B testing and faster server execution), multi‑WebView tab switching, PHA integration, and enhanced monitoring facilities are planned to sustain and extend performance gains.