Front‑End Performance Monitoring: Metrics, Types, and Data Collection

Front‑end performance monitoring helps developers understand website health, detect problems early, and drive optimizations that improve stability and user experience.

1. Why monitor front‑end performance

Detect issues as soon as they appear, often before users report them.

Gain a comprehensive view of performance data to guide systematic optimization.

Improve perceived speed by reducing content display latency and interaction delay.

2. Types of front‑end performance monitoring

Two main categories are discussed:

Synthetic monitoring – Simulates user scenarios (e.g., Google Lighthouse) to collect metrics such as hardware info and waterfall charts.

Real‑user monitoring (RUM) – Captures actual user interactions and sends data to a backend for aggregation and analysis.

Advantages and disadvantages of each are compared in tables, highlighting differences in implementation cost, data richness, sample size, and suitable scenarios.

3. Key performance metrics

LCP (Largest Contentful Paint) – Time until the biggest visible element is rendered.

FID (First Input Delay) – Delay between the first user interaction and the browser’s response.

CLS (Cumulative Layout Shift) – Visual stability measured by unexpected layout movements.

Additional metrics: FCP, TTFB, Speed Index, Total Blocking Time, etc.

Each metric is explained with its significance and typical thresholds (e.g., a good CLS score is <0.1 for 75% of users).

4. Data collection methods

4.1 web‑vitals library

Install and use the official web-vitals package to obtain LCP, FID, CLS, FCP, and TTFB directly in the browser.

npm install web-vitals

import { getLCP, getFID, getCLS, getFCP, getTTFB } from 'web-vitals';
getCLS(console.log);
getFID(console.log);
getLCP(console.log);

4.2 Performance API

The W3C Navigation Timing API provides low‑level timestamps (navigationStart, fetchStart, responseStart, domInteractive, loadEventStart, etc.) that can be combined to compute classic performance indicators such as DNS lookup time, TCP connection time, TTFB, DOM parsing time, and first paint.

Example of retrieving the timing object:

console.log(window.performance.timing);

Common helper methods include performance.getEntries() , performance.getEntriesByType(type) , performance.getEntriesByName(name, type) , and performance.now() for high‑resolution timestamps.

4.3 Error collection

JavaScript errors can be captured with window.onerror :

/**
 * JS error capture
 */
window.onerror = (msg, url, lineNo, columnNo, error) => {
  console.log(error.stack);
  // custom handling
};

Vue-specific errors require Vue.config.errorHandler :

/**
 * Vue error capture
 */
Vue.config.errorHandler = (error) => {
  console.log(error);
  // custom handling
};

API request errors (e.g., using Axios) can be handled via .catch or a global interceptor:

axios.post(url, data)
  .then(response => { /* ... */ })
  .catch(error => {
    console.log(error);
    // custom handling
  });

Axios.interceptors.response.use(
  response => response,
  error => {
    console.log(error);
    // custom handling
    return Promise.reject(error);
  }
);

These techniques provide the raw data needed for performance analysis and subsequent optimization.

5. Summary

The article outlines why front‑end monitoring is essential, distinguishes synthetic and real‑user approaches, enumerates core metrics (LCP, FID, CLS, etc.), and presents practical ways to collect data using the web-vitals library, the native Performance API, and error‑tracking hooks. Armed with these insights, developers can systematically improve page load speed, interactivity, and visual stability.