Front‑End Performance Optimization: Metrics, Data Reporting, and Practical Improvements

This is the sixth article in our team’s engineering series, focusing on how to take ownership of and complete front‑end performance optimization work. It outlines the preparation steps, metric definition, data reporting, dashboard construction, bottleneck analysis, and practical solutions.

Metric Definition and Target Setting

We discuss common web performance metrics such as First Contentful Paint (FCP), Largest Contentful Paint (LCP), and Time to Interactive (TTI). Because our B‑side users care most about when core data becomes visible, we adopt TTI as a reference but define a simplified, business‑specific metric called x‑fmp (core interface completion time). The formula is:

x‑fmp = core API end time - navigationStart

Based on the definitions, x‑fmp should be less than 4 seconds (approximately 2 s + API time (0‑2 s) ).

Performance Data Reporting

We built a unified performance reporting tool that integrates with the project’s axios interceptor or umi‑request middleware. The tool automatically captures window.performance.timing , core API paths, and their durations, then reports them as custom events to our internal monitoring platform (Slardar).

Data Aggregation and Anomaly Handling

After data collection, we aggregate by page ID, environment, and source. We pay special attention to:

Normalizing page URLs to avoid fragmented statistics.

Distinguishing production from test environments.

Ensuring only real user traffic is counted (e.g., filtering out automated white‑screen checks).

Dashboard Construction

We created dashboards to visualize the overall trend of x‑fmp and related metrics, as well as per‑page or per‑project breakdowns. The dashboards include:

Core page PV and performance indicator board.

User attribute and static resource loading time board.

Performance Bottleneck Analysis

Network Layer

HTML loading (0‑446 ms) accounts for only ~7% of total time, but the waiting‑for‑server‑response can reach 511 ms. TTFB varies by region: US ~400 ms, Singapore ~30 ms, China/UK ~300 ms, Brazil ~450 ms, indicating a need for caching and multi‑region edge nodes.

CDN loading shows parallel limits: after six concurrent resources, remaining chunks load serially, and many chunks still fetch from the Singapore origin due to low cache‑hit rates (<20%). This causes long‑tail delays, especially for large chunks (>1 MB).

Application Layer

Packaging : Analysis with Perfsee reveals 45 duplicate bundles (600 KB‑1 MB gzipped). Some pages have only three chunks, each ~1 MB, leading to >1 minute load times on poor networks.

Caching : Multi‑language resources and enumeration/config APIs block rendering. Since these are static, they can be cached locally and refreshed lazily.

Code :

useEffect(() => {
  ;(async () => {
    try {
      setLoading(true);
      if (id) {
        const config = await fetchAPI(apis.quote.getConfig, { quoteId: id });
        setBaseConfig(config);
        const detail = await fetchAPI(apis.quote.getDetail, { id });
        setDetail(detail);
        setAdvId(detail.advertiserId);
      }
    } catch (error) {
      logger.error(error, { loggerId: 40 });
    } finally {
      setLoading(false);
    }
  })();
}, [id, detailFlag]);

The above serial await calls cause unnecessary blocking; they should be executed in parallel when there is no dependency.

// Example of parallel API calls
const [config, detail] = await Promise.all([
  fetchAPI(apis.quote.getConfig, { quoteId: id }),
  fetchAPI(apis.quote.getDetail, { id })
]);
setBaseConfig(config);
setDetail(detail);

Component rendering accounts for ~400 ms (≈10% of total). Optimizations such as useMemo , useCallback , and reducing unnecessary re‑renders can further improve x‑fmp.

Conclusion

The article covered the preparatory work and analysis for front‑end performance optimization. The next installment will address the identified problems with concrete solutions and more technical details.

Read the follow‑up article: 100+ Applications Load 50% Faster – International Business Platform Performance Optimization (Part 2)