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.

DeWu Technology
DeWu Technology
DeWu Technology
How DeWu’s Frontend Platform Built an Effective Performance Monitoring System

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.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

frontendSDKarchitectureSSRPerformance Monitoringweb‑metricsSLS
DeWu Technology
Written by

DeWu Technology

A platform for sharing and discussing tech knowledge, guiding you toward the cloud of technology.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.