Performance
How I approach performance budgets in Next.js
11/3/2025 - 6 min read
How to define budgets, instrument meaningful metrics, and choose optimizations that improve user outcomes.
Budget the experience, not only the bundle
A useful performance budget starts with the route a user lands on and the task they are trying to complete. JavaScript size matters, but so do image weight, font loading, API timing, hydration cost, and layout stability.
For Next.js projects, I usually track route-level LCP, CLS, total blocking time, critical asset weight, and the amount of client code needed before the first meaningful interaction.
Push heavy work behind intent
The fastest byte is the one the user did not need yet. Expensive 3D scenes, analytics extras, and non-critical widgets should load after text content and primary navigation are already usable.
This does not mean stripping personality from a portfolio or product site. It means staging the experience so the first paint communicates value while richer layers arrive progressively.
Measure regressions where teams work
Performance budgets are most useful when they are visible in pull requests and release checks. A local Lighthouse run is helpful, but teams need automated thresholds and a shared habit of reading the numbers.
The budget should be strict enough to catch drift and practical enough that teams do not bypass it the first time a deadline gets tight.