Performance profile · Membership & Logged-in Sites
Web hosting for membership sites — A logged-in member is not a cached page view
Your public pages are free to serve and your members area is not — which is why a site with modest traffic can feel slow every single evening.
The short answer
On a membership site the number that matters is the cost of one logged-in page view, because a page cache cannot store any of them. Every request builds the page from the database, so the constraints are CPU, entry processes and query time — which is why a membership site with a thousand members can work a server harder than a blog with fifty thousand readers.
Measure it directly: log in, time a members-only page five times, then time the public sales page for comparison. Redis object caching ships on every WordPress tier and is the only caching layer that touches the gap between those two figures; cPanel's Resource Usage shows you which limit you are actually against.
By the HostingFast team · Reviewed 24 August 2026
24/7
Support, any hour
1-click
To install WordPress
Free
SSL, issued and renewed
Daily
Backups, every day
The defining fact of this workload is one sentence: logged-in pages are personalised, so they cannot be cached. Everything else follows from it. Your public pages cost you almost nothing to serve, and every page a paying member opens costs you PHP time, database time and a slot in your entry process limit.
That inverts the usual sizing advice. Traffic volume is the wrong yardstick; concurrent logged-in members is the right one. Twenty people reading the members area at eight in the evening is real work, and it happens at the same time every day because that is when people have time to use what they paid for.
So the discipline here is to measure the logged-in path and to read the resource graph rather than the visitor count. Both are available on any plan, and neither requires you to take our word for anything.
Time the members area, not the sales page
Log in, open a members-only page and time it five times, then do the same on the public sales page. The sales page comes off the LiteSpeed cache as stored HTML and should be a fraction of the other figure. The gap between them is the real cost of your membership plugin, your theme and your queries, and it is the only number worth optimising.
Google's 800 ms TTFB threshold still applies, and a logged-in page has no cache to hide behind. If the median is poor, work through it in order: object cache on, then the slow query log over SSH, then the plugin doing a remote API call on every page load. Only after those three does a bigger plan become the right answer.
Entry processes are the ceiling you meet first
cPanel's Resource Usage plots CPU, memory and entry processes against your allocation over time. On a membership site it is usually entry processes — simultaneous requests being executed — that hit the ceiling first, because every member is generating uncacheable work at the same hour. Hitting a limit and having slow code look identical from the outside and are completely different problems.
Read the graph before buying anything. Sustained pressure during ordinary evening hours means the account is genuinely too small: Nitro carries 2 cores and 4 GB of RAM with 200 GB of NVMe and applies in place. A single daily spike usually means a scheduled job, and that is a scheduling fix rather than a capacity one.
Object caching is the only cache you get
A page cache stores finished HTML for anonymous visitors and is useless to you here. An object cache stores the results of individual database queries, which is exactly what a personalised page repeats — membership level lookups, capability checks, content protection rules, the same option rows on every request. Redis and AccelerateWP ship on every WordPress tier.
Check it is actually running rather than merely installed. A drop-in that was never activated, or one being flushed constantly by another plugin, is a common state and it looks like a cache you do not have. Time a logged-in page with it off and on, at the same hour, and keep both numbers.
Recurring billing, dunning and the jobs behind them
Renewal charges, retries and expiry reminders are scheduled work, and WordPress fires wp-cron on page loads by default — which means the job runs when a visitor happens to arrive, or piles up when nobody does. Move it to a real cron entry from the panel and the billing run becomes predictable instead of a mystery that correlates with traffic.
That predictability matters commercially, because a large share of subscription cancellations are expired cards rather than unhappy members. Automatic retries, expiry reminders and a grace period before access is cut recover most of them, and none of it works reliably on a scheduler that only runs when somebody visits.
For sites where the traffic is signed in
This is the workload that punishes the usual assumptions, so a HostingFast account is set up to let you check them: Resource Usage graphs, real logs over SSH, per-site PHP switching, and object caching included rather than sold separately.
The public half still gets everything a brochure site would — a LiteSpeed cache engine in the server, NVMe storage, built-in WebP conversion and free SSL that reissues itself before it can lapse.
- Redis object caching and AccelerateWP on every WordPress tier
- Entry process, CPU and memory usage graphed against your limits
- Real cron entries from the panel instead of wp-cron on page views
- In-place upgrade to 2 cores and 4 GB when evenings get busy
Why HostingFast
Standard on every plan
The right cache for the job
Redis object caching on every WordPress tier — the only layer that speeds up pages a member is signed into.
See the ceiling you are hitting
Resource Usage separates entry process limits from slow code, which are the two things a membership site confuses daily.
Scheduled work that actually schedules
Replace wp-cron with a real cron entry from the panel, so renewals and dunning run on a clock rather than on traffic.
CPU when the evening peak needs it
Nitro brings 2 cores, 4 GB of RAM and 200 GB of NVMe, applied in place with no migration and no downtime.
Logs you can actually read
SSH access to the error and slow query logs, so a slow members page becomes a query you can name.
Members-only content, properly protected
Isolated accounts, Imunify360 on the platform and daily self-service restores, so protection failures are recoverable.
Quick Start
From order to online
- 1
Get two figures, logged in and out
Five timed runs on a members-only page and five on the sales page. The gap is what your membership stack costs per view.
- 2
Read the resource graph before buying
Check whether you are at the entry process ceiling in the evenings or merely running slow code. The fixes are entirely different.
- 3
Move the scheduler off page loads
Set a real cron entry for wp-cron from the panel, so billing retries and reminders run at fixed times rather than when a visitor calls.
Built In
Loaded onto every plan
- Redis object caching and AccelerateWP on the WordPress tiers
- NVMe storage on every tier for uncached, logged-in pages
- cPanel Resource Usage: entry processes, CPU and memory over time
- Real cron entries configured from the control panel
- SSH access to error and slow query logs
- Per-site PHP version switching from the control panel
- Daily backups with self-service restores from the panel
- Imunify360 on the platform, with isolated accounts
- Staging copies for testing a membership plugin update
- In-place upgrades to Nitro: 2 cores, 4 GB RAM, 200 GB NVMe
Frequently Asked
What people ask us most often
Why does the members area feel slower than the public site?
Because it cannot be cached. Every logged-in page is personalised, so the server builds it from the database on each request while anonymous visitors are served stored HTML for almost nothing. That is why a membership site with a thousand members can work a server harder than a blog with fifty thousand readers, and why CPU and object caching matter more than bandwidth.
Which resource limit does a membership site hit first?
Usually entry processes — the number of requests being executed simultaneously — because members all arrive in the same evening window and none of their page views can be served from cache. Read Resource Usage in cPanel before buying anything: sitting at the ceiling is a capacity problem, while slow code with idle graphs is not.
How do I check my object cache is actually working?
Time a logged-in page five times with it disabled, then five times with it enabled, at the same hour. Installed-but-inactive is a common state, usually because the drop-in was never activated or another plugin is flushing it constantly. If the two medians match, you have configuration to fix rather than hardware to buy.
Should renewal billing rely on wp-cron?
No. By default WordPress fires wp-cron on page loads, so your billing retries and expiry reminders run whenever a visitor happens to arrive. Set a real cron entry from the panel instead. Involuntary churn from expired cards is the cheapest churn to recover, and recovering it depends on a scheduler that runs whether anyone visits or not.
Keep reading
Pet Sitters — Hosting Guide
A small service site at the opposite end of the scale: everything cacheable, nothing logged in.
Music Teachers — Hosting Guide
A teaching site with the same logged-in problem and a video question on top of it.
SSL Certificate (Glossary)
What TLS is doing on a members area, and how to confirm yours is configured properly.
Secure Hosting — Built for Membership Sites
Imunify360, isolated accounts and hardened defaults for a site holding member records.
Domain Names
Register or move the name the members area lives on, first year free on annual plans.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Time a logged-in page.
Then time the sales page. The gap between them is the only performance number a membership site should care about.
View Secure Hosting — Built for Membership Sites plans