What the Benchmarks Reveal About the Best WordPress Hosting for Course & Membership Sites

The 2026 WordPress Hosting Performance Benchmarks are one of the only independent datasets in this space. Many of these tests require collaboration with hosts in order to get past firewalls and rate limits that would throttle them, so the data isn’t readily available or something you could gather without opt-in from service providers. Kevin Ohashi of Review Signal worked directly with hosts to ensure accurate, fair and independent results. No host sponsors the testing, and every participant pays the same documented fee to cover the resources needed to send virtual traffic to strain the servers and get the raw numbers, which are made fully public. That independence and level of access is what makes these particular benchmarks worth paying attention to, and why we’ve chosen to showcase these results rather than running our own benchmarks and asking you to trust our results.

While we’re fans of the work Kevin has done, the way he has to present the data in order to maintain neutrality doesn’t rank the results or give a non-technical reader much insight about which host makes the most sense for them. The way results like these get summarized “who had the highest requests per second” or “who won the most GTmetrix locations” sometimes rewards the wrong things when your site has members log in and see pages built fresh rather than served from cache. That category is broader than you might think: course platforms (LearnDash, LifterLMS, TutorLMS), membership and community sites (MemberPress, BuddyBoss, Paid Memberships Pro), marketplaces, directories, and any WooCommerce store. The common thread is that the expensive work cannot be cached away, so the server has to do it for real, for every logged-in person, at once.

Since we host these workloads for a living, we have our own approach to interpreting the raw data. That’s why we’re showing our work, and you can check every number below in the independently published third-party data. Before we get into the numbers, though, we need to follow the journey of a page load to understand what any of it means for real-world user experience.

What happens when a student clicks a lesson

It’s 7PM and course work is due at 8PM. A student navigates to Lesson 14 on your course site in a last-minute scramble to finish on time. Her browser asks your host for the page. If she were logged out and asking for the homepage, the host would hand back a copy it prepared earlier, possibly from a server down the street from her, and be done in a few milliseconds. Caching is great like that. But she’s logged in, and Lesson 14 has to include her progress bar, her quiz attempts, and her group’s discussion thread. There’s no prepared copy of that page and there can’t be, because the page didn’t exist until she asked for it.

Her request travels all the way back to the origin server, and the server starts working. Confirm her session. Check what she’s allowed to see. Fetch her course progress, her completed topics, her group enrollment. It’s all in the LearnDash database and fetching it all can get heavy. Assemble the page. Send it back. Now multiply this process by every other member who’s also frantically logging in last-minute before the deadline, with each of them asking for their own pages with their own lessons, groups, certificates, discussions, etc. all of which have to be built on-the-fly.

That’s the workload for courses, memberships, communities, stores, and directories. Different plugins, but similar demands on your hosting plan. The expensive work can’t be cached away, so the server has to do it fresh for everyone at once. Every test in this benchmark measures a part of that picture, or sometimes measures something else entirely while appearing to. The rest of this page maps out how the benchmark results actually impact the student’s journey, and which results don’t.

The short version

For a site serving dynamic uncached pages, the metrics that predict real member experience are:

• Database throughput – can the server actually run your uncached queries fast, over and over, for hundreds of people at once.
• p95 response time under the dynamic (logged-in) load test – how slow the slowest responses get, which are the ones your members complain about and remember.
• Page and login cumulative averages under that same dynamic test – how browsing the site actually feels after you log in
  
  The most attention-grabbing metrics like peak requests per second, GTmetrix world maps, and uptime to four decimal places, mostly do not separate the good hosts from each other, and in some cases are a bit misleading. Here’s how we think about each one.

What the RPS column actually counted

Picture the load test from the server’s side.

The testing rig starts sending visitors. Not real students, but convincing bots. Each one lands on the site, logs in, and loads a page the way a member would. A few hundred of them at first, and then steadily more. Every one of them logs in, so each page takes the full origin trip from the walkthrough above. The test rig keeps a counter of how many requests the server answers per second. That counter is the RPS number.

Now the question that decides what that number means: how did the test end?

