Web Performance Metrics Explained: Beyond Core Web Vitals

Introduction

While Core Web Vitals get most attention, they're only part of the performance picture. To fully understand and optimize your website's performance, you need to understand the complete metrics landscape.

This guide explains all important web performance metrics and how to improve them.

Performance Metrics Categories

1. Loading Metrics - How fast the page loads
2. Interactivity Metrics - How fast the page responds
3. Stability Metrics - How stable the layout is
4. Custom Metrics - Business-specific measurements

Loading Metrics

Time to First Byte (TTFB)

What it measures: Time from request to first byte received.

Components:

TTFB = Redirect Time + DNS Lookup + TCP Connection + TLS Negotiation + Server Processing

Targets:

• Excellent: Under 200ms
• Good: 200-500ms
• Poor: Over 500ms

How to improve:

• Use faster hosting
• Enable server-side caching
• Use CDN
• Reduce database queries
• Optimize server code

First Contentful Paint (FCP)

What it measures: Time when first content is painted to screen.

What counts:

• Text
• Images (including background images)
• SVG
• Non-white canvas

Targets:

• Excellent: Under 1.0s
• Good: 1.0-1.8s
• Poor: Over 1.8s

How to improve:

• Reduce server response time
• Minimize render-blocking resources
• Defer non-critical CSS/JS
• Optimize above-the-fold content

Largest Contentful Paint (LCP)

What it measures: Time to render the largest content element.

Core Web Vital - Google ranking factor

Targets:

• Good: Under 2.5s
• Needs improvement: 2.5-4s
• Poor: Over 4s

How to improve:

• Optimize images (WebP, lazy load)
• Preload important resources
• Improve server TTFB
• Remove render-blocking JS

Speed Index (SI)

What it measures: How quickly visual content is displayed.

Calculated by: Comparing visual progress frames during load.

Targets:

• Excellent: Under 3.4s
• Good: 3.4-5.8s
• Poor: Over 5.8s

How to improve:

• Optimize above-the-fold content
• Use progressive image loading
• Minimize critical rendering path
• Implement skeleton screens

Interactivity Metrics

First Input Delay (FID)

What it measures: Time from user interaction to browser response.

Core Web Vital - Google ranking factor

Note: Only measures first interaction (click, tap, keypress)

Targets:

• Good: Under 100ms
• Needs improvement: 100-300ms
• Poor: Over 300ms

How to improve:

• Reduce JavaScript execution
• Split code into smaller chunks
• Defer non-critical JS
• Use Web Workers

Time to Interactive (TTI)

What it measures: Time when page is fully interactive.

Definition: Window of 5 seconds where:

• FCP has occurred
• No long tasks (>50ms) for 5 seconds
• Network requests complete

Targets:

• Excellent: Under 3.8s
• Good: 3.8-7.3s
• Poor: Over 7.3s

How to improve:

• Reduce JavaScript bundle size
• Defer non-critical scripts
• Code splitting
• Optimize third-party scripts

Total Blocking Time (TBT)

What it measures: Total time main thread is blocked.

Relationship to FID:

• TBT is lab metric (measured in tools)
• FID is field metric (measured by real users)
• Both relate to main thread blocking

Calculation:

TBT = Sum of all long tasks (>50ms) after FCP
(Only count time beyond 50ms for each task)

Targets:

• Excellent: Under 200ms
• Good: 200-600ms
• Poor: Over 600ms

How to improve:

• Reduce JavaScript execution time
• Break up long tasks
• Optimize event handlers
• Use Web Workers

Stability Metrics

Cumulative Layout Shift (CLS)

What it measures: Visual stability during page load.

Core Web Vital - Google ranking factor

Calculation:

CLS = Sum of (impact fraction * distance fraction) for all layout shifts

Targets:

• Good: Under 0.1
• Needs improvement: 0.1-0.25
• Poor: Over 0.25

How to improve:

• Reserve space for images (width/height)
• Use aspect-ratio CSS
• Avoid inserting content above existing content
• Reserve space for ads

Layout Shift (Individual)

What it measures: Single layout shift event.

Components:

• Impact Fraction: How much of viewport affected
• Distance Fraction: How far elements moved

Example:

Element covers 50% of viewport (0.5)
Moves down 25% of viewport (0.25)
Score = 0.5 * 0.25 = 0.125

Network Metrics

DNS Lookup Time

What it measures: Time to resolve domain to IP.

Targets:

• Excellent: Under 50ms
• Good: 50-200ms
• Poor: Over 200ms

How to improve:

• Use faster DNS provider
• DNS preconnect
• DNS prefetching

TCP Connection Time

What it measures: Time to establish TCP connection.

Targets:

• Excellent: Under 50ms
• Good: 50-150ms
• Poor: Over 150ms

How to improve:

• Use CDN (reduce distance)
• HTTP/2 or HTTP/3
• Optimize server response

TLS Negotiation Time

What it measures: Time for SSL/TLS handshake.

