Set a Performance Budget Before a Website Redesign
Redesigns tend to make pages heavier, one hero video and font weight at a time. A performance budget agreed before design starts gives the team a shared limit, so speed is decided in the brief rather than discovered after launch.
A website redesign rarely sets out to make a site slower. It happens one reasonable decision at a time: a background video for the homepage, a second typeface, a chat widget, a testimonial slider, an analytics tag for the new campaign. Each one is small. Together they can leave the new site heavier and slower than the one it replaced.
A performance budget prevents that drift by agreeing on limits before the first mockup. This article uses HTTP Archive’s 2025 measurements of page weight across millions of sites, MDN’s guidance on how budgets work, and a practitioner’s account of why some budgets hold while others are ignored, and turns them into a budget a redesign team can actually use.
Why redesigns put on weight
The web as a whole keeps getting heavier. The Web Almanac, HTTP Archive’s annual report, analyzed 17.2 million websites for its 2025 edition. Its Page Weight chapter, published on 15 January 2026, found that the median mobile home page reached 2.6 MB in July 2025, up 8.4% from 2.4 MB in 2024. In July 2015, the same median was 845 KB.
Page weight is the total amount of data a browser downloads to show a page: HTML, CSS, JavaScript, fonts, images, and video. The chapter’s breakdown of the median mobile home page shows where those bytes go:
| Resource type | Median mobile home page, July 2025 |
|---|---|
| Images | 911 KB |
| JavaScript | 632 KB |
| Fonts | 122 KB |
| CSS | 77 KB |
| HTML | 22 KB |
Two details matter for a redesign. First, home pages carry the heaviest load: the chapter reports them as close to 45.8% larger than inner pages, and the median mobile inner page used 354 KB of images against 911 KB on the home page. Second, much of the JavaScript does nothing for the page. Lighthouse, Google’s open-source page-auditing tool, ran alongside the crawl and found a median of 251 KB of unused JavaScript on mobile pages, measured after decompression.
Bytes are not equal, either. The chapter notes that JavaScript must be parsed, compiled, and executed after it downloads, which can stall low-end phones, while an image costs mainly its transfer and decoding.
What goes wrong when speed is checked only at launch
- Decisions are already locked in. By the time anyone measures, the hero video and the font pairing have been approved by stakeholders.
- Fixes become negotiations. Removing a feature after sign-off feels like a loss, so the team optimizes around it instead.
- Regressions arrive quietly. Without an agreed limit, each new plugin or tag after launch looks too small to refuse.
What a performance budget is
MDN Web Docs defines a performance budget as “a limit to prevent regressions.” The limit can apply to a single file, a file type, all files on a page, a timing metric, or a threshold over a period of time. MDN groups budgets into three kinds:
- Timing-based, such as how long the main content takes to appear.
- Quantity-based, such as total image size or the number of JavaScript files.
- Rule-based, such as a minimum Lighthouse score.
MDN also recommends two levels for each limit. A warning level flags a change early without blocking work, so the team can plan for it. An error level marks the upper bound, where a change would have a negative and noticeable effect on users.
A budget works much like a baggage allowance on a flight: knowing the limit before you pack changes what goes in the case, while learning it at the check-in desk only forces an awkward repack. The comparison has a limit, though. A weight allowance treats every kilogram the same, and a web page’s bytes do not cost the same.
Why some budgets stick and others are ignored
Tim Kadlec argued in a March 2019 essay that budgets which fail usually fail in execution, not in concept. In his account, a budget that lasts is concrete, meaningful, integrated into the workflow, and enforced. A phrase like “fast as possible” is not a budget. A specific metric, measured under stated conditions, is.
Kadlec recommends a timing-based metric as the primary budget, with page weight or a Lighthouse score as supporting budgets. The reason is meaning: a speed target connects to what visitors experience, while a byte count on its own does not. The byte limits still earn their place, because designers and developers can act on them directly when choosing between images, fonts, and features.
What the weight data does and does not show
The Web Almanac compared page weight with Chrome User Experience Report (CrUX) field data, which records how real Chrome users experienced each site. Core Web Vitals are Google’s metrics for loading, responsiveness, and visual stability. A page passes the assessment when its loading and visual stability scores are good at the 75th percentile of visits, and its responsiveness score is either good or has no data.
Pass rates fell as home pages got heavier. On mobile, 57% of home pages under 1 MB passed, compared with 45% in the 2 to 3 MB range and 30% at 5 MB or more. On desktop, 70% of home pages under 1 MB passed, against 38% at 5 MB or more.
That trend is a correlation, and the chapter presents it that way: page weight is not part of the Core Web Vitals calculation, and CrUX data mainly reflects the more popular sites. A light page can still be slow because of a slow server or a blocking script, and a heavier page can be fast when its bytes are well ordered. The data supports weight as a useful warning sign, not as the definition of speed.
“A budget written before the first mockup is a design constraint. A budget written after launch is a cleanup list.”
— Windware Studio Practice Note
Build the budget into the redesign
Step 1: Measure who actually visits
MDN’s first step is to measure the devices and connections your visitors use, then translate time-based targets into file-size budgets. Your current analytics and the baseline you record before a redesign show whether your audience is mostly on phones, and how much of it arrives on slower connections.
Step 2: Choose one primary speed target
Following Kadlec’s advice, make the primary budget a timing metric for the pages that bring in inquiries: the homepage, key service pages, and the contact page. State it precisely, including the page, the metric, the threshold, and the device and network conditions it is tested under.
Step 3: Translate it into byte limits per resource type
This is the part designers use. Fill in a worksheet like the one below, using your current site and the Web Almanac medians as reference points. The budget column is a team decision; the medians describe a typical page, not a good one.
| Resource type | Current homepage | Median mobile home page (2025) | Warning level | Error level |
|---|---|---|---|---|
| Images and video | measure | 911 KB (images only) | team decides | team decides |
| JavaScript | measure | 632 KB | team decides | team decides |
| Fonts | measure | 122 KB | team decides | team decides |
| CSS | measure | 77 KB | team decides | team decides |
| Third-party tags | count | — | team decides | team decides |
Step 4: Make design decisions against the budget
With limits on paper, the familiar redesign requests turn into tradeoffs the team can discuss openly:
- Hero media: is a background video worth its share of the image and video budget, or does a single well-compressed photo carry the message?
- Type: how many families and weights fit within the font limit?
- Embeds: can maps, video players, and chat widgets load as a facade, a lightweight placeholder replaced by the real embed only when someone interacts? Lighthouse flagged 41% of mobile home pages in the 2025 crawl as able to benefit from this pattern.
- Basics: is text compression on? The same crawl found that 72% of mobile home pages compressed text resources correctly, leaving more than a quarter flagged by that check.
- Scripts: does every analytics or marketing tag have an owner and a reason to stay?
Step 5: Enforce it, then check the live site
MDN describes build-time checks, such as a module bundler’s size warnings or a file-size check in continuous integration, as the first line of defense. It also names their blind spot: development environments often lack the third-party scripts and CDN (content delivery network) optimizations of the live site. Check the budget again in production after launch, and after every significant change to tags or plugins.
Tradeoff to accept
A budget will sometimes say no to something a stakeholder wants. MDN’s guidance is to keep budgets dynamic, allowing deliberate experiments that may cost some speed in exchange for engagement. The difference is that the exception becomes a visible decision with an owner, not a slow drift nobody chose.
Practical takeaways for your next website
- Write the budget into the redesign brief, before visual design begins.
- Lead with one timing target for the pages that bring in inquiries, and support it with byte limits per resource type.
- Give every limit a warning and an error level, so the team sees problems before they block a release.
- Watch the homepage first. It is where heavy images, video, and widgets tend to gather.
- Check the live site, not only the build, because third-party tags and hosting change the real numbers.
Ready to Discuss Your Website?
If you are planning a new website, a service redesign, or custom development for your business, we’re here to help shape the work.
- Explore Our Services: Web Design · Web Development · Website Redesign
- Start a Conversation: Tell us about your project via our Contact Form or email us directly at
[email protected].