I’ve seen it happen on many sites. A WordPress site launches fast, with careful image optimisation, a lean theme and minimal scripts. Six months later, it’s noticeably slower. Nobody made a single bad decision. A marketing pixel was added. A chat widget went in. A slider plugin appeared on the homepage. Product images were uploaded at full camera resolution. A new font weight crept into the design. Each change was small. Together, they doubled the page weight.
Performance doesn’t usually collapse; it erodes. A performance budget is how you stop the erosion. It’s a set of agreed limits, like maximum page weight, number of requests or loading time, that the site isn’t allowed to exceed without a deliberate decision.
Here’s how I set performance budgets for WordPress sites and how to keep them working after launch.
What a performance budget is
A performance budget is simply a list of limits for measurable aspects of your pages. For example:
- Total page weight on the homepage: no more than 1.5 MB.
- JavaScript: no more than 300 KB compressed.
- Largest Contentful Paint on mobile: under 2.5 seconds.
- Third-party scripts: no more than five domains.
When a change would push a page over budget, the team has to decide: optimise something else to make room, reject the change or consciously raise the budget with a clear reason.
The value isn’t in the numbers themselves. It’s in making performance a visible part of every decision.
Types of budgets
Quantity-based budgets
Limits on things you can count directly:
- Total page weight.
- JavaScript size, compressed and uncompressed.
- CSS size.
- Image weight.
- Font files and weights.
- Number of requests.
- Number of third-party domains.
These are easy to measure and understand, and they’re directly influenced by everyday decisions, like adding a plugin or uploading an image.
Milestone-based budgets
Limits on how quickly things happen:
- Largest Contentful Paint.
- Interaction to Next Paint.
- Cumulative Layout Shift.
- Time to First Byte.
These reflect user experience more directly, but they vary with network conditions and devices.
Rule-based budgets
Scores from tools, like a minimum Lighthouse performance score. Easy to communicate, but scores fluctuate and can hide specific problems. I use them as a supporting signal, not the main budget.
A good budget usually combines a few quantity limits with Core Web Vitals targets.
Step 1: Measure your current state
Before setting limits, measure your key page types:
- Homepage.
- A typical blog post.
- A service or landing page.
- For stores: a category page, a product page and the checkout.
For each, record page weight, JavaScript size, number of requests, third-party domains and Core Web Vitals, using both lab tools and field data where available.
Lab tools like Lighthouse and WebPageTest give repeatable measurements for testing changes. Field data from the Chrome User Experience Report, shown in PageSpeed Insights and Search Console, reflects real visitors.
Step 2: Set realistic budgets
Base budgets on:
- Your current measurements: if the site is already fast, set budgets close to current values to prevent regression.
- Core Web Vitals thresholds: LCP within 2.5 seconds, INP within 200 milliseconds and CLS under 0.1 for at least 75 percent of visits.
- Your audience: if most visitors use mid-range phones on mobile networks, set tighter limits than a site used mainly on office desktops.
- Competitors: being noticeably faster than competitors is a real advantage.
Different page types can have different budgets. A product page with an image gallery may need more image weight than a text-heavy blog post. Checkout should have the strictest script budget of all.
Write the budgets down somewhere the whole team can see them.
Step 3: Make budgets visible in decisions
Budgets only work if they influence choices before changes go live:
- New plugins: before installing, measure the impact on page weight, scripts and requests on staging.
- Marketing tags: each new tag uses part of the third-party and JavaScript budget. Ask what it replaces or what can be removed.
- Design changes: new fonts, animations and large hero images count against the budget.
- Content: guidelines for image sizes and embed usage keep editors within limits.
When a request would exceed the budget, the conversation becomes about trade-offs: “This chat widget adds 250 KB of JavaScript. We’re at 280 KB of our 300 KB budget. What should we remove to make room, or is it worth raising the budget?”
Step 4: Automate checks where possible
Manual checks are easy to forget. Automation catches regressions early.
Lighthouse CI
Lighthouse CI can run Lighthouse tests in a deployment pipeline and fail the build if budgets are exceeded. A simple budget file defines limits:
Sizes are in kilobytes. For teams with a deployment workflow, this turns performance into a test like any other.
Scheduled monitoring
For sites without a deployment pipeline, schedule regular tests with a monitoring service or WebPageTest. Alert when key pages exceed budgets or when Core Web Vitals worsen.
Field data monitoring
Watch Search Console’s Core Web Vitals report monthly. Real-user monitoring tools can provide more detail and faster feedback.
Step 5: Review regularly
Schedule a performance review every month or quarter:
- Compare current measurements with budgets.
- Investigate pages that are getting heavier.
- Audit third-party scripts and plugins.
- Check whether budgets are still appropriate.
Plugin and theme updates can change performance without anyone noticing. Regular reviews catch that drift.
WordPress-specific budget threats
In my experience, the biggest sources of budget creep on WordPress sites are:
- New plugins that load assets sitewide.
- Page builder features, like animations and sliders.
- Unoptimised images uploaded by editors.
- Embedded videos and social feeds without facades.
- Marketing and tracking tags added through tag managers.
- Additional fonts and font weights.
- Chat, review and pop-up widgets.
Guardrails for each help: plugin vetting with performance checks, image optimisation on upload, facades for embeds, a tag approval process and a fixed font set in theme.json.
Communicating budgets to non-developers
Performance budgets can sound technical, but the idea is easy to explain: “Every page has a weight limit, like luggage on a flight. If we want to add something, we either remove something else or decide it’s worth paying for the extra weight.”
Link performance to business outcomes where you can: faster pages tend to see better engagement and conversion rates, and slow pages lose visitors, especially on mobile. Show before and after examples from your own site.
A budget that worked
On one client site, we set a homepage budget of 1.2 MB and 250 KB of JavaScript after a performance rebuild. Six months later, marketing wanted to add a chat widget that alone added close to 300 KB of scripts. Instead of a debate about speed in the abstract, the conversation was concrete: the widget would more than double the JavaScript budget. We agreed to load it only on the pricing and contact pages, using a lightweight button that loaded the full widget on click. Marketing got their chat, the homepage stayed fast and the budget held.
That’s the real value of a budget. It turns performance from an opinion into a shared constraint that everyone understands, and it makes trade-offs visible before they happen rather than after visitors feel them.
Start with one page
If budgets feel like a lot, start with your most important page, often the homepage or a key landing page. Set a weight limit and an LCP target, check it monthly and expand to other page types once the habit sticks.
Celebrate staying on budget
Share monthly results with the team. When a page stays within budget despite new features, say so. Visible wins keep performance a shared priority rather than a developer’s private concern.
Frequently asked questions
What’s a good page weight budget?
It depends on the page type and audience. Many content pages can stay under 1 MB, and many business homepages under 1.5 to 2 MB. Start from your current measurements and aim to stay at or below them.
Should I budget by Lighthouse score?
Scores are useful indicators, but they fluctuate and hide details. Combine specific quantity limits with Core Web Vitals targets for more reliable budgets.
How do I enforce budgets without a developer?
Use scheduled monitoring with alerts, keep a written budget and plugin approval process and review performance monthly.
What happens when a change exceeds the budget?
Optimise something else to make room, reject the change or consciously raise the budget with a documented reason. The key is making it a deliberate decision.
Final thoughts
Fast sites stay fast through discipline, not luck. Measure your key pages, set budgets for page weight, JavaScript, third parties and Core Web Vitals, make those limits part of every decision about plugins, tags, design and content, automate checks where possible and review regularly. A performance budget turns speed from a launch-day achievement into a lasting property of your WordPress site.
