Getting Started with SpeedCurve: Setup and First Performance Budget

Web performance has a direct impact on user experience, conversion rates, and search rankings. But tracking it consistently — across browsers, devices, and deployment cycles — requires more than a one-off Lighthouse run. SpeedCurve was built to solve exactly that problem: it gives teams continuous, automated visibility into how fast their site is, and where it's slowing down.

This guide walks you through getting started with SpeedCurve from scratch — account setup, connecting your first site, configuring Synthetic monitoring, and creating a performance budget that will keep your team accountable.

What Is SpeedCurve?

SpeedCurve is a web performance monitoring platform founded by Steve Souders and Mark Zeman. It combines two complementary data sources:

• Synthetic monitoring: Automated browser tests run from real locations on a schedule (every hour, every day). These give you controlled, reproducible measurements that are ideal for catching regressions before users do.
• Real User Monitoring (RUM): Field data collected from actual visitors via a lightweight JavaScript snippet called LUX. This shows you what users actually experience, including long-tail slowness that lab tests miss.

Together, these two approaches give you a complete picture — lab conditions for debugging, real-world data for prioritization.

Step 1: Create Your SpeedCurve Account

Go to speedcurve.com and sign up for a trial. SpeedCurve offers a 30-day free trial with no credit card required, giving you access to Synthetic monitoring with a reasonable test frequency.

After signing in, you land on the main dashboard. It's empty at first — you'll need to add a site before anything useful appears.

Step 2: Add Your First Site

Click Add Site (or navigate to Settings > Sites). SpeedCurve will ask you for:

• Site name: A friendly label — e.g., "My E-commerce Site"
• URLs to test: You can add multiple URLs — homepage, a key landing page, a product page. Start with 3–5 representative pages rather than testing everything at once.
• Test profile: This defines the browser, connection speed, and location used for testing.

Choosing a Test Profile

SpeedCurve runs Synthetic tests using real browsers (Chrome, Firefox) on real hardware. When adding URLs, you select a profile that specifies:

• Browser: Chrome or Firefox
• Connection: Cable, 3G Fast, 3G Slow, LTE, etc.
• Location: Available locations include US East, US West, London, Sydney, and others
• Device: Desktop or mobile (emulation)

For most teams, a good starting set is:

• Chrome on Cable from a US location (your primary lab baseline)
• Chrome on 3G Fast (mobile simulation)

You can add more profiles later. Each URL × profile combination counts as one test slot against your plan's quota.

Step 3: Run Your First Test

After saving your site configuration, SpeedCurve queues tests immediately. The first results appear within a few minutes.

Navigate to the Dashboard to see initial results. SpeedCurve shows:

• Performance score (based on a weighted combination of metrics)
• Load time and Start Render
• Largest Contentful Paint (LCP)
• Cumulative Layout Shift (CLS)
• Total Blocking Time (TBT) (lab proxy for FID/INP)
• Page weight and request count

Click on any result to see the Filmstrip — a frame-by-frame screenshot timeline of the page loading. This is invaluable for understanding when users see content versus when the page becomes interactive.

The Waterfall chart shows every resource request in chronological order, with timing breakdowns for DNS, TCP, SSL, TTFB, and content download. If a third-party script is blocking render, you'll see it here.

Step 4: Understand the Dashboard

The main SpeedCurve dashboard gives you a high-level view across all your tested URLs and profiles. Key panels include:

Trend Charts

SpeedCurve plots every metric over time. This is where the continuous monitoring value becomes obvious: rather than a single snapshot, you see a trend line covering days, weeks, or months. Regressions show up as sudden jumps in the chart.

You can annotate trend charts with deploys — SpeedCurve lets you mark when a deployment happened (via API or manual annotation), so you can correlate performance changes with code changes.

Competitive Benchmarking

One of SpeedCurve's standout features is the ability to add competitor URLs to your tests. SpeedCurve tests competitor pages under the same conditions as your own, so you get an apples-to-apples comparison.

To add competitors, go to Settings > Sites > [Your Site] > Competitors and add up to 10 competitor URLs. They appear in your dashboard alongside your own metrics.

Filmstrip Comparison

The filmstrip view lets you compare how your page loads side by side with a competitor's or with a previous version of your own page. This is a powerful way to communicate performance wins to stakeholders — visual progress is far more compelling than raw numbers.

Step 5: Create Your First Performance Budget

A performance budget defines the maximum acceptable values for key metrics. When your site exceeds a budget threshold, SpeedCurve triggers an alert — giving your team early warning before regressions reach users.

Why Performance Budgets Matter

Without a budget, performance tends to degrade gradually. Each feature addition adds a few milliseconds here, a few kilobytes there. A performance budget creates a forcing function: the team can't ship changes that break the agreed limits without a conscious conversation about tradeoffs.

Setting Up a Budget in SpeedCurve

Navigate to Alerts > Performance Budgets. Click Add Budget.

SpeedCurve lets you set budgets on:

Metric-based budgets — direct measurements:

