FacetWP hosting where every filter click is fast.
FacetWP turns a page into an application: each interaction is a fresh query that no page cache can help with, against an index that has to stay current.
Everything faceted search asks of a host.
The page can be cached. What happens after the first click cannot.
An index that stays current without blocking
Reindexing on every post save turns a bulk import into hours of blocking writes. Rebuilds run on a schedule and on the CLI, where they have room to finish.
Facet requests, isolated
Each filter click is a fresh query against the index. Those endpoints bypass the cache and are rate-limited on their own, so one visitor exploring every combination cannot starve the rest.
Value lookups held in memory
The list of available facet values is recomputed per request without an object cache - and it is the query that runs on literally every interaction.
A ceiling on the result set
A facet combination that matches everything is one request that reads the whole index. Pagination is enforced server-side rather than trusted to the front end.
Rebuilds that finish
A full reindex through a web request times out and leaves the index half-written, which is worse than not rebuilding at all.
Know the index matches the content.
A stale facet index is the hardest kind of bug to see: the page works, the filters work, and the results are quietly wrong.
- Index freshness against post count
- Rebuild status and duration
- One-click admin login
- Restore any daily backup from the dashboard
The second click, not the first.
The landing page is cached and fast on any host. What separates them is the request after somebody selects a filter, because that one has to be computed.
What we change for FacetWP
These differ from a standard WordPress site on the same plan, and each follows from filtering being a query rather than a page view.
| Setting | What we do | Why |
|---|---|---|
| Facet index table | Indexed, and rebuilt on a schedule rather than on every save | Reindexing per post save turns a bulk import into hours of blocking writes that lock the table the site is trying to read. |
| Facet AJAX endpoint | Excluded from the page cache and rate-limited separately | Every filter click is a fresh query, and caching the response serves one visitor another visitor's selections. |
| Object cache | Redis, sized to hold facet value lookups | The set of available values is recomputed on every request without one, and that is the query that runs on each interaction. |
| Result set | Capped, with pagination enforced server-side | A facet combination that matches everything is a single request that reads the entire index. |
| Reindex runs | Executed on the CLI with their own time and memory limits | A full rebuild inside a web request times out and leaves the index partially written, which is worse than leaving it stale. |
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.
Why does my site slow down after a bulk import?
Can facet results be cached?
How many facets can a page have?
What happens if a filter matches everything?
How do I know the index is current?
Move your filtered site to a host that tunes the query.
Free migration, an index that rebuilds without blocking, and filter clicks that stay fast.