How Scalability Pro Works
Most WordPress speed advice starts and ends with caching: put a page cache in front of your site, serve a saved copy, done. That works right up until it does not. A cache only helps once a page has been generated and stored. It does nothing for the first visitor who hits an uncached page, nothing for your admin screens, and nothing for an import running through thousands of rows. On a large site those uncached paths are exactly where the pain is, and if the underlying page is slow to build, even priming the cache becomes a slow job in itself.
Scalability Pro takes a different starting point. Instead of hiding a slow page behind a cache, it makes the page fast to build in the first place by fixing what is slow underneath: the database. WordPress and WooCommerce generate a lot of inefficient SQL, and on a small site nobody notices. Once your tables grow into the hundreds of thousands or millions of rows, those same queries fall back to scanning entire tables, and the site grinds. Scalability Pro attacks that directly. Here are the mechanisms it uses.
It adds the database indexes WordPress is missing
An index is what lets MySQL jump straight to the rows it needs instead of reading every row in a table to find them. WordPress ships with surprisingly few indexes on its most heavily queried tables. Tables like wp_postmeta, wp_term_relationships and wp_options were designed for small sites, so out of the box there is nothing to help MySQL filter or sort by meta_value, term relationships, post_author and similar columns. Once those tables are large, queries fall back to full table scans.
Scalability Pro provides around 40 tuned indexes covering wp_posts, wp_postmeta, wp_term_relationships, wp_options and the WooCommerce product lookup tables, chosen to match the query patterns WordPress actually uses. You add them in one click from the Indexes tab, and you can drop them again just as easily. This is the foundation that underpins nearly every other optimisation in the plugin, and it is completely safe: an index changes how fast a query runs, never what it returns.
It rewrites the slow queries WordPress generates
Adding indexes helps, but some of the SQL WordPress writes is inefficient no matter how well the tables are indexed. So Scalability Pro rewrites those patterns as the queries run.
The biggest example is SQL_CALC_FOUND_ROWS. On every archive query WordPress asks MySQL not just for the 20 posts on the page but for a count of every matching row, so it can show “Page 1 of 211”. On a shop with 100,000 or more products that count forces MySQL to examine every matching row on every page load, and it is the single biggest cause of slow archive pages we see. Scalability Pro can remove it, so the query fetches only the rows for the current page. The trade-off is that exact pagination totals are no longer calculated, which is why this option is opt-in rather than always on.
It caches the expensive counts WordPress recomputes constantly
A lot of WordPress slowness is not one heavy query but the same moderately heavy query run over and over. Counts are the worst offenders.
WordPress constantly wants to know how many posts exist in each status, and to get it, it scans wp_posts and groups by status every time you open the Posts or Products list screen and repeatedly during an import. Scalability Pro can store those totals in a dedicated cache table and read them back instantly instead. Separately, the “Mine” filter on the Posts and Products screens and the per-role totals on the Users screen each run their own uncached COUNT over large tables on every load; Scalability Pro can cache those results too. The author-count option is guarded by a version-match check so a WordPress update makes it go dormant rather than break anything.
It defers work during imports instead of repeating it per row
Some work is fine to do once but ruinous to do thousands of times. Term counting is the classic case. Every time you add or update a product, WordPress and WooCommerce recount how many items sit in each affected category, tag and attribute. During an import that recount runs once per row, counting the same terms again and again. Scalability Pro can defer it so it happens once at the end of the run, with a daily task keeping the numbers accurate afterwards. On a large catalogue this is usually the single biggest import speed improvement available.
It removes work the site does not need to do
Not every fix is about queries. Plenty of speed is lost to work that serves no purpose on your site. Scalability Pro can trim it: blocking specific outbound HTTP calls that plugins make while wp-admin pages render (which hang your admin pages when a third-party server is slow), switching off query-heavy WooCommerce dashboard widgets and marketplace adverts, shortening Action Scheduler’s retention so its tables do not grow into millions of rows, and stopping WordPress generating image sizes you never display so imports do less CPU and disk work. Each is a toggle that stops a specific piece of pointless work.
It offers a pre-computed lookup table for extreme scale
At the very top end, archive and filtered listing pages are slow because they join wp_term_relationships against wp_posts on every load. The optional Super Speedy Listings add-on maintains a pre-computed “object ancestors” lookup table that maps posts to their terms directly, so those pages resolve from one indexed table instead of a large join. It builds in the background and is aimed at very large sites with heavy archive traffic; smaller sites will not see the same benefit because their joins are already cheap.
How it fits with a caching plugin
Scalability Pro is not a caching plugin and does not replace one. The two do different jobs and belong together. A page cache serves saved copies of pages to logged-out visitors; Scalability Pro makes the raw page fast to build. That matters in three places a cache cannot reach: the first, uncached hit on any page, the work of populating the cache in the first place, and everything in wp-admin and your imports, which are never cached at all. Because it only speeds up the underlying SQL, it runs happily alongside WP Rocket, LiteSpeed, W3 Total Cache, Cloudflare and a Redis object cache, and an object cache in particular is strongly recommended next to it.
Run a persistent object cache (Redis or Memcached) alongside Scalability Pro. Several of the caching options store their results in the object cache, so they are far more effective when one is present, and it costs a query build nothing to keep.
Is it safe?
The two foundations, the database indexes and the caching options, are completely safe and change no behaviour. Indexes only affect how fast queries run, and they have their own distinct names so they never touch WordPress’s own indexes or interfere with updates. Everything is reversible: turn an option off and it stops, drop the indexes and your database is exactly as it was.
The exception is the query-alteration options. Removing SQL_CALC_FOUND_ROWS, sort clauses or private-post checks changes how a query is built, and the first deliberately changes your pagination totals. These options are opt-in and worth testing on your archives after enabling. To apply an alteration to a specific slow query rather than site-wide, see Custom Query Alterations.
The query-alteration options are the only settings that change how a query is built rather than just how fast it runs. Enable them one at a time and check your archive pages afterwards, so if anything looks off you know exactly which toggle caused it.
To find out which queries are actually slow on your site before you change anything, see Finding Slow Queries. For what every setting does and where to find it, see the Settings and Options Reference.
Comments