How to Set and Enforce a Site Speed Budget That Prevents Performance Regression | AuditMySite

Every Website Gets Slower Over Time (Unless You Stop It)

It's the Second Law of Web Thermodynamics: without active intervention, websites tend toward sluggishness. A new feature adds 40KB of JavaScript. A marketing pixel gets dropped in. Someone adds a carousel library for one page. A font weight gets included "just in case." Individually, each addition is negligible. Collectively, over 6-12 months, they compound into a 40-60% performance regression.

Amazon famously found that every 100ms of added latency costs them 1% of revenue. Google found that a 0.5-second delay in search results reduces traffic by 20%. Walmart reported a 2% conversion increase for every 1-second improvement in page load time. Performance isn't a technical detail — it's a business metric.

The solution isn't periodic performance fixes. It's performance budgets: hard limits that prevent regression from happening in the first place.

What Is a Performance Budget?

A performance budget is a set of measurable thresholds that your website must not exceed. If a code change would push any metric past the threshold, the change is blocked until it's optimized.

There are three types of performance budgets:

1. Resource Budgets (Easiest to Implement)

Hard limits on asset sizes:

Total page weight: ≤ 1.5MB (mobile) / ≤ 2.5MB (desktop)
JavaScript budget: ≤ 300KB compressed (all scripts combined)
CSS budget: ≤ 60KB compressed
Image budget: ≤ 800KB per page (with lazy loading for below-fold)
Font budget: ≤ 100KB (2-3 font files maximum)
Third-party budget: ≤ 150KB total for all third-party scripts

2. Timing Budgets (Most Meaningful)

Limits on user-facing performance metrics:

LCP: ≤ 2.0 seconds (more aggressive than Google's 2.5s threshold — you want headroom)
INP: ≤ 150ms
CLS: ≤ 0.05
TTFB: ≤ 600ms
Total Blocking Time (TBT): ≤ 200ms

3. Rule-Based Budgets (Most Comprehensive)

Lighthouse or WebPageTest scores that must be maintained:

Lighthouse Performance: ≥ 90 (mobile)
Lighthouse Accessibility: ≥ 95
Lighthouse SEO: ≥ 95

Setting Your Budgets: The Data-Driven Approach

Don't pick numbers arbitrarily. Base your budgets on three data points:

Your current baseline: Measure your site's current performance on your 10 most important pages. Your budget should be ≤ current performance (don't allow regression).
Your competitors: Measure your top 3 competitors' performance. Your budget should match or beat them.
Your revenue data: If you have conversion rate data correlated with page speed (Google Analytics can show this), calculate the revenue impact of each 100ms.

The budget should be the most aggressive number that's achievable with your current architecture. Stretch goals belong in a roadmap, not a budget that blocks deployments.

Enforcing Budgets in CI/CD

GitHub Actions + Lighthouse CI

The most common setup for automated performance budget enforcement:

Install Lighthouse CI: npm install -g @lhci/cli
Create lighthouserc.js with your budgets
Add a GitHub Action that runs Lighthouse CI on every pull request
Configure it to fail the PR check if budgets are exceeded

This creates a hard gate: no PR that degrades performance can be merged without explicit override. The override should require approval from a tech lead — making performance regression a deliberate, documented decision rather than an accident.

Webpack/Vite Bundle Size Monitoring

For JavaScript budgets specifically:

bundlesize npm package: Checks gzipped bundle sizes against thresholds in CI
size-limit by Andrey Sitnik: More sophisticated, measures the cost of your JS (includes parse/compile time estimation)
Import Cost VS Code extension: Shows the size impact of every import in real-time as developers write code

Real User Monitoring (RUM) Alerts

CI/CD catches issues before deployment. RUM catches issues in production:

Set up alerts for when any Core Web Vital metric degrades by > 10% from the 28-day average
Use Sentry Performance, SpeedCurve, or a custom web-vitals.js setup reporting to your analytics
Alert on p75 values (the same percentile Google uses for Core Web Vitals ranking signals)

Common Budget Violations and How to Fix Them

"Marketing added a new tracking pixel" (JavaScript Budget)

This is the #1 budget violation in our experience. Solution: require all third-party scripts to go through a tag manager with a hard size limit. Create a shared tracking budget and force marketing to prioritize which scripts stay within it.

"The new feature needs a large library" (Bundle Size)

Before adding any dependency > 10KB: check bundlephobia.com for the size, look for lighter alternatives, and evaluate if the functionality can be achieved with native browser APIs. React teams: consider server components for non-interactive features — they add zero client-side JavaScript.

"Images from the CMS are huge" (Image Budget)

Never serve user-uploaded images directly. Always process through an image CDN (Cloudinary, imgix, Cloudflare Images) that automatically resizes, compresses, and converts to modern formats. Budget the image processing pipeline, not individual images.

"Core Web Vitals passed in the lab but fail in the field" (Timing Budget)

Lab tests run on high-end hardware with fast connections. Field data reflects real users on real devices. The gap is typically 2-3x worse in the field. Set lab budgets at 50-60% of your field targets to account for this.

The Performance Culture Shift

Tools and budgets aren't enough. Performance must become a cultural value:

Dashboard visibility: Display Core Web Vitals on a team dashboard (TV in the office, Slack channel, or weekly email)
Performance reviews: Include performance metrics in sprint retrospectives
Knowledge sharing: When someone finds a clever optimization, share it in a team channel
New developer onboarding: Include performance budgets in onboarding documentation

Companies with strong brand standards already understand this concept — they enforce visual consistency through design systems. Performance budgets are the engineering equivalent: a system that prevents entropy.

For digital menu platforms and similar display-focused products, performance budgets are even more critical — a menu that takes 3 seconds to load on a restaurant's tablet is functionally broken, regardless of how good the content looks.

Start Today: The 30-Minute Setup

Run Lighthouse on your 5 most important pages — record every metric
Set budgets at current values (prevent regression first, improve later)
Add Lighthouse CI to your GitHub Actions or CI pipeline
Configure it to comment on PRs with performance impact
Set it to block merge if any budget is exceeded by > 5%

In 30 minutes, you'll have a system that prevents your site from ever getting slower. Everything after that is improvement. And improvement is a lot easier when you've stopped the bleeding.