Many plugins load their full set of scripts and styles on every page by default, regardless of whether that specific page uses any of the plugin’s functionality at all — a contact form plugin loading its scripts on every page rather than just the contact page, for instance — which adds unnecessary weight sitewide for functionality that’s only actually needed in a handful of specific places. This default, load-everywhere behaviour is understandable from the plugin developer’s perspective, since predicting in advance exactly which pages a site owner will actually use their feature on isn’t something the plugin can know without being told explicitly.
Check the network tab on a page that doesn’t need the plugin
Open your browser’s developer tools, go to the Network tab, and reload a page you know doesn’t use a specific plugin’s functionality, looking for that plugin’s own script or style files loading anyway.
Finding them loading unnecessarily confirms this is happening on your site, and noting which plugin and which page helps scope the work directly.
Checking a second unrelated page the same way is also worth doing, since confirming the pattern repeats rather than being isolated strengthens the case for scoping multiple plugins rather than just one. A single confirmed instance is often just the most visible sign of a broader pattern. Worth checking before assuming the scope is limited to just one plugin. It rarely takes much extra time to confirm either way. Better to know upfront than discover it partway through.
Selective plugin loading - scope to pages
Heavy plugins configured to load only on the specific pages that actually need them, instead of on every single page across your site.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Which plugins you’d like scoped, or confirmation you want a general review of heavy plugins
- Which specific pages or page types each plugin’s functionality actually belongs on
- Whether you want this applied broadly, or tested carefully on one plugin first
This or something else?
| Specific plugins load sitewide when they’re only actually needed on certain pages | This fix covers it |
| You want your page builder specifically scoped, not other plugins generally | Unused builder asset unloading, a more specific related fix |
| The same script is loading twice on a page, not just loading unnecessarily elsewhere | A different, duplication-focused fix |
| You want plugin settings synced between environments, not scoped to pages | Plugin settings export & environment sync, a different service |
| You’re not sure which of your plugins are actually loading unnecessarily wide | This fix covers it; we identify that as the first step |
What we do
- Identify which plugins load sitewide versus which pages genuinely need their functionality
- Configure each identified plugin to load only on the pages where it’s actually needed
- Verify the plugin continues functioning correctly on the pages it should
- Confirm other pages no longer load that plugin’s unnecessary assets
- Test across your site’s full range of page types to catch any edge case
- Measure and report the actual reduction in unnecessary loading achieved
What is included
- Plugin loading scoped specifically to the pages that genuinely need it
- Verification that scoped plugins continue functioning correctly where needed
- Testing across page types to catch edge cases before considering this complete
- A before-and-after measurement of the reduction achieved
Not included
- Removing any plugin entirely, as distinct from scoping where it loads
- Scoping your page builder’s own assets specifically, which is a separate, related fix
- Fixing a duplicate-loading issue, which is a different, related fix
- Re-scoping the rule yourself as your page structure changes — we set the rule up, but a redesign later is a new job
Questions about this fix
Will this break a plugin if I add it to a new page later?
Not if scoped correctly — the configuration is based on genuinely identifying which pages need the functionality, and we can adjust it as your site's actual needs change.
How much faster will pages be after this?
It varies by how heavy the specific plugin's assets are, but removing genuinely unnecessary loading is a real, measurable improvement rather than a marginal one.
Is this risky to get wrong?
There's some risk in scoping incorrectly, which is why we test thoroughly across page types before considering the work complete, rather than assuming our first configuration is right.
Could this conflict with a caching plugin's own optimisation feature?
Occasionally, if both try to manage the same script loading behaviour — we check for that specifically and adjust the configuration so the two work together rather than against each other.
Will I need to redo this if I install new plugins later?
Only for the new plugin itself, if it also loads unnecessarily wide — this fix addresses the plugins scoped now, not future installations automatically.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.