Performance Budgets in the Real World
How we set and enforce web performance targets that actually stick—beyond the Lighthouse score obsession.
Everyone agrees web performance matters. Few organizations actually maintain it. Here's our approach to performance budgets that survive contact with reality.
Beyond Lighthouse Scores
Lighthouse is a tool, not a target. A perfect 100 means nothing if your actual users on actual devices have a poor experience.
We track:
- **Core Web Vitals on real traffic** (via CrUX data or RUM)
- **Time to Interactive on target devices** (not just the latest MacBook Pro)
- **Total page weight by resource type** (identifying what's growing)
- **Third-party script impact** (often the real culprit)
Setting Realistic Budgets
We start with competitor analysis. If the market leader loads in 3 seconds and you're at 8, you have a problem. If everyone's at 8, faster is competitive advantage.
Typical budgets for marketing sites:
- **LCP**: < 2.5s on 4G connection
- **Total page weight**: < 1MB (ideally < 500KB)
- **JavaScript**: < 200KB gzipped
- **Third-party scripts**: < 100KB total
For web applications, we adjust based on complexity—but we still set limits.
Enforcement That Works
Budgets without enforcement are wishes. We implement:
Build-Time Checks
Our CI pipelines fail if bundle sizes exceed limits. No exceptions without explicit approval and documented justification.
# In CI
if [ $(stat -f%z build/main.js) -gt 200000 ]; then
echo "Bundle size exceeded. Current: $(stat -f%z build/main.js)"
exit 1
fiPerformance Dashboards
We set up monitoring from day one. SpeedCurve or similar tools track real user metrics. Alerts fire when budgets are breached.
Regular Audits
Monthly performance reviews are part of maintenance contracts. We catch slow degradation before it becomes a crisis.
Common Budget Busters
In our experience, performance problems come from:
- **Unoptimized images** (40% of cases) - Next.js Image helps but doesn't solve everything
- **Third-party scripts** (30%) - Marketing tools, chat widgets, analytics
- **Large client-side frameworks** (15%) - Loading React for a content page
- **Web fonts** (10%) - Three weights of four fonts
- **Unintentional dependencies** (5%) - That one import that bundles 500KB
The Maintenance Reality
Performance isn't a launch milestone—it's ongoing work. Every new feature, every marketing request, every "just add this tracking pixel" chips away at performance.
Build the culture from the start. Make performance visible. Celebrate speed improvements. Make regressions painful to ship.
The sites that stay fast are the ones where someone cares enough to keep them fast.
Related Articles
Why We Chose Next.js for (Almost) Everything
A practical breakdown of when Next.js makes sense, when it doesn't, and how we make the call for each project.
A Discovery Phase That Actually Works
How we structure the first two weeks of every project to uncover real requirements and avoid expensive surprises.
Building Digital Trust with Legal Clients
Lessons from redesigning law firm websites: how we balance professionalism, accessibility, and conversion.
Want to discuss this topic?
We'd love to hear your thoughts or help you apply these ideas.