Super Speedy Archives

Category, tag, brand and author archives that stay fast as the catalogue grows, and stay correct as it grows too. Super Speedy Archives builds one pre-flattened index of which posts sit under which terms, then rewrites your archive queries to read it instead of grinding through WordPress's relationship tables. An add-on for Scalability Pro or Super Speedy Filters.

View Pricing
Super Speedy Listings icon, list glyph on purple corner-radial gradient

Archives that stay fast as the catalogue grows, and stay correct as it grows too

An add-on for Scalability Pro

Every category page, tag page, brand page and author archive on a WordPress site asks the same question: which posts sit under this term? WordPress answers it by joining term_relationships to term_taxonomy and, if the term has children, expanding the whole term tree first. On a few hundred posts nobody notices. On a few hundred thousand it is the slowest query on the site, and it runs on the pages customers actually browse.

Super Speedy Archives answers the question in advance. It builds one pre-flattened index of which posts belong under which terms, carrying enough post columns that most archive queries never touch wp_posts at all, then rewrites the queries WordPress was going to run so they read that index instead.

0
repeated posts across a 1,200 slot archive walk, where stock WordPress showed 136
0.02s
taxonomy queries measured at version 2.1.0, down from 0.7 to 0.9s
15
indexes built with the archive table, plus one per meta key
222
test assertions across the suite, 0 failures

What it gives you back

What Super Speedy Archives gives you back

  • Category archives that do not slow down as you add products. The term hierarchy is flattened once at build time, so include_children costs nothing at query time.
  • Author archives on their own indexes. Rewritten onto the same table, with two dedicated indexes behind them.
  • Ordering from an index, not a sort. Date, modified date, menu order and title each get their own composite index when you enable them.
  • Meta ordering and filtering as real columns. Name a meta key such as _price and it becomes a typed, indexed column instead of a postmeta join.
  • The right content for logged-in editors. Every post status is indexed, so private and draft posts appear where they should, including over the REST API.
  • Pages and post types with no taxonomy included. They still show up in author archives, which they did not before version 3.1.0.
  • Correct results or none. Where a query asks for something the index cannot answer, it hands the query back to WordPress untouched rather than guessing.
  • Upkeep without a rebuild. Adding a term, re-parenting a term, publishing, unpublishing, trashing or editing a date all update the index as you work.
  • Rebuilds that never serve a half-built table. Every build writes a temporary table, indexes it, and renames it into place in one step.
  • WooCommerce stock and catalogue visibility carried on the row, so catalogue archives respect them without a postmeta lookup.

What it does

Pagination that does not repeat or drop posts
This one is worth reading twice, because it is a defect in stock WordPress rather than in any plugin. When many posts share a timestamp, SQL_CALC_FOUND_ROWS pushes the database off its index scan into a full-scan sort whose tie ordering changes with the page window, so adjacent pages slice differently ordered groups. Walking a 48,000 post author archive over 120 pages of 10 in July 2026, stock WordPress rendered 1,064 distinct posts across 1,200 slots: 136 slots wasted on posts already seen, and 136 posts never shown at all. Super Speedy Archives appends the primary key to every sort, making the order total, and rendered 1,200 of 1,200 with no repeats. Confirmed on vanilla WordPress with no plugins active, and reproduced in pure SQL.
One flattened index instead of a runtime tree walk
For every post, the table stores every ancestor term above the term it is actually attached to, along with the depth. Asking for a top-level category matches rows directly. There is no term tree to expand while a customer waits.
wp_posts removed from the query entirely
When every column a query needs is already on the index, the FROM clause is rewritten to read the index and the join to wp_posts disappears, taking the GROUP BY and DISTINCT that only existed to serve it. The 2.1.0 release measured taxonomy queries falling from 0.7 to 0.9 seconds down to 0.012 to 0.02 seconds.
Author archives, properly indexed
A query for post IDs reads the index alone. A query wanting whole posts filters and deduplicates on the index first and only then joins wp_posts, for the small paginated result rather than the entire match set.
Meta keys become typed columns
Configured meta keys are materialised as real columns of the type you declare, each with its own index, populated in a second build phase. Keys you have not configured still work, they simply take the normal WordPress path.
Built in the background, in phases, resumable
The table is populated by a single recursive query in the database rather than a loop in PHP, queued so a large site is not asked to do it inside one admin request. Phase one builds the rows, phase two fills the meta columns in batches, phase three turns the optimisation on. A part-finished build reports which phase it stopped in and carries on from there.
Kept current as you edit
Ordinary editing maintains the index: terms added or removed, a term re-parented so the hierarchy has to follow, posts published, unpublished, trashed, restored or re-dated. Writes are deferred to the end of the request, so a bulk edit does not pay for each change separately.
Run it from the command line
wp ssl build, rebuild, status, enable, disable and configure, registered under wp ssl, wp sstr and wp ssp-archives. Useful for rebuilding out of hours or straight after a bulk import.

