SpeedCurve Performance Budgets: Setting Up Alerts and Thresholds

Performance budgets are one of the most effective tools a web team can adopt. They transform abstract goals like "make the site faster" into concrete, measurable commitments: "LCP must stay below 2.5 seconds." SpeedCurve's performance budget system enforces these commitments automatically — alerting teams the moment a threshold is breached, before users ever complain.

This guide covers how to configure performance budgets in SpeedCurve, set up meaningful alert channels, choose the right threshold types, and integrate budget monitoring into your team's workflow.

What Is a Performance Budget?

A performance budget is a defined limit on one or more performance metrics. If your site exceeds that limit, something needs to change — either the budget gets renegotiated (with intentional tradeoffs) or the regression gets fixed.

Performance budgets work because they make performance a first-class engineering constraint, on par with correctness and security. Without them, performance tends to erode slowly through the accumulation of small decisions — an extra font, a heavier tracking script, an unoptimized image — each individually defensible but collectively damaging.

Common budget types include:

• Timing budgets: LCP < 2.5s, TBT < 300ms, Start Render < 1s
• Size budgets: JavaScript < 300KB, images < 500KB, total page weight < 1MB
• Score budgets: Lighthouse Performance score > 85
• Request budgets: Total HTTP requests < 80

SpeedCurve supports all of these, tied directly to your Synthetic monitoring data.

Setting Up Performance Budgets in SpeedCurve

Navigate to Alerts in the main SpeedCurve navigation, then select Performance Budgets. Click Add Budget to create your first rule.

Budget Configuration Fields

URL filter: Apply the budget to all URLs in your account, or scope it to specific pages. You might have different budgets for your homepage (which must be fast) versus your admin panel (where performance is less critical).

Profile filter: Scope budgets to specific test profiles. A reasonable mobile budget is looser than a desktop budget — or vice versa, depending on your audience. You can create separate budgets for cable vs. 3G connections.

Metric and threshold: Choose a metric and set the maximum (or minimum for scores) acceptable value.

Comparison period: SpeedCurve can evaluate the current result against a rolling median rather than a fixed threshold. This is useful for catching sudden regressions relative to your baseline, rather than failing budgets you've never met.

Severity: Warning (amber) or Critical (red). Use warning for approaching-the-line situations and critical for definitive breaches.

Metric-Based vs. Score-Based Budgets

Metric-based budgets tie directly to Web Vitals and timing measurements:

Score-based budgets use composite scores:

SpeedCurve calculates a performance score that weighs multiple metrics together, similar in spirit to Lighthouse's Performance score. Score-based budgets are good for executive reporting ("our score must stay above 80") but less actionable for engineering — when a score drops, you still need to find which underlying metric is responsible.

For engineering workflows, prefer metric-based budgets. For stakeholder communication, score-based budgets are more legible.

Choosing the Right Thresholds

Setting budgets too tight means constant alert noise; too loose means the budget is meaningless. Here's how to calibrate:

Start with Your Current Performance

Run SpeedCurve for a week before setting budgets. Get a stable baseline for each metric across your pages. Then:

• For "must not regress" thresholds: Set the budget at current median + 10–15%. This catches real regressions without firing on normal variability.
• For aspirational thresholds: Set at Core Web Vitals "Good" targets (LCP < 2.5s, CLS < 0.1, INP < 200ms). These may fail initially, creating a backlog of performance work.

Separate Budgets per Page Type

Don't apply a single budget to all URLs. Your checkout page might have stricter requirements than your blog archive. A product page with images has different constraints than a lightweight landing page.

Create budget groups:

• Critical path (homepage, landing pages, checkout): tightest budgets
• Content pages (blog posts, documentation): moderate budgets
• Supporting pages (contact, about, admin): looser budgets

Account for Test Variability

Synthetic tests aren't perfectly deterministic. Network conditions, server-side variability, and CDN routing can cause metric values to fluctuate by 5–10% between runs. Set thresholds that account for this:

• If your LCP averages 1.8s with ±150ms variability, a budget of 2.5s is solid
• A budget of 2.0s on that same baseline will fire on bad-luck test runs

SpeedCurve's comparison mode (evaluating against the rolling median rather than a fixed value) helps with this by smoothing out noise.

Configuring Alert Channels

Budgets only work if the right people see the alerts. SpeedCurve supports several notification channels.

Slack Integration

This is the most commonly used integration. In SpeedCurve, go to Alerts > Notification Channels > Add Channel > Slack.

You'll need to create an Incoming Webhook in your Slack workspace:

1. Go to your Slack app settings (api.slack.com/apps)
2. Create or select an app, enable Incoming Webhooks
3. Create a new webhook for your chosen channel
4. Copy the webhook URL into SpeedCurve

SpeedCurve Slack alerts include:

• The URL that breached the budget
• Which metric exceeded which threshold
• The actual measured value vs. the budget
• A direct link to the SpeedCurve dashboard for that test

Tip: Create a dedicated #perf-alerts Slack channel rather than routing to #engineering. This keeps performance discussions focused and avoids alert fatigue in busier channels.

Email Notifications

Configure email alerts under Alerts > Notification Channels > Email. You can set up:

• Immediate alerts for critical budget breaches
• Daily digest emails summarizing the performance state of all monitored pages

Email works well for managers and stakeholders who want awareness without being in the real-time notification stream.

Webhook Integration

For custom workflows, SpeedCurve sends a POST request to a URL you provide when a budget is breached or recovers. The payload is JSON:

