Performance Budget Calculator

A performance budget is a set of limits you define for metrics that affect how fast a page feels: total page weight, JavaScript size, image size, number of requests, or timing metrics like Time to Interactive. Once set, you test builds against it and treat a budget-busting change the same way you'd treat a failing test: block it or negotiate a trade-off before it ships. Budgets exist because "make it fast" isn't actionable on its own. A number your team can check a build against is.

A widely-cited starting point (popularized by Addy Osmani's performance budgeting work) is around 170KB of JavaScript, minified and compressed, for a page that needs to become interactive quickly on a mid-range phone over a typical mobile connection. That's roughly 700KB once the browser unpacks and parses it. Desktop-only experiences can usually afford more, since desktops have faster CPUs and users are more likely on a fast, stable connection. These are starting points, not hard rules: use the calculator above to set a target load time for your actual device and connection mix, and it will work backward to a JS budget that fits your audience instead of a generic guideline.

Core Web Vitals are the outcomes Google measures from real users: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). A performance budget is the input you control to hit them. A budget on JavaScript size and image weight, for example, directly constrains LCP (large hero images and render-blocking JS delay it) and INP (heavier JS bundles mean more main-thread work before the page can respond to input). The current "good" thresholds are LCP under 2.5s, INP under 200ms, and CLS under 0.1, measured at the 75th percentile of real visitors in Chrome UX Report data. A budget that keeps you comfortably under these on a mid-tier device and 4G connection leaves margin for the slower quarter of your traffic that CrUX also counts.

No. Google retired FID as a Core Web Vital in March 2024 and replaced it with Interaction to Next Paint (INP). FID only measured the delay before the browser started processing a user's first interaction; INP measures the full latency of every interaction across the page's lifetime, which is a far better proxy for whether a page feels responsive while in use. If you're setting budgets today, track INP (good: under 200ms) rather than FID, and treat JavaScript execution time, not just download size, as the main lever that moves it.

Manual spot-checks don't scale. The standard approach is Lighthouse CI, which reads a budget config and fails the build when a page exceeds it, so a pull request that blows the budget gets caught before it merges instead of after users notice. Use the "Export Configs" section above to download a ready-made lighthouserc.json generated from the numbers you've set on this page, place it in your project root, and run lhci autorun in your CI pipeline (or as a pre-deploy step) to enforce it automatically on every build.

Set your budget for the slowest device and connection your real users have, not the one you develop on. Check your analytics for the most common device category and, if available, effective connection type; without that data, a mid-tier Android phone on a throttled 4G connection is a reasonable default, since it approximates a typical global mobile user rather than someone on a flagship phone and fast Wi-Fi. If a meaningful share of your traffic is in regions still on 3G, or your audience skews toward older or lower-end devices, budget for that tier explicitly instead of assuming the best case.

There's no universal ratio, but JavaScript deserves the tightest per-kilobyte budget because it costs more than any other resource type: the browser has to download, parse, compile, and execute it, while an image mostly just needs to decode and paint. A common allocation pattern spends roughly a quarter to a third of the total budget on JavaScript, close to half on images (usually the biggest category by bytes but relatively cheap per byte to process), and the remainder across CSS, fonts, and HTML. The industry benchmarks on this page give more concrete starting ranges by site type. Use those as a baseline, then adjust based on which resource type is driving your slowest metric today.