Two possible endings. Either the server starts to buckle, responses stretch, errors pile up, or the test rig runs out of traffic to send before any of that happens. If a server buckled at 600 users, its peak RPS is a real ceiling. That ceiling means that any additional requests cause things start to slow to a crawl and then break. If the test rig hits the maximum traffic it was designed to send and the response-time graph stayed flat the whole way through, the peak RPS records the limits of the test instead of the limits of the hosting plan. The server answered everything it was asked, and then sat waiting for more.

In the 2026 results, every host worth shortlisting ended the second way. Ohashi’s write-up acknowledges the ceiling was never found, though that’s easy to miss when the RPS table is sitting right there asking to be used to rank the hosts. The temptation is to take two survivors, whose counters stop at say 940 and 998 requests per second, both with flat response times and near-zero errors and to read that as second place and first place. But the test never asked the question ranking them that way would imply. They’re two students who finished the exam with twenty minutes to spare. One handed in the test a few seconds sooner, and that tells you exactly nothing about which student would have done better on a harder exam because nobody gave them one.

The column can do worse than say nothing, though. Imagine the 7pm rush on two different hosts. On Host A, the one with the bigger RPS number, our student clicks into Lesson 14 and her page comes back in 600 milliseconds, because the server is juggling more requests by holding each one longer. On Host B, with a smaller RPS number, the same click comes back in 150ms. Host A wins the RPS column. She’s waiting on one page, hers, and is only aware that the site feels slow to her. She doesn’t know or care that more requests are being answered, just how quickly hers is answered. Her experience shows up in a different set of numbers.

So RPS gets one job in our scoring: did the host clear the full run without buckling? A few didn’t, and they’re disqualified. Everyone who did moves on, and that’s it for RPS.

p95 and the cumulative averages: where the wait time shows up

The test rig counted requests, but it also tracked how long every single response took. That pile of timings is the closest thing in the dataset to what a user actually feels when they’re using the site.

Suppose a server answers most requests in 150 milliseconds, but under load one request in twenty stretches past a second. The average still looks lovely. The student doesn’t experience the average. She makes more than twenty clicks in her evening study sessions, which means she lands on a slow one almost every night. The inconsistent slowness is what she remembers, and what makes your site feel unreliable to her.

p95 is the number built exactly for this. It lines up every response time from fastest to slowest and p95 is the mark that 95% of them beat. One request in twenty is slower than the p95. A low p95 means that even the site’s worst load times stayed quick, and even the student at the back of the line moved through quickly.

The page cumulative average is more straightforward: how long the HTML pages took to build and return, averaged across the whole run. The login cumulative average is the same measure for the login path specifically, which deserves its own number because on a membership or course site, logging in is the start of every journey, and one of the heavier authenticated operations a WordPress site performs in these tests.

A host with a low p95 and low page and login averages on the dynamic test is a host where members feel the site is fast even when it gets busy. That’s the thing worth paying for.

A word of caution before you go and try to rank hosts by these columns, though. The skepticism around the RPS numbers applies here too: a host at 148 milliseconds and a host at 160 shouldn’t be ranked against each other. Differences that small are easily explained by the test rather than the hosts. The test rig sitting a few network hops closer to one data center than another, or one test window catching more congestion on the public internet than another. Treat close numbers as a tie and save your attention for the large gaps.

Uptime: three monitors, three different stories

Uptime looks like the easiest column to rank, but it isn’t as simple as it appears.

The benchmark used three monitors: HetrixTools, StatusCake, and a self-hosted UptimeKuma instance. On several hosts the three monitors disagree wildly. The clearest case in the entry tier: one host got 99.93% on StatusCake but 94.48% of HetrixTools and 91.98% on UptimeKuma, while its load tests and static tests on the same plan both ran clean. Those last two figures describe a server that went missing for weeks out of the year! It’s highly unlikely that a host was down for that long, especially when one of the monitors missed that gap entirely if it happened. It’s also unlikely that a host with that much downtime also happened to ace a sustained load test in the same dataset.

