Performance Monitoring

Website Speed Monitoring: Metrics That Actually Matter

Website speed monitoring beyond PageSpeed scores. Learn which performance metrics actually impact users and revenue, and how to track them continuously.

AzMonitor TeamFebruary 5, 20257 min read · 946 wordsUpdated January 20, 2026
website speedperformance monitoringpage speedweb performance

Most teams treat website speed monitoring as a periodic activity — run PageSpeed Insights when something feels slow, celebrate a good score, forget about it for six months. Real performance monitoring is continuous, covers the metrics that correlate with user behavior, and catches regressions before users notice them.

The Metrics That Actually Predict User Behavior

Not all performance metrics are equally important. Research from Google, Akamai, and multiple large-scale studies has identified the metrics with the strongest correlation to user behavior:

| Metric | User Behavior Impact | Revenue Impact | |--------|---------------------|----------------| | LCP (Largest Contentful Paint) | Bounce rate, engagement | Direct (e-commerce) | | INP (Interaction to Next Paint) | Task completion, satisfaction | Conversion rate | | TTFB (Time to First Byte) | Perceived performance, SEO | Indirect | | FCP (First Contentful Paint) | Perceived load speed | Engagement | | CLS (Cumulative Layout Shift) | Mis-clicks, frustration | Conversion | | Total Blocking Time (TBT) | Interactivity, engagement | Conversion |

Metrics NOT in this list that teams over-focus on:

  • PageSpeed Score: Composite score that's useful for direction but not directly correlated with user behavior
  • Page size in MB: Matters less than how efficiently it loads
  • Number of requests: Matters less with HTTP/2 and HTTP/3

Time to First Byte (TTFB)

TTFB is the time from the browser sending an HTTP request to receiving the first byte of the response. It's the foundational metric — everything else depends on it.

Good TTFB threshold: < 800ms (Google's "Good" threshold for TTFB)

What affects TTFB:

  • Server processing time (database queries, server-side rendering)
  • Network latency to the server (geographic distance)
  • DNS resolution time
  • SSL handshake time
  • CDN cache hit/miss

A TTFB below 200ms is excellent. Above 800ms suggests meaningful optimization opportunity.

First Contentful Paint (FCP)

FCP marks when the browser first renders any content — text, images, SVGs, or canvas elements. It signals to the user that the page is loading.

Good FCP threshold: < 1.8 seconds

What affects FCP:

  • TTFB (FCP can't happen before the server responds)
  • Render-blocking resources (CSS, synchronous JavaScript in the <head>)
  • Font loading strategy

Monitoring Speed by Page Type

Different page types have different performance baselines and priorities:

Homepage

  • Priority: High (first impression, SEO landing page)
  • Key metrics: LCP, FCP, TTFB
  • Typical acceptable LCP: < 2.5 seconds

Product/Category Pages (E-commerce)

  • Priority: Critical (directly drives revenue)
  • Key metrics: LCP (product image), INP (filter/sort interactions), CLS
  • Typical acceptable LCP: < 2.5 seconds

Checkout Flow

  • Priority: Critical (conversion moment)
  • Key metrics: INP (form interactions), TTFB for API calls
  • Note: Checkout is often behind auth; use synthetic monitoring with auth

Blog/Content Pages

  • Priority: Medium (SEO, retention)
  • Key metrics: LCP, CLS
  • Typical acceptable LCP: < 2.5 seconds

Single Page Application (SPA) Dashboard

  • Priority: High (core product)
  • Key metrics: INP (all interactions), TTFB for data API calls
  • Note: SPAs often have good initial load but poor INP due to heavy JavaScript

Setting Up Continuous Speed Monitoring

The key word is "continuous." Periodic speed checks don't catch the regression introduced by Tuesday's deployment. Continuous monitoring does.

Configure performance monitors in AzMonitor:

monitors:
  - name: "Homepage Performance"
    type: performance
    url: https://yoursite.com
    schedule: every_6_hours
    thresholds:
      lcp_ms: 2500
      fcp_ms: 1800
      ttfb_ms: 800
      cls: 0.1
    alert_on_regression: true
    regression_threshold: 20%  # Alert if any metric worsens by 20%+

  - name: "Product Page Performance"
    type: performance
    url: https://yoursite.com/products/featured
    schedule: every_6_hours
    thresholds:
      lcp_ms: 2500
      inp_ms: 200

Alert on regression, not just threshold breach: Set up alerts for relative degradation ("LCP is 35% worse than 7-day average") in addition to absolute thresholds. A page going from 800ms LCP to 1,100ms LCP is still within the "Good" threshold, but 37% worse than before — often indicating a new performance problem.

The Performance Budget Approach

Performance budgets set explicit limits for performance metrics per page. Any build that exceeds the budget fails:

{
  "resourceSizes": [
    { "resourceType": "script", "budget": 300 },
    { "resourceType": "total", "budget": 1000 }
  ],
  "timings": [
    { "metric": "lcp", "budget": 2500 },
    { "metric": "fcp", "budget": 1800 },
    { "metric": "cls", "budget": 0.1 }
  ]
}

Performance budgets enforced in CI/CD prevent performance regressions from reaching production. See our performance budget monitoring guide for implementation details.

Speed Monitoring by Geography

Your performance varies significantly by user location. A page served from US-East loads in 1.5 seconds for New York users and 3.5 seconds for Singapore users if you're not using a CDN.

Monitor performance from multiple geographic locations to understand your global performance:

| Location | Baseline LCP | With CDN | Without CDN | |---------|-------------|----------|-------------| | New York | 1.2s | 1.2s | 1.2s | | London | 1.8s | 1.6s | 2.8s | | Singapore | 2.1s | 1.9s | 4.5s | | São Paulo | 2.4s | 2.0s | 5.2s |

AzMonitor runs performance checks from multiple global nodes, giving you geographic performance data that PageSpeed Insights (which only tests from a US location) doesn't provide.

Turning Speed Data into Action

Speed monitoring is only valuable if it drives improvement. Create a performance improvement process:

  1. Weekly review: Check performance trends in your monitoring dashboard
  2. Regression triage: Investigate any metric that degraded by > 20% week-over-week
  3. Correlation with deploys: Cross-reference performance changes with deployment timestamps
  4. Prioritization: Focus on the highest-traffic pages and the metrics with strongest revenue correlation

Start monitoring your website speed with AzMonitor and see your performance baseline across 20+ global locations. Know the moment a deployment hurts performance before users do.

Tags:website speedperformance monitoringpage speedweb performance
Back to blog
A
AzMonitor Team
The AzMonitor team writes guides based on experience monitoring millions of endpoints daily across 10,000+ customer environments. Our expertise covers uptime monitoring, SRE practices, and reliability engineering.
Try AzMonitor free

3 monitors free forever · No credit card needed · Set up in 2 minutes

Start monitoring free →