Key details

Key details

  • Add-on, not standalone. Requires Scalability Pro, where it appears as the Archives tab.
  • Also works inside Super Speedy Filters, where it appears as the Performance tab and replaces that plugin’s bundled performance add-on.
  • MySQL 8.0 or MariaDB 10.2.2 and above. The build uses a recursive query, available since 2018 and 2016 respectively.
  • Any post type, any taxonomy. Nothing here is WooCommerce specific, though WooCommerce stock and catalogue visibility are understood.
  • Ordering columns are opt-in. Date and modified date are on by default; menu order and title are checkboxes, because each one adds a column and an index to every row.
  • Fifteen indexes are built with the table, plus two more if you enable title ordering and one for each meta key you configure.
  • Debug output is off by default, and has been since version 3.1.0.
  • The index is a second copy of the relationship data, denormalised, so it costs disk in exchange for the speed.
  • Tested against ground truth, not just against stock WordPress. The suite asserts that every row returned belongs in the archive, that paging the whole archive yields every post exactly once, and that the reported total is the true total.
  • Suites refuse to run rather than pass vacuously. Each one aborts unless the optimisation is demonstrably engaged, after a review in July 2026 found three separate ways the old tests had been passing while testing nothing.

How a build works

How a build works

Phase one: build the index
A single recursive query walks the term hierarchy inside the database and writes one row per post per ancestor term into a temporary table, along with the post columns you have enabled.
Phase two: fill the meta columns
Any meta keys you configured are populated in batches, recording the last post reached so the phase can resume rather than restart.
Phase three: index, swap, enable
Every index is created on the temporary table, which is then renamed over the live one in a single step, and the query optimisation is switched on. Visitors never query a half-built table.

Questions

Do I need another plugin to use this?
Yes. Super Speedy Archives is an add-on and cannot run on its own. It needs Scalability Pro active, where it adds an Archives tab. It also loads inside Super Speedy Filters as the Performance tab, replacing that plugin’s bundled performance add-on. With neither active it does nothing at all and says so in the admin.
What does it need from my database?
MySQL 8.0 or MariaDB 10.2.2 and above. The index is built by a single recursive query, which is a feature MySQL added in 2018 and MariaDB in 2016. Almost every host is well past both. On anything older the build cannot run.
Does it work with WooCommerce?
Yes, and it understands two WooCommerce specifics: stock status is carried on each row, and products hidden from the catalogue are recognised while the index is built, so catalogue archives respect both without a postmeta lookup. Everything else about it is generic, so it works just as well on blog categories, custom post types and custom taxonomies.
Will it work with my page builder, or with WPML?
There is no integration code for page builders, multilingual plugins, custom field plugins or SEO plugins, and none of them has been tested. The optimisation works at the WP_Query level, so anything building ordinary archive queries should be fine and anything writing its own SQL is simply left alone. If you run a multilingual site on a large catalogue, test on staging first rather than taking that on trust.
What happens to a query it cannot optimise?
It hands it straight back to WordPress. Searches, unconfigured meta keys, slug lookups, random ordering and comment-count sorting all fall back to stock behaviour. The plugin is deliberately conservative here: a slow correct answer beats a fast wrong one.
Do I have to rebuild every time I edit something?
No. Ordinary editing keeps the index current on its own. A full rebuild is needed when you change which ordering columns or meta keys are enabled, after a bulk import that bypassed WordPress, and when upgrading to version 3.1.0, which changed the schema and every composite index. Rebuild from the settings tab or with wp ssl build.
How much disk does the index use?
It is a second, denormalised copy of the relationship data, one row per post per ancestor term, wider than term_relationships because it carries post columns. Enabling title ordering adds a title column and two more indexes to every row, which is why it is a checkbox rather than a default.
What if it does not help my site?
Every Super Speedy plugin carries a 60 day money back guarantee. See the refund policy.

Invest in Speed

Choose your licence below.

Agency or host? Get in touch for custom pricing

Reviews

There are no reviews yet.

Be the first to review “Super Speedy Archives”
▲
▼
1/1