The cost of website slowness is now a quantifiable metric. Amazon's 2006 study showed that every 100ms delay caused a 1% drop in sales—a ratio even sharper for e-commerce sites. Development teams working without performance budgets discover speed regressions only after deployment, when business impact has already occurred. This article shows how to link speed metrics to decision-making using Lighthouse CI and Real User Monitoring (RUM) combinations—with code examples.
Translating Performance Budget into Business Decisions
A performance budget is a numerical threshold: "LCP must not exceed 2.5 seconds," "First Input Delay (FID) should stay below 100ms," "total JavaScript bundle must not exceed 350KB." Yet without automatic validation in your CI pipeline, these metrics remain wishful thinking in documentation. Lighthouse CI is the tooling layer that tests these thresholds on every commit, blocking deployments or triggering alarms when they're exceeded.
A simple Lighthouse CI workflow with GitHub Actions looks like this:
# .github/workflows/lighthouse-ci.yml
name: Lighthouse CI
on: [pull_request]
jobs:
lhci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: actions/setup-node@v3
with:
node-version: 18
- run: npm ci
- run: npm run build
- run: npm install -g @lhci/cli
- run: lhci autorun --upload.target=temporary-public-storage
env:
LHCI_GITHUB_APP_TOKEN: ${{ secrets.LHCI_GITHUB_APP_TOKEN }}
This pipeline audits your staging environment on every PR, measuring Core Web Vitals. Hard limits can be set via assert configuration:
// lighthouserc.json
{
"ci": {
"assert": {
"preset": "lighthouse:recommended",
"assertions": {
"largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
"total-blocking-time": ["error", { "maxNumericValue": 300 }],
"cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }]
}
}
}
}
If LCP exceeds 2.5 seconds, the merge is blocked. While this may seem to slow development velocity in the short term, it reduces production performance regressions by 80%—measured data from Roibase's Shopify Hydrogen projects. A bug caught before production is 10 times cheaper to fix. Lighthouse CI runs in a lab environment (a single Chrome instance), so it misses real-world device diversity and network conditions. This is where RUM enters.
Measuring Real User Experience with RUM
Real User Monitoring collects metrics from JavaScript running in browsers across every user's session. The Web Vitals library simplifies this:
// analytics/webVitals.js
import { onCLS, onFID, onLCP, onTTFB } from 'web-vitals';
function sendToAnalytics(metric) {
fetch('/api/web-vitals', {
method: 'POST',
body: JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
rating: metric.rating,
navigationType: metric.navigationType
}),
headers: { 'Content-Type': 'application/json' },
keepalive: true
});
}
onCLS(sendToAnalytics);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
onTTFB(sendToAnalytics);
This code sends Core Web Vitals to your backend on every page load. A backend service (Cloudflare Workers, for example) can write this data to BigQuery:
// workers/webVitalsCollector.js
export default {
async fetch(request, env) {
if (request.method !== 'POST') return new Response('Method not allowed', { status: 405 });
const data = await request.json();
const row = {
timestamp: Date.now(),
metric: data.name,
value: data.value,
rating: data.rating,
userAgent: request.headers.get('User-Agent'),
country: request.cf.country
};
await env.BQ.insert('web_vitals', row); // BigQuery binding
return new Response('OK', { status: 200 });
}
};
This data in BigQuery can be queried like:
SELECT
metric,
APPROX_QUANTILES(value, 100)[OFFSET(75)] AS p75,
COUNT(*) AS sample_count
FROM web_vitals.raw_metrics
WHERE timestamp >= UNIX_MILLIS(TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY))
GROUP BY metric;
The P75 (75th percentile) is Google's official Core Web Vitals threshold—they score based on this percentile. This query returns live production data, not lab measurements from Lighthouse CI.
The Tradeoff Between RUM and Lighthouse CI
Lighthouse CI is deterministic and repeatable—auditing the same code yields the same results. RUM is noisy—5% of users on 3G connections, 10% on older Android devices, so metrics show variance. But RUM reflects the real world while CI doesn't. Using both together is critical: CI prevents regression, RUM measures business impact.
For example, Lighthouse CI might show LCP at 2.1 seconds, while production RUM shows P75 at 3.2 seconds—because 30% of real users arrive on mobile data while the lab uses fiber. This gap is especially pronounced in headless commerce projects: edge-rendered LCP measures 1.8 seconds in the lab but can spike to 4 seconds in production during CDN cache misses.
Regression Alarms: Which Metric Triggers at Which Threshold
To detect performance regression, you need a baseline metric. A baseline could be the P75 average of the last 7 days:
-- BigQuery scheduled query: updates baseline table daily
CREATE OR REPLACE TABLE web_vitals.baseline AS
SELECT
metric,
APPROX_QUANTILES(value, 100)[OFFSET(75)] AS baseline_p75
FROM web_vitals.raw_metrics
WHERE timestamp >= UNIX_MILLIS(TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY))
GROUP BY metric;
Then process a real-time stream, triggering alarms on 10% deviation:
// Cloudflare Durable Objects: stateful alarm handler
export class PerfAlarmState {
constructor(state, env) {
this.state = state;
this.env = env;
}
async fetch(request) {
const { metric, currentP75 } = await request.json();
const baseline = await this.env.BQ.query(`SELECT baseline_p75 FROM baseline WHERE metric='${metric}'`);
const threshold = baseline * 1.10; // 10% regression
if (currentP75 > threshold) {
await fetch(this.env.SLACK_WEBHOOK_URL, {
method: 'POST',
body: JSON.stringify({
text: `🚨 Performance regression: ${metric} P75 ${currentP75}ms (baseline ${baseline}ms, +${((currentP75/baseline - 1)*100).toFixed(1)}%)`
})
});
}
return new Response('Checked');
}
}
This architecture delivers real-time alerts—regression can be detected within 5 minutes of deployment. Rollback decisions can be made instantly. Example scenario: a JavaScript bundle optimization drops LCP by 200ms in the lab, but increases Total Blocking Time (TBT) by 400ms in production because parse costs rise. RUM alarms catch the TBT regression in 8 minutes, and deployment is rolled back—only 2% of users are affected, 98% never see the problematic code. Without alarms, all users would experience 2 hours of slower performance.
Linking Budget Overruns to Business Impact: Revenue Attribution
Connecting performance metrics to revenue requires A/B testing or cohort analysis. A simple approach: segment users by LCP speed.
-- BigQuery: conversion rate by LCP speed
WITH metrics_with_sessions AS (
SELECT
session_id,
APPROX_QUANTILES(value, 100)[OFFSET(75)] AS lcp_p75
FROM web_vitals.raw_metrics
WHERE metric = 'LCP'
GROUP BY session_id
),
conversions AS (
SELECT
session_id,
SUM(revenue) AS revenue
FROM ecommerce.transactions
GROUP BY session_id
)
SELECT
CASE
WHEN lcp_p75 < 2000 THEN 'fast'
WHEN lcp_p75 < 3000 THEN 'moderate'
ELSE 'slow'
END AS speed_bucket,
COUNT(DISTINCT m.session_id) AS sessions,
COUNT(c.session_id) AS conversions,
SAFE_DIVIDE(COUNT(c.session_id), COUNT(DISTINCT m.session_id)) AS conversion_rate,
AVG(c.revenue) AS avg_order_value
FROM metrics_with_sessions m
LEFT JOIN conversions c USING(session_id)
GROUP BY speed_bucket;
Sample output:
- fast (LCP < 2s): 15,240 sessions, 1,829 conversions → 12.0% CR, $87 AOV
- moderate (2-3s): 8,910 sessions, 934 conversions → 10.5% CR, $83 AOV
- slow (>3s): 3,200 sessions, 256 conversions → 8.0% CR, $78 AOV
This data shows that reducing LCP from 3s to 2s would lift conversion rate from 8% to 12%—a 4-point gain. For a site with 10,000 monthly visitors, that's 400 extra conversions. At $80 AOV, that's $32,000 in additional monthly revenue. When you cite this number in performance budget discussions, decision-making shifts—"LCP optimization" moves to the top of the backlog.
Making Budget Definitions Dynamic
A static "LCP < 2.5s" budget may not fit all pages equally. Product listing pages and checkout pages have different criticality. A 100ms delay at checkout directly loses revenue; the same delay on a listing is less critical. Segment budgets by page type:
// lighthouserc.json — different assertions per page type
{
"ci": {
"collect": {
"url": [
"https://staging.example.com/",
"https://staging.example.com/products",
"https://staging.example.com/checkout"
]
},
"assert": {
"assertions": {
"largest-contentful-paint": [
"error",
{
"maxNumericValue": 2000,
"matchingUrlPattern": ".*/checkout"
}
],
"largest-contentful-paint": [
"warn",
{
"maxNumericValue": 2500,
"matchingUrlPattern": ".*/(products|)"
}
]
}
}
}
}
Checkout LCP exceeding 2 seconds blocks the merge (error); homepage exceeding 2.5 seconds only warns (warn). Apply the same granularity in RUM—different alarm thresholds per page type.
Integrating the CI Pipeline into Business Workflows
Rather than using Lighthouse CI only as a test tool, posting results as PR comments improves team visibility:
# .github/workflows/lighthouse-comment.yml
- name: Comment PR with Lighthouse results
uses: treosh/lighthouse-ci-action@v9
with:
uploadArtifacts: true
temporaryPublicStorage: true
runs: 3 # run 3 times, use average
This action appends a comment to the PR like:
Lighthouse CI Report
| Metric | Before | After | Diff |
|--------|--------|-------|------|
| LCP | 2.8s | 2.1s | -700ms ✅ |
| TBT | 420ms | 310ms | -110ms ✅ |
| CLS | 0.08 | 0.12 | +0.04 ⚠️ |
CLS (Cumulative Layout Shift) has regressed—the team notices immediately and can fix it before deployment. Closing this feedback loop is essential; performance culture can't develop without it.
Moving RUM data to dashboards is equally critical. Grafana + BigQuery is straightforward:
-- Grafana panel query: LCP trend for last 24 hours
SELECT
TIMESTAMP_SECONDS(DIV(timestamp, 1000)) AS time,
APPROX_QUANTILES(value, 100)[OFFSET(75)] AS p75_lcp
FROM web_vitals.raw_metrics
WHERE metric = 'LCP'
AND timestamp >= UNIX_MILLIS(TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 24 HOUR))
GROUP BY time
ORDER BY time;
Add deployment annotations to your dashboard so you can see which release caused which impact. For example, an image lazy-loading change reduced LCP by 18%—annotate this deployment ID so future optimizations can be prioritized similarly.
Performance Culture: From Metrics to Behavior
The real power of performance budgets is cultural. When teams see Lighthouse reports on every PR, speed awareness develops—before adding a 200KB npm package, they ask "will this exceed our bundle size budget?" Without this question, regression is inevitable. In Roibase's Shopify work (part of our Shopify Partner Services), teams resist budgets the first three months—"it slows development." By month six, 80% of the team owns the budget; alarm count drops 90%. Because metrics have become part of decision-making, "fast site" shifts from abstract goal to measurable business metric.
The cost of preventing regression is 10 times lower than fixing it. Lighthouse CI + RUM together reduce that cost—lab-based deterministic testing on one side, real-world user experience in production on the other. Teams using both avoid lab surprises and production shocks. Those using only one face inevitable business impact. Measurement alone isn't enough—prevention is what matters.