A firewall, on the other hand, behaves exactly this way. Uptime monitors are bots. Often these are the same few IPs asking for the same page over and over again, which is also what a lazy attack looks like. Some hosts’ security layers eventually treat the monitor accordingly and throttle it, block it, or serve it nothing. The monitor records this as “down” even if the server was up. The bouncer just didn’t let them into the club and they’re bummed about it. The same pattern shows up elsewhere in the data, with one host showing an identical sub-99.8% UptimeKuma figure in every tier it appears in, while both third-party monitors report everything as normal. This test seems particularly prone to monitoring artifacts, and tighter coordination with a more involved and carefully designed process would have been necessary to get an apples-to-apples comparison.

None of this means uptime doesn’t matter. It means that in this dataset, the real differences between hosts are hidden in the bot-detection noise, so fourth decimal places mostly measure how each host’s firewall feels about synthetic traffic, not how often your students will find the site inaccessible.

Just like the RPS, we read the column as pass/fail. Every host passed.

GTmetrix: a world map of a page your members never see

GTmetrix loads the site’s homepage from twelve cities around the world and times each one. The results make a satisfying map. The question is which version of the site the map is timing.

We’ve covered how different the student logging in to do course work at rush hour is from just serving up a home page. The logged out home page visitor just gets the prepared cached copy served from an edge node near the visitor, the server doesn’t even come into play. That’s the path GTmetrix tests, twelve times over. Your members aren’t having the experience GTmetrix tests for because their pages can’t be served from an edge, and each one has to make the full trip back to the origin server to be built. A host can light up the whole map green because its edge cache answers quickly from everywhere, while the machine that actually builds Lesson 14 never gets touched by the test.

The geography the map rewards is also a solved problem. If your students are mostly in North America, you put the data center in North America, and Singapore’s opinion of your homepage stops mattering. Many hosts allow you to pick a location that works for you. A host with a middling worldwide average because its test site sat in one region isn’t slow, it’s being measured from 12 places when its users likely live in one.

GTmetrix traffic is also automated, same as the uptime monitors, so it can trip the same security layers. The firewall thinks a bot from Dubai is suspicious and suddenly one throttled run in one city drags an average down without saying anything about how long a real visitor has to wait for a page. It’s vulnerable to the same testing artifacts from the random nature of the proximity of the GTmetrix test servers and CDN edge nodes along with global network congestion at test time which was different for every host tested.

We don’t think this test answers any questions for course & membership site owners when it comes to hosting so we don’t weight it in our rankings. It’s a good tool for frontend optimization, but won’t help much with comparing hosts.

PHP Bench vs WP Bench: which stopwatch matters

The benchmark runs two synthetic server tests: PHP Bench and WP Bench. Casual readings might blend them together even though they time completely different things.

PHP Bench times pure computation. 100,000 math operations, 100,000 string operations, a million loops, a million conditionals, and five million AES_ENCRYPT rounds, reported in total seconds. It’s just hammering a single CPU core with problems to solve. A great score tells you one core on that box is quick at math and encryption. It never touches the database or runs anything resembling what your site actually does to serve a request. It’s like trying to figure out how well a restaurant copes with the dinner rush by timing how fast one sous-chef chops onions. At best it tells you roughly what kind of CPU core one of the CPU cores is in that host’s architecture.

WP Bench is the one to watch. 250 inserts, selects, updates, and deletes pushed through WordPress’ database layer ($wpdb) reported as queries per second. Progress lookups, permission checks, group enrollments, quiz states, etc. are all database operations travelling along the same path WP Bench times. It’s still synthetic, but it’s measuring the kind of thing that matters.

Notice what this test doesn’t involve: the internet. WP Bench runs on the server itself. There’s no route from a test rig for congestion to vary, no twelve cities, no firewall mistaking anything for a bot, because nothing external is involved. The queries travel the host’s own internal path, the same path our student’s Lesson 14 queries travel. Of all the numbers in this dataset, it’s the one least contaminated by everything that isn’t the host. Least, not zero: it’s still one run on one particular day, and whatever else the box was doing that moment is in the measurement. But every other noise source we’ve flagged so far is ruled out.

