How Alibaba Cloud Security Achieved Sub‑Second Front‑End Performance with PWA and PCP
Alibaba Cloud Security’s front‑end team tackled the “1‑second battle” by redefining performance with the PCP metric and leveraging PWA techniques—service workers, skeleton screens, aggressive code‑splitting, and micro‑frontend architecture—to shrink perceived load times from seconds to sub‑400 ms across eight products.
Background
Last year Alibaba Cloud launched a "1‑second battle" for its cloud‑security console, demanding that the product start within one second. Typical JavaScript bundles are around 8 MB, and parsing, compiling, and executing them takes 0.6–1 s on average PCs. Since many users have devices at least twice as slow, the team focused on perceptual performance rather than raw physical metrics, defining the PCP (Perceivable Contentful Paint) indicator with a target of 1.5 s. The ultimate goal became a perceived "0 s" experience, meaning the page feels instantly ready.
Effect
The team chose Progressive Web Apps (PWA) over SSR, exploiting Service Workers and high‑precision skeleton screens. By caching aggressively and reducing TTFB to 218 ms, the average page load dropped to 639 ms, and after full Service Worker activation it fell another ~200 ms, reaching sub‑400 ms—effectively a "0 s" perceived experience.
Result
Eight cloud‑security products met the 1‑second target, with average load times reduced by 0.5–0.7 s. Continuous monitoring shows the proportion of users experiencing PCP < 1 s steadily increasing, confirming the impact on overall user satisfaction.
Implementation
Optimization centered on the Critical Rendering Path (CRP). All static assets use strong HTTP caching and gzip. The <head> was trimmed to keep only CSS required for initial render, deferring JavaScript. Key principles: "As little as possible, as early as possible." Early actions include launching the Service Worker before any page request and displaying a skeleton screen while the main bundle loads. The team achieved a total pre‑render time under 300 ms (TTFB = 218 ms, page size ≈ 20 KB, download ≈ 28 ms). Later actions focused on shrinking resources: replacing Moment with day.js, on‑demand Lodash imports, selective core‑js polyfills, separating stable libraries (React, Dva, charting, component libraries) into their own bundles, on‑demand map data, route‑based code splitting, and migrating to micro‑frontends, which cut main‑app size by roughly 50 %.
Redundant text and CSS were also pruned, with about 40 % of UI copy identified as unnecessary. Loading‑stage improvements followed the PRPL model.
Browser‑Side Skeleton Screen Solution
In the console scenario, multiple versions, languages, and regions require a highly simplified skeleton UI. At runtime, the appropriate skeleton is generated per account and cached locally. The strategy is cache‑first: if a cached skeleton exists it is shown immediately; otherwise a default skeleton appears. When the main application script loads, it hydrates the skeleton for a smooth transition. Each skeleton consumes about 500 KB and is automatically cleared after seven days, with caching limited to main entry routes.
Future Work
The next steps include deepening Service Worker support for B‑end products, exploring Webpack Module Federation, and implementing concurrent data‑request patterns. Additional performance work targets large‑client optimizations, white‑screen mitigation, and jitter reduction, with experience management now a core front‑end responsibility.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.