• Largest Contentful Paint (LCP): e.g., max 2500ms
• Cumulative Layout Shift (CLS): e.g., max 0.1
• Total Blocking Time (TBT): e.g., max 300ms
• Speed Index: e.g., max 3000ms
• Start Render: e.g., max 1000ms
• Page weight: e.g., max 500KB JavaScript

Score-based budgets — composite scores:

• Lighthouse Performance score: e.g., minimum 85

For each budget, you specify:

• The metric and threshold
• Which URLs and profiles it applies to
• The alert severity (warning vs. critical)
• Who gets notified

Recommended Starting Budgets

If you're not sure where to set your thresholds, use Google's Core Web Vitals "Good" thresholds as a starting point:

Set your initial budgets slightly tighter than your current performance — for example, if your LCP is currently 2.2s, budget at 2.5s. This gives you headroom while creating accountability.

Step 6: Configure Alert Notifications

A budget that nobody sees is useless. SpeedCurve supports several notification channels:

Slack Integration

Go to Alerts > Notification Channels > Add Channel > Slack. You'll need a Slack Incoming Webhook URL. Once configured, SpeedCurve posts a message to your chosen channel whenever a budget threshold is breached — or recovers.

A typical Slack alert includes:

• Which URL exceeded which budget
• The current value vs. the threshold
• A link to the SpeedCurve dashboard

Email Notifications

Under Account > Team Members, you can configure which team members receive email alerts. Email is useful for daily digest reports even if Slack handles real-time alerts.

Webhooks

For custom integrations — posting to a ticketing system, triggering a PagerDuty incident, or sending to a custom Slack workflow — SpeedCurve supports generic webhooks. Configure these under Alerts > Notification Channels > Webhook.

The webhook payload is JSON with the alert details, metric value, and a link to the specific test result.

Step 7: Set Up Real User Monitoring (Optional but Recommended)

Synthetic monitoring tells you how fast your site is under controlled conditions. RUM tells you how fast it is for real users. SpeedCurve's RUM product is called LUX (Lux User eXperience).

To enable LUX, go to RUM > Setup in the SpeedCurve dashboard. You'll get a small JavaScript snippet to add to your site:

<script>
LUX = window.LUX || {};
LUX.samplerate = 100; // Collect 100% of page views
</script>
<script src="https://cdn.speedcurve.com/js/lux.js?id=YOUR_ACCOUNT_ID" async defer></script>

Add this snippet to your <head> as early as possible — ideally before any other scripts. LUX is designed to be lightweight (around 8KB gzipped) and non-blocking.

LUX collects:

• Core Web Vitals (LCP, CLS, FID, INP) from the browser's Performance Observer API
• Navigation timing data
• Long tasks
• Custom marks and measures you define with the User Timing API
• Device and connection type

The RUM data appears in SpeedCurve's RUM section, where you can filter by country, device type, connection speed, and page group. Comparing your Synthetic results against RUM data shows you whether your lab conditions are representative of real user experience.

Reading Your First Week of Data

After a week of monitoring, you'll have enough trend data to start drawing conclusions:

• Look for spikes: Sudden increases in LCP or TBT often correlate with deploys or third-party script updates.
• Check for slow pages: Some pages may consistently underperform others. Prioritize them.
• Compare profiles: If mobile performance is significantly worse than desktop, that's a signal to focus mobile optimization effort.
• Review the Filmstrip weekly: Visual regressions (new elements shifting layout, slower time-to-first-meaningful-paint) are often invisible in raw numbers but obvious in filmstrip comparison.

Common Setup Mistakes to Avoid

Testing too many URLs at once: Start with 5–10 critical pages. Testing everything immediately burns through your test quota and creates alert noise.

Ignoring mobile profiles: Most web traffic is mobile. If you only test desktop, you're missing the majority of your users' experience.

Setting budgets you'll immediately breach: Budget thresholds should be achievable — set them based on your current performance plus a reasonable buffer. Budgets that are always red get ignored.

Not annotating deploys: Without deploy markers, trend charts don't tell you why something changed. Use the SpeedCurve API or a CI/CD integration to send deploy events automatically.

Skipping RUM: Synthetic monitoring is essential, but it doesn't capture real-world variability. LUX takes minutes to set up and immediately adds field data to your decision-making.

Next Steps

With your account configured, tests running, and your first budget in place, you have the foundation for continuous performance monitoring. From here, you can:

• Integrate SpeedCurve into your CI/CD pipeline to catch regressions before they deploy
• Set up more granular budgets per page type (homepage vs. product page vs. checkout)
• Configure competitive benchmarking to track progress against key competitors
• Explore SpeedCurve's API for custom integrations and reporting

Performance monitoring is most valuable when it's continuous and automatic. SpeedCurve's combination of Synthetic testing, RUM, and alerting gives teams the infrastructure to make performance a permanent part of how they ship software — not a periodic audit they remember to do.

Start with the basics, keep your budget thresholds realistic, and let the trend data guide where you invest optimization effort.