Back to blog
Web2 min read

Practical Guide to Web Performance Budgets on Client Projects

April 26, 2026

Most web agencies know they should have performance budgets. Few actually enforce them. After a project where a last-minute carousel widget pushed a client’s LCP past 4 seconds on launch day, we made budgets a contractual deliverable — not a nice-to-have.

What goes into a budget

We set three numbers per project:

  • LCP ≤ 2.5 s on a simulated mid-tier Android device over 4G (Lighthouse mobile preset)
  • Total JS ≤ 200 KB (compressed) for the initial route
  • CLS < 0.1 — no layout shift after fonts load

These map directly to Core Web Vitals thresholds, which keeps the conversation simple with clients who care about SEO.

Enforcement in CI

We use bundlesize for the JS limit and a Lighthouse CI step for LCP and CLS. Both run on every pull request. A failed check blocks the merge — no exceptions, no “we’ll fix it later.” The key is configuring the Lighthouse CI budget file at project kickoff, not after launch.

{
  "budgets": [
    {
      "resourceSizes": [{ "resourceType": "script", "budget": 200 }]
    }
  ]
}

The client conversation

When a feature request would break the budget — a full-page video background, a heavyweight slider library — we frame it as a trade-off, not a refusal. “We can ship this, but it will push LCP to ~3.8 s and likely drop your search ranking for these pages. Here’s a lighter alternative that achieves the same effect.” Clients almost always choose the lighter path when the cost is concrete.

Performance budgets have saved us from scope creep disguised as features more than once. Build them in at the proposal stage and they become a shared language, not a developer complaint.