Perfmatters hosting where asset rules survive the cache.
Unloading a script on one page and not another means the cached copies of those pages must differ. Get the order wrong and the rules apply to nobody.
Order of operations is everything.
Per-page asset rules and full-page caching interact in exactly one correct sequence, and most setups get it backwards.
Unloading happens before the page is cached
If the cache stores the page first, the rules never run for anybody but the visitor who warmed it. Asset decisions are applied during generation, so the cached copy is the trimmed one.
One system rewriting scripts, not two
Perfmatters and a platform optimiser both deferring the same script produces assets that break on some pages only. Rewriting is enabled in a single layer, deliberately.
Different pages, different cached output
A rule that unloads a slider script everywhere except the homepage means those pages genuinely differ. The cache keeps them as separate entries rather than one shared copy.
Rules that survive a purge
Asset configuration lives in the database, not in the cache, so clearing the cache rebuilds trimmed pages rather than restoring the untrimmed ones.
Undo an unload that broke something
Removing a script that something else depended on is a subtle break, often on one template. A restore point is quicker than bisecting the rules.
Two optimisers, one page.
The symptom is a scorecard that improved on the page you tested and nowhere else, because the rules ran once during generation and the cache kept a copy from before.
- Asset rules applied during page generation
- Script rewriting enabled in one layer only
- Per-page differences cached separately
- Configuration outside the cache
The gain has to reach every visitor.
Asset trimming that only applies on a cache miss is a measurement artefact. The number worth having is a cached page delivered to somebody who did not warm it.
What we change for asset-control plugins
None of this changes what the plugin does. It changes whether what it does reaches anybody.
| Setting | What we do | Why |
|---|---|---|
| Rule ordering | Asset decisions applied while the page is generated | A page cached before the rules run keeps every script the rules were meant to remove, and only the visitor who warmed it ever saw the trimmed version. |
| Rewriting layers | Script deferral and combination enabled in one place | Two systems rewriting the same asset produce output that breaks on a subset of pages, which is close to impossible to attribute afterwards. |
| Cache variants | Pages with different asset rules cached separately | Unloading a script on some templates means those responses genuinely differ, so a single shared cache entry has to be wrong for one of them. |
| Configuration storage | Kept in the database rather than derived from cached output | Clearing the cache should regenerate trimmed pages, not silently restore the unoptimised ones until somebody notices. |
| Dependency checks | Reviewed per template before rules go live | Removing a script that another one depended on breaks a single template quietly, which is the failure mode of aggressive unloading. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
My scores improved in testing but not in the field. Why?
Can I use Perfmatters alongside host-level optimisation?
Does per-page unloading break caching?
I unloaded a script and one template broke. How do I find it?
Make the optimisation reach visitors.
Move the site across. Migration is free, asset rules reviewed.