{
  "event": "budget_breach",
  "severity": "critical",
  "url": "https://example.com/checkout",
  "metric": "lcp",
  "value": 3240,
  "threshold": 2500,
  "profile": "Chrome Cable",
  "timestamp": "2024-01-15T14:32:00Z",
  "dashboard_url": "https://speedcurve.com/..."
}

Common webhook use cases:

• Create a GitHub issue automatically when a budget is breached
• Open a Jira ticket and assign it to the performance owner
• Trigger a PagerDuty incident for critical performance failures
• Post a custom message to a project management tool (Linear, Asana, etc.)

Configure webhooks under Alerts > Notification Channels > Add Channel > Webhook.

Slack Webhook Example (Custom Payload Processing)

If you want more control over the Slack message format, route the SpeedCurve webhook through a small serverless function that reformats the payload before posting to Slack:

// Cloudflare Worker or AWS Lambda
export async function handler(event) {
  const body = JSON.parse(event.body);
  
  const message = {
    text: `⚠️ Performance budget breached`,
    blocks: [
      {
        type: "section",
        text: {
          type: "mrkdwn",
          text: `*${body.metric.toUpperCase()}* exceeded budget on \`${body.url}\`\n` +
                `Measured: *${body.value}ms* | Budget: ${body.threshold}ms\n` +
                `<${body.dashboard_url}|View in SpeedCurve>`
        }
      }
    ]
  };

  await fetch(process.env.SLACK_WEBHOOK_URL, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(message)
  });
}

Integrating Performance Budgets into Team Workflows

Alerts are only the starting point. The goal is to make performance budgets part of how your team ships software.

Assign a Performance Owner

Every budget breach should have a clear owner — someone who triages the alert, determines the cause, and either fixes it or escalates. Without explicit ownership, alerts get acknowledged and ignored.

Options:

• Rotating on-call: A weekly rotation where one engineer is the "performance owner" responsible for triaging alerts
• Feature team ownership: Each team owns the performance of the pages they build
• Dedicated performance team: In larger organizations, a dedicated web performance team handles all budget breaches

Create a Budget Breach SLA

Define how quickly budget breaches must be addressed:

• Critical breach (> 50% over threshold): Fix within 24 hours or revert
• Warning breach (10–50% over threshold): Address within the current sprint
• Near-miss (within 10% of threshold): Add to backlog for the next sprint

Document this SLA somewhere visible — your engineering handbook, a README, or a performance playbook.

Use Budget Data in Sprint Planning

Weekly performance data should appear in sprint planning and retrospectives. Questions to ask:

• Which pages are consistently near their budget limits?
• Did any recent deploys cause budget breaches?
• Are there trends suggesting gradual degradation?

SpeedCurve's trend charts make it easy to see which metrics are slowly creeping toward thresholds — catching problems before they become breaches.

Separate Monitoring from CI Gates

SpeedCurve's continuous monitoring operates independently of your deployment pipeline. This is appropriate for catching regressions that develop over time (third-party script weight growing, server response times drifting).

For catching regressions at deploy time, combine SpeedCurve monitoring with a CI integration that tests new code before it ships (covered in a separate guide). The two approaches are complementary:

• CI gates: Catch regressions before they deploy
• Continuous monitoring: Catch regressions from third-party changes, CDN issues, and gradual drift

Advanced Budget Configuration

Budget Templates

Once you've established a solid set of budgets for one site, SpeedCurve lets you apply similar configurations to other sites or URLs without recreating everything from scratch. Export your budget configuration from one site and use it as a starting point for another.

Anomaly Detection vs. Fixed Thresholds

SpeedCurve's comparison mode evaluates current performance against a rolling baseline rather than a fixed number. This is useful when you can't set a meaningful absolute threshold — for example, a page that has highly variable load times depending on user data.

With anomaly detection:

• A sudden 30% increase in LCP triggers an alert, even if the absolute value is within budget
• A page that's always been slow doesn't trigger constant alerts
• Noise from individual outlier runs is smoothed out by looking at the rolling median

Multi-Metric Budgets

Some performance problems only manifest in combinations — LCP might be acceptable but TBT is high AND page weight has spiked. While SpeedCurve doesn't support compound budget rules natively, you can approximate this by setting individual budgets on each metric and using the alert channel to build a custom aggregation view.

Common Mistakes with Performance Budgets

Setting budgets and forgetting them: Budgets need periodic review. As your site evolves, some budgets become too easy (not meaningful) and others become impossible (constantly triggering). Review and adjust quarterly.

Too many alerts: If engineers see 20 budget alerts a day, they'll start ignoring all of them. Start with 3–5 critical budgets, prove the workflow, then expand.

Budgets without investigation process: A budget alert is useless if nobody knows what to do when they see it. Document your triage process before you turn on alerts.

Not celebrating budget recoveries: When a team fixes a budget breach, acknowledge it. SpeedCurve sends recovery alerts too — route these to Slack with a positive message. Performance work is often invisible; make it visible.

Conclusion

Performance budgets in SpeedCurve give teams a structured, automated way to hold themselves accountable for web performance. The combination of granular thresholds, flexible alert channels, and continuous trend data means breaches are caught early — before they impact users or search rankings.

Start simple: pick your three most important metrics, set achievable thresholds, and connect Slack notifications to a dedicated channel. Let the data teach you where the problems are, then add more specific budgets as your performance monitoring practice matures.

The goal isn't to have perfect budgets from day one — it's to create a feedback loop that catches regressions fast and gives your team the information to fix them.