How DeWu’s Frontend Platform Built an Effective Performance Monitoring System
This article explains why front‑end performance is critical, outlines the most cost‑effective metrics such as FCP, TTS, and TSP, describes the SDK‑SLS‑Backend architecture, shares key technical decisions, and proposes future enhancements for a robust monitoring solution.
Why Performance Matters
For front‑end developers, user experience hinges on performance; metrics like page load speed and smoothness directly affect perceived quality. An accurate, timely, and effective performance monitoring system can quantify current page performance, validate optimization impact, and trigger alerts when performance degrades.
Chosen Monitoring Metrics
01. First Contentful Paint (FCP)
FCP is a widely adopted metric for measuring page load speed. Although it is less user‑centric than First Meaningful Paint (FMP) or Largest Contentful Paint (LCP), it can be obtained on Android via the Performance API and on iOS via requestAnimationFrame, making implementation simple.
02. Time to Server (TTS)
TTS measures the time from the browser initiating a request to the server receiving it, calculated as requestStart - fetchStart. While front‑end code cannot reduce this value, it reveals the network ceiling for page‑open rates; for example, if 15% of users need ≥1 s to connect, the maximum possible instant‑open rate is 85%.
03. Time for Server Processing (TSP)
TSP applies to SSR scenarios and is derived from responseStart - requestStart. Excessive TSP becomes a bottleneck for instant‑open rates, so it must be monitored and balanced against server operation costs.
04. Resource Size & XHR Duration
Large CSS, image files, and long‑lasting XHR requests can prevent a page from becoming usable even after a fast initial load. For SPA pages that rely heavily on backend data, XHR latency is critical and should trigger backend optimization when it degrades.
05. Environment Information
Collecting device model, OS, browser, or in‑app WebView details helps reproduce performance issues accurately.
System Architecture
The monitoring system consists of the following modules:
SDK : Embedded in pages to collect performance data and basic user info, sending data to SLS according to a defined transmission strategy without requiring page‑code interaction.
SLS : Alibaba Cloud Log Service that receives SDK data, appends timestamps, IP, and other metadata.
Backend : Periodically pulls raw logs from SLS, deduplicates and processes them into performance metrics and user‑info tables, and provides APIs for data visualization.
DB : Stores processed performance logs and metric tables.
Report : Generates performance dashboards for specific projects, versions, or pages.
The relationship among modules is illustrated below:
Key Technical Decisions
Because the unload event is unreliable on mobile, the SDK sends data intermittently, with a gradually increasing interval; after a certain page‑open duration, the SDK stops sending.
Fingerprinting uses FingerPrintJS2 with unstable browser features removed; deduplication combines fingerprint, client timestamp, and IP to filter duplicate logs.
Synchronous SDK code is wrapped in try…catch to prevent crashes from breaking the page.
Only the top‑10 largest images and top‑10 longest XHR requests are recorded in detail to keep data volume manageable while still reflecting resource load characteristics.
Raw logs are sent to SLS to avoid the high cost of building a proprietary log server.
Backend services are built with Python + Django; using PyPy and multi‑process/threading improves processing speed on modest hardware.
Sampling: for each day, only 5% of logs are processed, with a maximum of 1,000 entries per sample, ensuring random coverage while reducing computation.
MySQL is chosen for persistence due to modest I/O requirements.
Future Development Plans
Frame‑rate statistics: currently the SDK can capture frame rates, but raw data volume is high; future work will report only stutter intervals and aggregated frame‑rate distributions.
Adopt more scientific metrics such as LCP and FMP to replace FCP.
Combine pageName in deduplication logic to improve uniqueness filtering.
The current system meets daily monitoring needs, and the outlined enhancements aim to provide deeper insight and more precise performance optimization.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
DeWu Technology
A platform for sharing and discussing tech knowledge, guiding you toward the cloud of technology.
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.
