Why a page speed budget beats a redesign

When a company tells me their site feels slow, the conversation often drifts toward a redesign. New theme, new platform, fresh start. Sometimes that is the right call. More often, the new site launches fast and then slowly gets heavy again, because nothing changed about how pages are allowed to grow.

A speed budget fixes the cause rather than the symptom. It is less exciting than a redesign, and it tends to work better.

What a speed budget is

A speed budget is a set of limits for each page or page type. It says, in plain numbers, how much a page is allowed to load and how fast it has to feel.

A typical budget covers:

• Images: total image weight per page, plus a cap on the largest image.
• Fonts: how many font files and weights a page may load.
• Scripts: total JavaScript weight, and a list of approved third-party tags.
• Timing: targets for how quickly the main content appears and responds.

The exact numbers depend on the site. A product page with a gallery needs a different image budget from a contact page. What matters is that the limits are written down, agreed upon, and checked.

Why redesigns drift slow

Sites rarely get slow because of one bad decision. They get slow through a long series of reasonable ones: a new chat widget, a heatmap tool, a larger hero video, a second font for headings, a tracking pixel for a campaign that ended months ago.

Each addition looks small. Nobody is responsible for the total. A redesign clears all of it out, and then the same process starts again.

A budget turns "is this worth it?" from a vague worry into a specific trade-off: if you want to add this, what are you removing?

That is the real value. It gives marketing, design, and development a shared rule, so adding something new becomes a decision instead of an accident.

Core Web Vitals in plain terms

Google publishes a set of measurements called Core Web Vitals that describe how a page feels to real visitors. They are a good foundation for the timing part of a budget. The widely published thresholds for a "good" experience are:

• Largest Contentful Paint (LCP): 2.5 seconds or less. How long it takes for the main content, usually the largest image or heading, to appear.
• Interaction to Next Paint (INP): 200 milliseconds or less. How quickly the page responds visually when someone taps, clicks, or types.
• Cumulative Layout Shift (CLS): 0.1 or less. How much the layout jumps around while loading, such as a button moving just as someone goes to tap it.

These are assessed on real visitor data, typically looking at how most visits perform rather than the best case. A page that is fast on your office connection but slow for a large share of visitors will not count as good.

Test on the phones your customers use

Most teams check their site on a recent laptop or a high-end phone on fast Wi-Fi. Many customers are on a mid-range Android phone with a weaker processor and a patchy mobile connection.

The difference is not small. Heavy JavaScript in particular takes much longer to process on a slower device, which hurts responsiveness even when the download itself is quick.

So I test on a mid-range phone, or with throttling that simulates one, as a standard part of every build. If a page meets its budget there, it will feel quick almost everywhere else.

How speed affects leads

I will not quote conversion statistics here, because the honest answer is that the effect varies by business and by page. What is consistent is the mechanism.

A slow page loses people before they read anything. A page that jumps around causes mis-taps and frustration. A form that hesitates when someone types makes the whole company feel less reliable. Each of these is friction at the exact moment a visitor is deciding whether to contact you.

Speed also helps in less direct ways. Fast pages are easier for search engines to crawl, and page experience is one of many signals they consider. Fast sites are usually simpler sites, which makes them easier to maintain and more accessible.

Putting a budget in place

You do not need to rebuild to start. The steps are straightforward.

1. Measure your key pages as they are today, on a mid-range phone and with real visitor data where you have it.
2. Set a budget for each page type, starting with the pages that matter most for leads.
3. Remove what is not earning its place: unused scripts, oversized images, extra font weights.
4. Add automated checks so new changes are tested against the budget before they go live.
5. Review the budget whenever someone wants to add a new tool or feature.

Steps three and four are where most of the gain comes from. Plenty of sites get dramatically faster just by removing things nobody remembers adding.

The takeaway

A redesign resets the clock. A budget stops it from running. Write down what each page is allowed to load, hold yourself to the Core Web Vitals thresholds on real mid-range phones, and make every new addition earn its weight. If you want a budget set up for your site, see how I handle speed on every build.