Skip to content
MemberHost

Raise your speed score and Google Web Vitals

We tune your speed score and Google Web Vitals so pages load fast, even on plugin-heavy membership and eLearning sites.

Why membership sites are a different problem

The way we look at performance for membership sites, eLearning sites, community sites, WooCommerce sites, and other heavy, often paywalled WordPress sites is fundamentally different from the popular understanding.

A static marketing site can run on a $10 server and be cached into looking fast. Membership sites are dynamic and paywalled, so most of that caching never applies. Factors such as a heavy tech stack, large numbers of concurrent users, and lots of dynamic content all demand a different approach.

It shows up differently on each platform: quiz and progress writes on LearnDash, paywall rules and checkout on MemberPress and Paid Memberships Pro, and activity feeds on BuddyBoss.

Read how we measure WordPress backend speed and performance to see exactly what we look at.

What we actually measure

Not a scorecard on your logged-out homepage. The numbers that describe what a member experiences.

  • TTFB

    Time to first byte: how long your server takes to start answering at all.

  • FCP and Start Render

    When the page stops being blank and your member sees something.

  • Web Vitals and Speed Index

    Google's own measures of loading, interactivity, and visual stability.

  • Total page load time

    The whole picture, on the dynamic pages that caching cannot rescue.

The technology behind it

We specify the hardware for fast single-threaded CPUs, NVMe storage and, on clustered setups, a failover path, because those decide how a logged-in membership site feels.

  • Servers provisioned directly

    Sites run in virtual machines on bare metal servers from data centre partners, on hardware we specify, rather than on cloud capacity resold from the big platforms.

    • Fast single-threaded CPUs, which is what WordPress leans on
    • NVMe storage
    • Virtual machines for resource and customer isolation, and easier moves between physical servers
    • Deployed in the geography you need
  • A LiteSpeed Enterprise stack we configure ourselves

    The configuration is ours, not an off-the-shelf panel's defaults.

    • LiteSpeed Enterprise, PHP and the database tuned per site
    • Caching configured per client, with Redis, Relay or other layers where they fit
    • Changes made at the server and application level
    • Adjusted as your traffic changes
  • Cloudflare

    We use Cloudflare for DNS and edge security, along with:

    • Load balancing
    • Reverse Proxy / CDN
    • Brute force attack mitigation
    • Custom rules and workers
  • Custom configured, just for you

    Every hosting environment is built around the way your membership site actually runs, rather than a one-size template.

Performance questions

Updated

Why is my membership site slow when members are logged in?

Logged-in pages are built for each member, so the page cache that makes a marketing site fast usually steps aside. Those pages typically run PHP and can involve database queries, depending on how caching is set up. How fast they load depends on the server, the database and how much work your plugins do on each request.

What do you measure when you look at speed?

The pages members actually use, not only a logged-out homepage score: time to first byte, when the page first shows something, Google's Web Vitals and total load time. The dynamic pages that caching cannot rescue are where the difference shows.

Do you use Redis object caching?

Where it suits the plugins. We configure caching per site, using Redis, Relay or OPcache where they fit. On MemberPress sites we test object caching first and leave it off if the plugins disagree with it, because MemberPress lists the Redis Object Cache plugin among its known incompatibilities.

What hardware do your servers run on?

Sites run in virtual machines on bare metal servers from data centre partners, on hardware we specify, and each client gets its own node or cluster with dedicated resources. We don't publish exact specifications, but we'll tell you what your site runs on if you ask.

Is a good speed score enough?

Not on its own. Most speed tools load a public page that is often cached, which tells you little about what a logged-in member waits for. Test the member pages too, and test them at your busiest times.

Want to know how fast your site really is?

Start with a free site speed audit. We'll look at how fast your site is today and run synthetic load tests around concurrency and PHP worker usage, and send you a report with what we would change, whether or not you host with us.