These plugin tests usually get called single-threaded, and Ohashi made the same point discussing the 2026 results. Plenty of plans may be running complex distributed architectures that single-thread tests undersell, and he pointed to hosts with much slower bench scores that still held up fine on the load test that in his words “actually gets graded”. Fair enough, but with one precision worth adding for WP Bench: the plugin sends its queries one at a time, but it gets no say in what answers them. What answers them is the host’s entire database setup. The MySQL configuration, the storage under it, the internal network in a distributed build, however many threads any of that involves. So WP Bench is a fair timing of how fast one stream of real WordPress queries comes back. That one-at-a-time stream can’t show how that same machinery holds up when two hundred students make requests at once, that’s the load test’s job, which is why our scoring uses the two. We first gate on whether the host handled everything thrown at it without showing signs of breaking a sweat, then rank the survivors by WP Bench and response timings. Any one of these alone can’t tell you which host beats another, especially since the load test didn’t find the upper limit for many hosts, but together they can paint a pretty clear picture. (The dataset’s composite WPBenchmark score mostly tracks WP Bench, for what it’s worth, but the raw queries per second data is more meaningful for ranking purposes).

The LMS-relevant ranking

So the scoring, assembled from everything above:

1. Gate first. Did the host clear the dynamic load test without saturating? No rate limit walls? No mid-test collapse? Low errors? If a host hit a ceiling, it’s out, regardless of how good the other numbers look.
2. Rank the survivors by database throughput (WP Bench queries per second), because that’s what your uncached logged-in pages depend on
3. Read the response-time distribution. p95 and the page / login cumulative averages from the dynamic test as the tiebreaker and the experience check.
4. Use RPS to confirm the host cleared the load with room to spare, never as a ranking axis

Disqualified at the gate

Before the ranking, here are the hosts that didn’t clear the dynamic load test, and are therefore out for LMS use-case at that price tier. This step removes more hosts than people expect. A disqualified host isn’t “bad hosting”. If the price is right or the panel experience is much better for your purposes, they can be fine for static brochure sites or very light dynamic sites. They failed the specific thing this workload needs, which is to stay up and running smoothly under sustained logged-in load.

Tier	Host	Why it is out
$25-50	ScalaHosting	Slowed from ~350 concurrent users; errors by ~600 (2,896 total); no default static cache (8.9s static avg)
$25-50	InMotion Hosting	Mid-test spike, ~11,608 errors; recovered but lost the run
$25-50	KnownHost	Held to ~850 users, then sustained slow responses for the rest of the run
$25-50	CloudPress	CDN security layer interfered the whole run; result is uninterpretable, not just slow
$51-100	Raidboxes	Rate-limit wall; HTTP 429s from ~1,250 users, errors into the hundreds of thousands
$51-100	InMotion Hosting	Response times climbed steadily after ~700 users for the rest of the run

At $101-200/m no host was disqualified on the dynamic test, so it seems you really do get what you pay for. Raidboxes hit a rate-limit wall on the static test there (70,000+ 429 errors), but its dynamic test ran clean, so we’re keeping it in. Given its otherwise good performance, we’re choosing to believe it was a firewall getting in the way rather than the host failing, and the dynamic test data is what we care about. We eliminated it at the lower tier because the dynamic test had too many errors to evaluate, for all we know it’s fine but we can’t be sure.

Now we can apply the scoring to the hosts that survived.

Entry tier ($25-50/month)

Of the hosts that cleared cleanly, ranked for LMS & Membership use cases:

Rank	Host	WP Bench (q/s)	p95 (ms)	Page Cum Avg	Login Cum Avg
1	Tangible	4,695	148.7	174.4	148.6
2	WP Buzz	2,941	178.4	172.0	140.0
3	Bluehost	3,636	265.0	184.8	191.3
4	WPX	1,209	130.0	159.7	95.7
5	WordPress.com	1,637	180.3	241.9	147.9
–	Krystal, Pressable, GreenGeeks, Arsys	lower throughput	–	–	–