Targets:

• Excellent: Under 50ms
• Good: 50-150ms
• Poor: Over 150ms

How to improve:

• Use modern TLS (1.2+)
• OCSP stapling
• Optimized certificate chain

Resource Timing Breakdown

// Measure resource timing
performance.getEntriesByType("resource").forEach((resource) => {
  console.log({
    name: resource.name,
    dns: resource.domainLookupEnd - resource.domainLookupStart,
    tcp: resource.connectEnd - resource.connectStart,
    tls:
      resource.secureConnectionStart > 0
        ? resource.connectEnd - resource.secureConnectionStart
        : 0,
    ttfb: resource.responseStart - resource.requestStart,
    download: resource.responseEnd - resource.responseStart,
    total: resource.duration,
  });
});

Rendering Metrics

First Paint (FP)

What it measures: Time when any pixel is rendered.

Includes: Background colors, borders - anything visible.

Targets:

• Excellent: Under 1.0s
• Good: 1.0-2.0s
• Poor: Over 2.0s

First Meaningful Paint (FMP)

What it measures: Time when primary content is visible.

Note: Deprecated in favor of LCP, but still useful.

Definition: Paint after which biggest layout change occurs.

Resource Metrics

Total Page Size

Measurement: Total size of all resources loaded.

Targets by page type:

• Landing page: Under 1MB
• Blog post: Under 2MB
• Photo gallery: Under 3MB
• E-commerce: Under 2MB

Total Request Count

Measurement: Number of HTTP requests made.

Targets:

• Excellent: Under 50 requests
• Good: 50-100 requests
• Poor: Over 100 requests

How to reduce:

• Combine CSS/JS files
• Use sprites for icons
• Remove unused resources
• Use data URIs for small images

JavaScript Size

Measurement: Total size of JavaScript files.

Targets:

• Excellent: Under 200KB gzipped
• Good: 200-400KB gzipped
• Poor: Over 400KB gzipped

CSS Size

Measurement: Total size of CSS files.

Targets:

• Excellent: Under 50KB gzipped
• Good: 50-100KB gzipped
• Poor: Over 100KB gzipped

Custom Metrics

Hero Element Timing

Measure specific element visibility:

// Performance Observer for Element Timing
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(`${entry.identifier} rendered at ${entry.renderTime}`);
  }
});

observer.observe({ entryTypes: ["element"] });

<div elementtiming="hero-image">...</div>

Custom User Timings

// Mark specific events
performance.mark("feature-start");

// ... feature code ...

performance.mark("feature-end");
performance.measure("feature", "feature-start", "feature-end");

// Get measurement
const measure = performance.getEntriesByName("feature")[0];
console.log(`Feature took ${measure.duration}ms`);

Monitoring Tools

Lab Tools (Synthetic Testing)

• Lighthouse - Chrome DevTools, automated
• WebPageTest - Detailed waterfall charts
• GTmetrix - Comprehensive analysis

Field Tools (Real User Monitoring)

• Core Web Vitals Report - Chrome User Experience Report
• PageSpeed Insights - Real user data + lab data
• Search Console - Core Web Vitals report

Continuous Monitoring

// Real User Monitoring (RUM) setup
function trackWebVitals() {
  // LCP
  new PerformanceObserver((list) => {
    const lastEntry = list.getEntries().pop();
    sendToAnalytics({ metric: "LCP", value: lastEntry.startTime });
  }).observe({ type: "largest-contentful-paint", buffered: true });

  // FID
  new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      sendToAnalytics({
        metric: "FID",
        value: entry.processingStart - entry.startTime,
      });
    }
  }).observe({ type: "first-input", buffered: true });

  // CLS
  let clsValue = 0;
  new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      if (!entry.hadRecentInput) {
        clsValue += entry.value;
        sendToAnalytics({ metric: "CLS", value: clsValue });
      }
    }
  }).observe({ type: "layout-shift", buffered: true });
}

Performance Budgets

Set specific budgets for different resources:

// Example performance budgets
const budgets = {
  // Resource sizes
  scriptSize: 200 * 1024, // 200KB
  styleSize: 50 * 1024, // 50KB
  imageSize: 500 * 1024, // 500KB
  totalSize: 1000 * 1024, // 1MB

  // Timing metrics
  ttfb: 200, // 200ms
  fcp: 1000, // 1s
  lcp: 2500, // 2.5s
  tti: 3800, // 3.8s
  tbt: 200, // 200ms
  cls: 0.1, // 0.1

  // Resource counts
  totalRequests: 50,
  scriptCount: 10,
  styleCount: 3,
};

Conclusion

Understanding web performance metrics is essential for optimization. Start with Core Web Vitals (LCP, FID, CLS) for Google rankings, then expand to other metrics for a complete performance picture.

Measure regularly, set budgets, and iterate on improvements. Performance is a continuous journey, not a destination.

Get a complete performance analysis with all these metrics measured and prioritized recommendations for your site.