Every website has a weight problem it doesn't know about. Images get uploaded at full camera resolution, marketing adds another tracking script, the page builder loads three slider libraries for one carousel — and page weight creeps up month after month until your site feels like wading through treacle on a phone. A page weight budget is the discipline that stops this: a defined limit on how heavy your pages are allowed to be, enforced like any other budget. Here's how to set one and make it stick.
What a page weight budget actually is
A page weight budget is a set of limits on the resources a page may load: total page weight (say, under 1MB on key templates), number of requests, JavaScript payload size, image weight, third-party script weight. Like a financial budget, its purpose isn't austerity for its own sake — it's forcing trade-offs to be explicit. When marketing wants to add a chat widget, the question becomes "what are we removing to stay under budget?" instead of "sure, add it". That single shift in conversation is worth more than any optimisation tool.
Why it matters: weight is the dominant driver of load time, load time drives bounce rates and conversion, and Google's page experience signals mean it influences rankings too. Our technical SEO audits routinely find that weight — not server speed, not code quality — is the main reason a site feels slow.
Step 1: Measure where you are
Before setting a budget, measure reality. Run your key templates (homepage, main landing pages, product or service pages, checkout or contact flow) through PageSpeed Insights and WebPageTest, on mobile settings, and record: total transfer size, number of requests, JavaScript bytes, image bytes, and third-party bytes. You'll typically find two things: the numbers are worse than anyone guessed, and a small number of culprits dominate — one uncompressed hero image, one bloated script, one tag manager firing a dozen tags. Knowing the breakdown tells you where the budget will bite hardest.
Step 2: Set budgets per template, not one global number
Different pages have different jobs. A sensible starting framework for a UK business site:
- Total page weight: under 1MB for content pages, under 1.5MB for rich landing pages, and as lean as possible for checkout/contact flows.
- JavaScript: under 200KB (compressed) on content pages. JavaScript is the most expensive byte on a phone — it doesn't just download, it executes.
- Images: under 500KB total per page, with no single image over 200KB. Modern formats (WebP, AVIF) typically halve photographic weight versus JPEG.
- Third-party scripts: a separate sub-budget, because these are the fastest-growing line item. Every tag manager addition should be justified against it.
- Requests: under 50 on content pages. Each request has overhead, and on mobile networks latency multiplies it.
These are starting points, not laws — an image-led portfolio site legitimately needs more image budget than a text-led blog. The point is that the numbers are explicit and agreed.
Step 3: Assign the biggest wins first
Work the breakdown from step 1 in descending order of weight:
- Images: compress, resize to display dimensions (no 4000px images displayed at 800px), serve modern formats, lazy-load below the fold. This alone often cuts 50–70% of page weight.
- JavaScript: remove unused libraries, defer non-critical scripts, split bundles so pages load only what they use. Audit which scripts actually fire on each template — page builders and plugins load astonishing amounts of dead code.
- Third parties: inventory every tag. You'll find redundant analytics, retired A/B tools still firing, social widgets nobody uses. Each removal is free performance.
- Fonts: limit weights and styles, use modern formats, consider system fonts for body text. Web fonts are a quiet but significant weight line.
- Video: never autoplay full video as a page element; use a lightweight poster image with click-to-play. A background video can single-handedly blow any budget.
Step 4: Make the budget enforceable
A budget nobody enforces is a wish. Practical enforcement — and remember, speed is only one of the fundamentals of a good website:
- Build it into the CMS: image upload limits, automatic compression, maximum dimensions. Prevention beats cure — an editor can't upload a 12MB photo if the CMS won't accept it.
- Add checks to deployment: performance budgets in Lighthouse CI or similar, failing builds that exceed them. Developers respond to red builds faster than to polite requests.
- Quarterly reviews: re-measure the key templates, report the numbers alongside the budget, and treat overruns like financial overspends — investigated and corrected, not shrugged at.
- One owner: someone specific owns the budget. Shared ownership means no ownership.
What a budget can't fix
Honesty requires the caveat: a weight budget optimises delivery, not decisions. It won't fix a page that tries to do five jobs, content nobody wants, or a checkout with eleven steps. And don't pursue weight reduction past the point of diminishing returns — shaving the last 100KB off an already-lean page while the value proposition is unclear is performance theatre. Budget the weight, but spend the savings on clarity and content too.
If your site feels slow and you suspect weight is the culprit, our website development team runs performance audits that start with exactly this breakdown — measured, prioritised, and fixed in order of impact. Get a free consultation and we'll show you where your bytes are going.
FAQs
What is a good page weight for a website in 2026?
For a typical UK business site, aim for under 1MB total on content pages and under 1.5MB on rich landing pages, with JavaScript under 200KB compressed. These are pragmatic targets that balance rich design with mobile performance — most slow sites we audit are carrying two to five times these numbers without realising it.
How do I check my website's page weight?
Google PageSpeed Insights gives you the headline numbers; WebPageTest gives you the full breakdown by resource type, which is what you need for budgeting. Test your key templates on mobile settings — desktop numbers flatter, and your customers are mostly on phones. Record the numbers before changing anything so you can measure improvement.
Do images or scripts affect page weight more?
Images usually dominate total bytes; JavaScript dominates perceived slowness, because scripts block rendering and consume phone CPUs. Fix images first for the biggest byte savings, then scripts for the biggest experience improvement. Third-party scripts are the worst of both — heavy, render-blocking, and outside your direct control.
Will reducing page weight improve my Google rankings?
It helps, particularly through page experience signals and indirectly through better engagement (faster pages bounce less). But weight reduction alone won't rank a page with weak content or no authority. Treat performance as a multiplier on everything else you're doing right — necessary, but not sufficient on its own.
How do I stop page weight creeping back up?
Three things: CMS-level prevention (upload limits, auto-compression), deployment-time checks that fail over-budget builds, and a named owner with quarterly reviews. Weight creeps because every addition is individually reasonable; the budget makes the cumulative cost visible. Without enforcement, you'll be back where you started within a year.