TangibleXP leads on database throughput by a wide margin while also posting among the lowest p95 and cumulative averages. This is the combination of running queries fastest and staying fast at the slow end an LMS needs. WP Buzz pairs strong throughput with the best page/login feel, which is why we put it ahead of Bluehost despite Bluehost’s higher raw WP Bench: Bluehost’s p95 is notably worse. WPX deserves a callout. While the throughput is middle of the pack, their response-time distribution is best in tier (though within margin of test noise).

One thing worth pointing out at this tier, because the price difference between some hosts is near double: the value spread is enormous. Measured as database throughput per dollar of monthly price, the survivors run from roughly 162 queries per second per dollar at the top down to about 6 at the bottom. That’s a 25X value gap inside a small price band. Tangible ($29) and Bluehost ($33) are in one world while WPX ($60) and Arsys are in another, paying more for less throughput. This matters most at this tier precisely because that’s where budget-sensitive buyers shop, and where the assumption “they all cost about the same so they must be about the same” is the furthest from the truth. (A few plans here are priced in euros or pounds, so the per-dollar figures suffer from some currency fluctuation. Several hosts also run coupons and deals that the list prices don’t capture. The 25X spread is far too large for any of that to explain away, but treat the exact per-dollar numbers as a loose estimate.)

Mid tier ($51-100/month)

With InMotion Hosting and Raidboxes disqualified (see above), the hosts that cleared the test cleanly rank as:

Rank	Host	WP Bench (q/s)	p95 (ms)	Page Cum Avg	Login Cum Avg
1	Tangible	4,016	114.4	147.2	117.1
2	WP Buzz	3,663	221.0	177.6	146.0
3	WPX	1,280	149.4	176.4	99.8
4	Pressable	1,370	203.7	239.5	170.8
5	Bluehost	1,387	212.6	244.7	193.6

TangibleXP takes this tier on both axes at once: highest database throughput and the lowest p95 and cumulative averages in the group. WP Buzz is the clear second on throughput. Below them the WP Bench figures bunch together, so the response-time distribution does the sorting, and WPX’s distribution is the strongest of the remaining three.

Top tier ($101-200/month)

This was the cleanest dynamic load test of the year. All four hosts cleared the LoadStorm test without hitting a ceiling, so nobody is excluded at the gate. (Raidboxes hit a rate-limit wall on the static test, but we have the dynamic test numbers which is what counts here).

Rank	Host	WP Bench (q/s)	p95 (ms)	Page Cum Avg	Login Cum Avg
1	Tangible	3,067	106.6	137.1	110.5
2	Raidboxes	2,618	232.9	166.7	209.7
3	Bluehost	1,381	221.5	245.4	194.1
4	Pressable	1,348	195.9	219.9	160.9

TangibleXP leads on every LMS-relevant metric at once: the most database throughput, the lowest p95 in the entire benchmark, and the lowest page and login cumulative averages. Raidboxes is a strong second on raw throughput, though its higher p95 and login average mean a logged-in session feels slower than the throughput number alone suggests. Its static test rate limiting is worth knowing about even though it doesn’t disqualify it here. We received the same whitelist instructions as every participant, so this suggests the host struggled to configure their firewall for the test or dropped the ball on coordination with Kevin.

How to read this when you’re shopping

You run a logged-in, database-heavy WordPress site, so score hosts in this order:

• Confirm they survive a real load test that tests dynamic visits and not just cache hits without hitting a wall.
• Weight the database throughput.
• Weight the p95 and login/page averages from the dynamic test.
• Treat uptime as pass/fail.
• Mostly ignore the GTmetrix world map and the raw RPS leaderboard.

You now know why each of those steps exists, which means you can more easily compare other benchmarks you see around the web or even run some yourself since the WP Bench plugin is available to everyone.

Check the data at the source yourself, and the same name comes out on top in all three price tiers. We’re biased because it’s our name, but the public numbers are public numbers and the scoring above is the scoring any owner of these sites should be using whether or not they ever talk to us.

Every figure on this page is in Review Signal’s published tables at wphostingbenchmarks.com. If a future benchmark pushes these hosts to actual failure and the capacity order contradicts our ranking, this page will change and we’ll note the correction.

If your site is mostly static or lightly dynamic, none of this applies to you, the original tiered awards are a reasonable starting point, and TangibleXP might be overkill for you.