Set three numbers you can check quickly: page weight, request count, and load time on a throttled connection. Check them quarterly and before adding anything.

Why a budget rather than an audit

An audit tells you where a site is today and does nothing about where it will be in eighteen months.

Sites get slow by accumulation, and accumulation is a series of small approvals nobody had grounds to refuse.

A budget supplies the grounds: a number, agreed in advance, that a proposed addition either fits within or does not.

Which converts an argument about whether a chat widget is worth having into an arithmetic question.

Three numbers is the right amount

More than three and nobody checks any of them. These three cover the different failure modes: weight for bandwidth, requests for latency, and the timed figure as the thing that actually matters to a visitor.

Set them from where you are

Rather than from an ideal.

Measure your three most-arrived-at pages today and take the current figures.

If those are acceptable, the budget is where you are, and its job is to prevent drift.

If they are not, set the budget at where you want to be and treat the gap as work to do.

Round to memorable numbers, since a budget of one megabyte is remembered and one of nine hundred and forty kilobytes is not.

For most small business sites, something like a megabyte, forty requests, and four seconds throttled is a reasonable place to land.

The check has to be quick

Because a budget that takes an afternoon to verify gets verified once.

Open the network view, load the page, and read the three figures off the bottom of the panel.

That is under two minutes for three pages and requires nothing installed.

Write the figures in the same place every quarter, with the date, so the trend is visible rather than remembered.

The record is the part that does the work, since a single reading tells you nothing about direction.

A worked example

A business set a budget after a performance exercise brought their pages from six seconds to under three.

They wrote three numbers on the same page as their hosting details.

Eight months later somebody proposed adding a reviews widget, and the check showed it would take the home page from thirty-four requests to forty-nine.

Rather than refusing, they asked the supplier whether a lighter version existed, which there was.

The conversation took ten minutes and produced a better outcome than either approving or declining would have.

The budget had not stopped anything, it had made the cost visible at the moment of decision.

What to do when something exceeds it

Since the answer is not automatically no.

A budget is a trigger for a conversation rather than a rule.

Ask what it is worth, whether a lighter alternative exists, and whether something else can come off to make room.

The last is the most useful, since it forces the comparison that never otherwise happens: is this new thing worth more than the thing already there.

And where the answer is that the addition is genuinely worth exceeding the budget for, raise the budget deliberately and write down why.

A budget quietly ignored is worse than none, since it teaches everybody that the numbers are decorative.

Attach it to the moment of decision

Which is what makes it work rather than being a document.

The check belongs at the point where somebody proposes adding a tool, not at a quarterly review.

So the rule is one sentence: anything added to every page gets measured before and after.

That takes two minutes and is the only process step required.

Tell whoever maintains the site, whether that is you, a supplier, or a member of staff, since the check has to be somebody's habit.

The budget applies to content too

Worth saying, since these limits get read as a rule about developers and scripts.

Adding four photographs to a page spends the budget exactly as a widget does, and the person adding them is usually not the person who agreed the numbers.

Translate the weight figure into something they can act on: a maximum image size and a maximum number per page.

Those two instructions cover most of what content people do and require no understanding of the underlying budget at all.

A rule saying photographs go on at under three hundred kilobytes is followed, and a rule about total page weight is not.

Keep it in a place that survives

Since the person holding the budget changes.

Write the three numbers, the date, and the last few readings somewhere the business owns rather than in one person's notes.

Alongside the hosting login, the domain renewal date, and the list of third-party tools is the sensible place.

That way a new supplier inherits the standard rather than starting from their own assumptions.

It also means the annual removal exercise has a target to work towards rather than being open-ended.

Budget the pages, not the site

A refinement worth making once the habit exists, since one number for everything is either too loose or too tight.

A gallery page will always be heavier than a contact page, and holding both to the same figure means either permitting too much on one or refusing something reasonable on the other.

Set the budget per type: one for ordinary pages, a higher one for anything image-led, and a tighter one for anything you advertise to.

Three figures for three kinds of page is still checkable in two minutes and gives a far more useful answer.

The advertised pages deserve the tightest budget, since those are the visitors you have already paid for.

The counter-case

A budget can become an obstacle.

Refusing something genuinely valuable because of a number chosen arbitrarily eighteen months ago is a bad outcome, and the numbers should be revised as the site's purpose changes.

Very small sites also drift slowly enough that a budget is more process than they need.

And a business with a supplier who handles this competently does not need to hold the numbers themselves.

Set three numbers from today's figures, check before adding anything, and record the readings quarterly.

Setting it up

  1. Measure your three main pages.
  2. Take weight, requests, and throttled time.
  3. Round to memorable numbers.
  4. Write them where the business keeps things.
  5. Check before adding anything site-wide.
  6. Ask what comes off to make room.
  7. Record the readings quarterly.

Step six is what makes a budget productive rather than restrictive, since it turns every addition into a comparison against what is already there.

Why requests matter as much as weight is covered in testing on a throttled connection.


Frequently asked questions

Why a budget rather than an audit?

An audit describes today and does nothing about eighteen months from now. Sites get slow by accumulation, and a budget supplies the grounds to question each addition.

Which three numbers?

Total page weight, number of requests, and load time on a throttled connection. Those cover bandwidth, latency, and what a visitor actually experiences.

Where should I set them?

From your current figures if those are acceptable, so the budget prevents drift. Round to memorable numbers, since a budget nobody remembers is not checked.

How long should checking take?

Under two minutes for three pages, read off the network view. A budget that takes an afternoon to verify gets verified once.

What if something exceeds it?

Treat it as a trigger for a conversation. Ask what it is worth, whether a lighter version exists, and what could come off to make room.

Where should the numbers live?

Somewhere the business owns, alongside the hosting login and domain renewal date, so a new supplier inherits the standard rather than their own assumptions.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

No limit on what gets added to your site?

Measure three pages today and write the numbers down. That is the whole setup.

Start a Conversation