WordPress Sites with Huge Numbers of Users

WordPress sites can get really, really big. We regularly get questions from customers about sites with massive numbers of users.

An example this week was a site with over 500,000 users. The _user_meta table had grown to almost a million rows.

Once your userbase gets this big, even the simple things get complicated. Yes, large sites will need more powerful servers and databases. But some of the issues you'll encounter can't be solved only with upgraded hardware.

In this guide, we'll explain some of the things to expect once you have a WordPress site with a large number of users. For this discussion, we'll define large sites as those with over 10,000 users.

Interface Changes in the WordPress Core

Once your site has more than 10,000 users, WordPress will automatically start making changes to your site's interface. This is done to prevent slow page changes.

First, you will see changes to the “Users” screen. This screenshot below shows the “Users” screen from a site with only 9 users. You can see that there are numbers next to each role. This site has 1 Administrator, 2 Editors, 5 Authors, and 1 Contributor.

WordPress Users screen on a small site

The next screenshot is from a site with over 10,000 users. WordPress no longer displays how many users are in each role. This change prevents the screen from time outs. Click here to see background on these changes. Here's a key quote from that post:

This massively improves the performance of the page load and prevents slow database queries causing PHP timeout errors, which in turn helps ensure the user list renders every time on large sites.

Some plugins such as WooCommerce have their own workarounds for this by either pre-loading or caching the user counts. The users_pre_query filter is commonly used for this task.

WordPress Users screen on a large site

Second, you will see changes to the “Quick Edit” area of the “Posts” screen. This screenshot below shows the default “Author” dropdown in the “Quick Edit” area.

WordPress Authors dropdown in Quick Edit for a small site

On a site with over 10,000 users, this “Author” option is hidden. On large sites, you won't be able to use the “Quick Edit” area to change Post authors. It's worth noting that “Author” dropdowns can sometimes be hidden for other reasons.

WordPress Authors dropdown in Quick Edit for a large site

Third, you will change to the post editing screen. Inside the block editor, smaller sites will have a dropdown area to choose the authors. You can see that dropdown in this screenshot below.

WordPress Authors dropdown in the block editor for a small site

On larger sites, this dropdown changes to a search box, which can scale over 10,000 users.

WordPress Authors dropdown in the block editor for a large site

Other User Management Problems on Large Sites

You may find other issues when managing users on large sites. Human Made is an agency that specializes in enterprise-scale WordPress sites. They have this to say about making database queries for user information on large sites:

The fundamental issue with the default WordPress storage mechanism is the use of Post Meta for user levels and roles. To add insult to injury, roles are stored as a serialized array, so any queries for users by role results in a MySQL LIKE query on an unindexed text column (meta_value).

This screenshot below shows how user roles are stored in WordPress. It is not efficient for your site to be checking this data regularly and for 100,000's of users. For more, see our guide to how WordPress stores user data.

User roles WordPress database

There are plugins that may be able to help. Human Made have built a plugin called “Roles to Taxonomy” that creates two extra taxonomies to store user data. This results in a much faster lookup for users in a given role. We use the same approach in the PublishPress Authors plugin. This guide explains how we use taxonomy to store authors.

Another plugin to consider is “Index WP Users For Speed“. The developer of this plugin shared some background details on how it works. Here's the shorter version:

This plugin helps speed up the handling of those large numbers of users. It does so by indexing your users by adding metadata that’s easily optimized by MySQL or MariaDB. For example, when your site must ask the database for your post-author users, the database no longer needs to examine every user on your system. (In database jargon, it no longer needs to do notoriously slow full table scans to find users.)

You may consider developer tools rather than the WordPress UI to manage user changes. Tools like WP-CLI are designed to handle this kind of scale. For example, there is the cap command available in WP-CLI.

PublishPress Plugins on Large Sites

We are always cautious when people ask us, “Can PublishPress plugins run on very large websites?”

The quick answer is “Yes, we carefully optimize our plugins.”

However, answers are rarely that simple when discussing very large sites. As we've seen, with over 10,000 users, some parts of the WordPress core need modifications. You may encounter edge-case issues with plugins. These issues may appear very rarely, and only on the biggest sites.

It is never easy for any website software to support large numbers of users and content. Optimizing software so that it works at scale is always a challenge. And WordPress does have some specific issues that can cause problems with very large sites. If you have a very large site, you may need a developer available to help you solve these problems. You should absolutely test all your plugins, including those from PublishPress, on a development site before going live. This is always good advice for all websites and all plugins, but we strongly recommend it in this scenario.

  • Steve Burge

    Steve is the founder of PublishPress. He's been working with open source software for over 20 years. Originally from the UK, he now lives in Sarasota in the USA. This profile is generated by the PublishPress Authors plugin.

    View all posts

Leave a Reply

Your email address will not be published. Required fields are marked *