In WordPress 6.0, websites with more than 10,000 users will see improvements in handling users. Prior to changes in #38741, sites with more than 10,000 users would suffer from slow page loading time in the user and post list screens. 

The user screen was slow because a complex SQL query was run to get the number of users for each role. This sometimes resulted in page timeout or failures to load. On the post edit screen, a dropdown of authors in the quick edit option used to change the post’s author. On large sites, this results in thousands of options rendered on the page, which creates a large amount of markup and causes timeouts and slowdowns. 

Introducing large sites

The idea of a large network in multisite configurations of WordPress has existed since WordPress 3.0. A network is considered large when it has over 10,000 users. When marked as such, any real time calculation of the number of users is skipped and all counts of users are deferred to scheduled (cron) events. 

This idea of a large network has now been ported to single site installs of WordPress. Any site with more than 10,000 users is marked as large. Once this threshold is met, real time counts, such as ones noted above, no longer occur on every page load. This means that when viewing user lists, the count next to each user role will be missing. This massively improves the performance of the page 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. 

This change includes some new functions:

• get_user_count
  Now available for both single- and multi-site installations. For sites with over 10,000 users recounting is performed twice a day by a scheduled event. 
• wp_update_user_counts
  Perform a user count and cache the result in the user_count site option. 
• wp_is_large_user_count
  Determines whether the site has a large number of users. The default threshold of 10,000 users can be modified using a filter of the same name.

Now that the get_user_count is available for both single and multisite, it is strongly recommended not to use the count_users function in your code. This function is not performant and is the root cause of issues noted above. Wherever possible, every instance of count_users in core has been converted to use get_user_count, which is also recommended action for plugin authors. 

Props to @kkautzman, @milana_cap, and @bph for review and proofreading.

#6-0, #dev-notes, #dev-notes-6-0, #performance