A performance budget is a set of weight limits agreed before design starts: a maximum total size for each page type, caps for images, fonts and scripts, and outcome targets for how the page must feel. Agree it before anyone opens Figma, because every heavy element approved in a design concept — a video hero, a sixth font weight, a chat widget — becomes expensive to remove later.
The short answer: agree the weight limits first — here is a starter budget to adapt
Set two kinds of limit. Quantity limits cap what the page is made of. Outcome targets cap what the visitor experiences, using Google's official Core Web Vitals thresholds: Largest Contentful Paint at or below 2.5 seconds, Interaction to Next Paint at or below 200 milliseconds, and Cumulative Layout Shift at or below 0.1, at the 75th percentile of real visits.
| Budget line (homepage, mobile) | Starter limit |
|---|---|
| Total page weight | 1.5 MB |
| Images, including the hero | 700 KB |
| JavaScript, all sources | 250 KB |
| Web fonts | 100 KB, maximum 2 families, 4 weights total |
| CSS | 100 KB |
| Third-party scripts | Maximum 5, each named and justified |
Treat this as an example to adapt, not a universal standard.
The problem: every slow site was approved one reasonable design decision at a time
Nobody approves a slow website. They approve a hero video on Monday, six font weights on Tuesday, an uncompressed gallery on Wednesday, and chat, analytics and advertising scripts across the month. Each decision looks reasonable in isolation, and each adds weight nobody totalled.
The HTTP Archive's Web Almanac 2025 reports a median mobile homepage of about 2.6 MB, with images the largest share at a median of 911 KB and JavaScript at 632 KB. By launch, removing weight means re-designing approved work — which is why this conversation belongs at the design stage.
What a performance budget is: quantity limits plus outcome targets
Web.dev's "Performance budgets 101" describes budgets built from quantity-based metrics, milestone timings and rule-based scores. For a design-stage budget, quantity limits and outcome targets are the useful pair.
Quantity limits are set per asset type: total page weight, maximum hero image size, font weights, script size and a count of third-party scripts. Designers work with these directly, because they translate into choices: this hero, this many gallery images, this font set.
Outcome targets connect the budget to experience: a page can meet its weight limit and still feel slow if scripts block interaction, so pair the quantities with the Core Web Vitals thresholds above. Our Core Web Vitals launch checklist covers checking them at launch; the budget exists so that check has something achievable to pass.
Set the baseline: benchmark your current site and two competitors first
A budget set without a baseline is a guess. Measure your current homepage and two competitors' homepages on a mid-range mobile device over a throttled connection: record total weight, image weight, script count and Core Web Vitals.
Then set the budget relative to what you found: aim meaningfully lighter than the best performer in your set, adjusted for the weakest connection your audience uses. A UAE business whose customers browse on mobile data outside the main cities should budget for that connection, not office fibre.
Build the budget by page type: homepage, service page, article (worked table)
One number for the whole site fails, because page types do different jobs. A homepage carries brand media; an article is mostly text. Split the budget by template.
| Page type | Total | Images | JavaScript | Fonts |
|---|---|---|---|---|
| Homepage | 1.5 MB | 700 KB | 250 KB | 100 KB |
| Service page | 1.2 MB | 500 KB | 200 KB | 100 KB |
| Article / blog post | 900 KB | 350 KB | 150 KB | 100 KB |
Two rules make the table work. First, video is not inside the image allowance: a hero video gets its own line, agreed separately, or it is not in the design. Second, fonts count on every page load, so a font decision made for the homepage taxes every template too — which is why the font cap is identical across rows.
Price the usual suspects: hero video, image galleries, web fonts, chat and analytics scripts
Before approving any of these, ask what it costs. A full-screen background video can consume the entire image allowance several times over; if video stays, it replaces the hero image budget rather than adding to it, loads after the main content, and carries a poster fallback on mobile. Whether video helps conversions is a separate decision from its weight price.
Image galleries multiply quietly: ten photographs at an uncompressed 400 KB each are 4 MB. Set a per-image maximum, require modern formats and responsive sizes, and cap above-the-fold images separately.
Web fonts charge rent on every page: each additional weight is another file every visitor downloads. Two families and four weights total is a workable constraint for most business sites; a design needing more should say what it gives up elsewhere.
Third-party scripts are the least visible cost. Chat, analytics, heatmaps, review widgets and advertising tags each add JavaScript, requests and often layout shift. Give them a count cap and a named list in the brief — owner and purpose for each — or the script does not ship.
Write the budget into the design brief and the Figma handover
A budget that lives in a meeting note dies in the first design review. Put it in the brief with the table, the baseline it came from, and one sentence of authority: concepts that exceed the budget are revised before approval, not optimised after build.
In the Figma handover, attach the budget to the assets: image dimensions and maximum file sizes, the approved fonts, and the named third-party list. The developer should never guess which hero variant was approved, or discover an unlisted widget in the annotations.
Design review with a scale: what happens when a concept goes over budget
Review concepts with the asset list open, not by looking at the mockup — a static design weighs nothing, so estimate from its parts: count the images, multiply by planned sizes, add fonts and named scripts.
When a concept goes over, the trade-off happens in the room: enlarge the budget deliberately for this page type, or change the design. Silent approval converts a design decision into a build problem.
Enforce it in the build (budget checks, and what to do on a breach: optimise, remove, or don't add)
During the build, the budget becomes automated checks: Lighthouse tooling supports performance budgets directly, and bundler tools can fail a build when a script or image exceeds its cap. Our guide to technical SEO and Core Web Vitals explains where these checks sit in the wider picture, and a technical SEO audit can verify them on an existing site.
On a breach, web.dev's rule gives the right order: optimise the asset, remove it, or do not add it.
After launch: keep measuring against the same budget
Weight creeps after launch through new scripts, campaign tags and uncompressed uploads. Re-measure the main templates against the original budget regularly, using field data for the Core Web Vitals thresholds and the same page-type table for quantities. When marketing adds a script, price it against the third-party line first: the budget's long-term job is the standing rule that every addition has a visible cost, and most web design projects stay fast exactly as long as someone owns it.
Common mistakes
The most common mistake is setting a single total with no per-asset lines, so one hero video consumes the whole budget invisibly. Next is budgeting for desktop on fast connections while most visitors arrive on mobile data. Other frequent errors: treating the HTTP Archive median as a target rather than a warning, approving font weights without counting files, letting scripts arrive through a tag manager after sign-off, and writing the budget after design approval, when it can only document decisions instead of shaping them.
FAQ
How much should a homepage weigh?
There is no official figure. As a starting example, many business homepages can be designed to a total near 1.5 MB on mobile, split as in the table above. Set your own number from a baseline: benchmark your current site and two competitors, then budget below the best of them.
What is the difference between a performance budget and a speed test?
A speed test measures a page that already exists. A performance budget is agreed before design and build, and limits the decisions that determine the test result: asset sizes, font weights and script counts, paired with outcome targets such as the Core Web Vitals thresholds.
How many web font weights should a website use?
As few as the design genuinely needs. A workable starting cap is two families and four weights in total, because every weight is a file downloaded on every page. If a design needs more, it should trade weight from another budget line.
Can a homepage have a video hero and stay within budget?
Yes, if the video is budgeted as its own line, replaces rather than supplements the hero image allowance, loads after the main content, and has a lightweight poster image. An unbudgeted autoplay video is the fastest way to break a homepage budget.
Who should own the performance budget?
One named person — often the project manager or lead designer — who attends design reviews and can require a trade-off when a concept goes over. A budget owned by everyone is enforced by no one.
Get a design process with the budget built in (CTA)
If you are commissioning a site or redesign, ask for the performance budget in the brief, before concepts. WebStackRank builds sites through SEO-friendly web development, where weight limits and Core Web Vitals targets are agreed up front and checked during the build. Send us your current homepage and your benchmarked competitors, and we will reply with an itemised proposal within 24 business hours. WhatsApp: +971 52 595 3174.
