A performance budget is a set of limits a website agrees not to exceed, such as total JavaScript size, number of third-party scripts, Largest Contentful Paint and Interaction to Next Paint, checked automatically before each release. Marketing sites need budgets because speed rarely fails in one big change: it erodes through a new chat widget, another tracking tag, a larger hero video. A budget turns “the site feels slow” into a clear rule everyone can see, and makes every addition a decision.
What to put in the budget
| Metric | Example budget for a marketing site | Why |
|---|---|---|
| Largest Contentful Paint (lab, mobile) | 2.5 seconds or less | Google’s “good” threshold for real users |
| Total Blocking Time (lab) | 200 milliseconds or less | A lab proxy for responsiveness |
| Cumulative Layout Shift | 0.1 or less | Google’s “good” threshold |
| JavaScript transferred per page | An agreed size, for example 200 KB compressed | JavaScript drives INP problems |
| Third-party scripts | An agreed maximum number, for example 5 | Each adds weight and risk |
| Hero image weight | An agreed size, for example 150 KB | Often the LCP element |
| Web fonts | An agreed number of font files | Fonts delay text |
The example numbers are starting points, not standards. Set yours from your current performance and your competitors’, aiming to pass Core Web Vitals on mid-range phones.
Enforce it automatically
Lighthouse CI can fail a build when a page exceeds a budget. Add resource and metric assertions to its configuration:
// lighthouserc.json (excerpt)
{
"ci": {
"assert": {
"assertions": {
"largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
"total-blocking-time": ["error", { "maxNumericValue": 200 }],
"cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
"resource-summary:script:size": ["error", { "maxNumericValue": 204800 }],
"resource-summary:third-party:count": ["warn", { "maxNumericValue": 5 }]
}
}
}
}
Run it on staging for key templates, as described in catching SEO regressions before deployment.
Watch real users too
Lab tests catch regressions before release; field data shows what visitors experience. Review Search Console’s Core Web Vitals report monthly, and consider collecting your own real-user data with the web-vitals library for faster feedback.
Make it a team process
- Every new script or tag request states its purpose, owner and expected size, and is checked against the budget.
- If something new must go in, something else comes out, or the budget is changed deliberately and documented.
- Review all third-party scripts each quarter and remove unused ones.
- Show the budget and current status on the team’s dashboard.
Most budget breaches on marketing sites come from marketing tools, not from developers. The process only works if marketing owns it jointly.
Common budget busters
- Chat widgets and heatmap tools loading on every page
- Autoplaying hero videos
- Several analytics tools doing the same job
- Page builder scripts and animation libraries
- Uncompressed images uploaded directly from cameras or design tools
For WordPress specifics see Core Web Vitals for WordPress, and for React and Next.js see fixing INP.
Frequently asked questions
Is a performance budget only for large sites?
No. Small sites benefit most, because a few heavy scripts can make up most of their page weight.
What if the site already exceeds the budget?
Set the budget at the current level to stop things getting worse, then lower it step by step as you remove weight.
Does speed affect AI search?
Crawlers have time limits, and very slow pages risk being skipped. Fast, server-rendered pages are easier for every crawler to fetch.
Sources
- web.dev, “Performance budgets 101” and Core Web Vitals thresholds
- Lighthouse CI documentation, assertions