Web Performance Budget Reference
A practical starting budget for page weight, critical assets, third-party scripts, image dimensions, and Core Web Vitals review.
A budget is a guardrail, not a universal law
Targets should reflect the product, audience, and current baseline. The most useful budget prevents accidental regressions.
Measure field and lab data
Synthetic tests help reproduce issues; real-user data shows actual devices and networks. Use both where available.
Assign asset ownership
Every third-party script, font, widget, and large image should have an owner and purpose so unused weight can be removed.
How to read the downloadable table
The table is organized around “Budget field” and “Starter target.” Begin with the row labeled “HTML transfer,” then read across the full row before comparing it with another case. The cells are designed to preserve context; copying a single number or phrase without its row label can change the meaning.
Use the last row, “Mobile test,” as a completeness check rather than as an automatic conclusion. Where the table contains scores, thresholds, examples, or suggested actions, they apply only under the method and limitations stated on this page.
A repeatable application workflow
Measure a real page under a documented device, network, and cache condition. Change one variable at a time, repeat the run, and use field data when available instead of assuming a single laboratory score represents every visitor.
For web performance budget reference, keep a short review log containing the date, page or file tested, input values, result, reviewer notes, and any source that changed the interpretation. This turns a one-time check into an auditable workflow.
What evidence to preserve
Save the exact version of the input, a screenshot or exported result where appropriate, the source URL, and the date accessed. If the result depends on software, include the browser, library, encoder, calculator version, or device conditions that could affect reproduction.
When publishing a conclusion, distinguish an observation from an inference. An observation reports what the documented test produced; an inference explains what that result may mean. Readers should be able to see which is which.
Maintenance and citation practice
Cite this resource using the full title, ToolnixHub, the reviewed date, the canonical report URL, and the relevant table or section. Link to the report page rather than an isolated download so readers can see the methodology and limitations.
Recheck the underlying primary references before using the resource for a time-sensitive decision. Standards, rates, browser support, product behavior, and official guidance can change after the reviewed date, even when the general workflow remains useful.
| Budget field | Starter target | Why monitor it |
|---|---|---|
| HTML transfer | ≤ 100 KB | Large markup delays parsing |
| Critical CSS | ≤ 50 KB | Render-blocking cost |
| Initial JavaScript | ≤ 200 KB compressed | Parse and execution cost |
| Hero image | ≤ 250 KB where quality permits | Often a loading bottleneck |
| Total initial images | ≤ 1 MB | Mobile bandwidth and memory |
| Web fonts | ≤ 150 KB | Text rendering and layout |
| Third-party scripts | Explicit allowlist | Uncontrolled cost and privacy |
| Requests before interaction | ≤ 50 | Connection overhead |
| LCP | Good threshold review | Loading experience |
| INP | Good threshold review | Interaction responsiveness |
| CLS | Good threshold review | Visual stability |
| Mobile test | Mid-tier device/network | Desktop alone hides constraints |
Methodology
This reference provides conservative starter limits and a review checklist. Teams should establish their own baseline and regression thresholds.
Limitations
Actual performance depends on server, caching, network, device, code execution, page purpose, and measurement tooling.
Questions about this report
Will staying under these byte limits guarantee good Core Web Vitals?
No. Delivery, execution, layout, and user conditions also matter.
Should a complex app use the same budget as a simple article?
Not necessarily. The budget should reflect the experience while still controlling regressions.
How often should this resource be reviewed?
Review it whenever a primary reference, rate, standard, browser behavior, tool implementation, or decision context changes. For time-sensitive use, verify the sources on the day of the decision.
May a publisher reuse the dataset?
Publishers may quote or summarize a reasonable portion with clear attribution and a link to the canonical report. Republishing the complete dataset as a substitute for this resource requires permission.