Super Speedy Imports vs WP All Import Pro

Super Speedy Imports vs WP All Import Pro — the same WooCommerce imports, on the same server, measured end to end. The result that matters most is the everyday one: a full update of a 50,000-product catalogue — keeping stock and prices current from a supplier feed — took WP All Import Pro over 20 hours; Super Speedy Imports does it in about 60 seconds (~1,100–1,200× faster). On a first-time 1,000-product import SSI is about 24× faster. (A 50,000-product fresh import with images shows an even bigger multiple, but it’s a far less typical workload — more on that below.) Every dataset and config is published so you can repeat any of it.

Headline figures

Scenario	WP All Import Pro	WP All Import + SPRO	Super Speedy Imports	SSI + Scalability Pro	SSI advantage
50,000 full update (the everyday job)	20h 11m	2h 23m	66s	59–61s	~1,100–1,200× vs WP All Import; ~140× vs +SPRO
1,000 products (no images)	3m 48s	—	~9s	~10s	~24× faster
50,000 products (with images) — less typical	65h 59m	—	~6m 22s	~5m 54s	~620–670× faster

Hetzner CPX32 (4 vCPU, 8 GB), WooCommerce 10.3 / PHP 8.2 / MariaDB 10.6 / WordPress 7.0. SSI 2.55.7 (8 workers); WP All Import Pro 5.0.6 + WooCommerce add-on 4.0.6; Scalability Pro with indexes + options. Same feeds, same images, snapshot-reset between runs. “—” = WP All Import + SPRO not tested for that scenario (measured for the update only). The 50,000-product fresh import is an extreme, less-typical one-off (and its feed reuses images, which distorts disk usage) — judge us on the update. This is one controlled scenario, not a universal benchmark.

In plain English — what should you choose, and what to expect

You run a small shop (a few hundred to ~1,000 products)

Both plugins will get the job done. The practical difference is seconds vs minutes — SSI imports 1,000 products in about 9 seconds where WP All Import takes nearly four minutes. If you import rarely and your catalogue is small, either is fine; pick SSI if you’d rather not sit and wait. You don’t need Scalability Pro at this size.

You have a large catalogue (10,000–50,000+ products)

This is where speed stops being a convenience and becomes a constraint. A 50,000-product fresh import took WP All Import nearly three days versus about six minutes for SSI. (A first-time import that big is uncommon — the everyday win is updates, below — but it shows how the gap widens with scale.) On modest or shared hosting, WP All Import’s long runs are also prone to timing out and needing restarts. If your catalogue is large, choose Super Speedy Imports.

You update from a supplier feed regularly (the big one)

If you re-import a feed every hour or every night to keep stock and prices current, import time is everything. A full 50,000-product update took WP All Import over 20 hours — you simply can’t run that hourly. SSI applies the same update in about a minute. Even WP All Import tuned with Scalability Pro takes 2h 23m — far better than its 20-hour baseline, but still nowhere near a minute. Add Scalability Pro for recurring updates: it makes the update not just fast but reliably fast, removing a worst-case database query plan that can otherwise make an un-tuned update unpredictable. This is the single strongest reason to switch.

You’re an agency or developer doing migrations

SSI is CLI-driven (wp ssi …), runs parallel workers, and uses bulk SQL — so its per-product cost stays flat as the catalogue grows, while WP All Import’s per-product time rises with scale (~0.23s/product at 1k → ~4.75s/product at 50k). That predictability is what makes large migrations and scheduled jobs sane to plan around.

You already run WP All Import + Scalability Pro

Scalability Pro has long been how stores speed WP All Import up, and the boost is real: with SPRO applied, a 50,000-product update drops from 20h 11m to 2h 23m — about 8× faster. But Super Speedy Imports does the same update in about 60 seconds — still roughly 140× faster than SPRO-tuned WP All Import — and SPRO then makes SSI’s updates rock-solid too. So you can keep Scalability Pro and simply switch the importer: same optimisation layer, a vastly faster import engine underneath.

What to buy, in one line

• Fast, painless imports and updates: Super Speedy Imports.
• Large catalogue + frequent feed updates (and you want serving speed + stable recurring imports): Super Speedy Imports + Scalability Pro.

The detail, scenario by scenario

Open the full data for any scenario — per-stage timings, telemetry and a reproduce bundle on each run page. Super Speedy Imports pages include both the standard and Scalability Pro results; where a Scalability Pro run was measured for WP All Import (the update), it has its own page too.

Full per-plugin write-ups: Super Speedy Imports benchmarks · WP All Import Pro benchmarks.

Why the gap is so large

• Bulk SQL vs row-by-row. WP All Import processes a feed one row at a time through WooCommerce; SSI matches and writes in bulk SQL across parallel workers. That’s why SSI’s per-product cost stays flat while WP All Import’s grows with catalogue size.
• Disk efficiency. SSI de-duplicates images by URL (each unique image stored once) and lets you cut the scaled image sizes WordPress generates. The 50k benchmark’s 32× disk gap is exaggerated by its reused-image feed, but the two saving mechanisms are real on any catalogue.
• Updates are mostly database work. With no images to fetch, an update is pure matching + writing — exactly what bulk SQL is fastest at, which is why the update gap is the biggest of all, and why it’s the result we’d point you to first.

Methodology

• Server: Hetzner CPX32 — 4 vCPU (AMD), 8 GB RAM, 160 GB SSD, Ubuntu 24.04 LTS.
• Stack: WooCommerce 10.3, PHP 8.2, MariaDB 10.6, WordPress 7.0.
• Plugins: Super Speedy Imports 2.55.7 (8 parallel workers); WP All Import Pro 5.0.6 + WooCommerce add-on 4.0.6 (single process). Scalability Pro (database indexes + performance options) was measured on the update for both plugins.
• Fairness: identical feeds, identical images, same hardware, snapshot-reset between runs; both plugins produced the correct end-state catalogue — the difference is time (and, with images, disk).

Honest caveats. The 50,000-product fresh import is the least representative test here: a one-off import that large is uncommon, and its feed reuses ~5,000 images cycled ~10× across products (so it’s “50,000 products, ~5,000 unique images”) — which also inflates WP All Import’s disk figure, since it re-downloads each reused image. Treat that scenario’s multiples, and especially its 32× disk number, as an extreme illustration rather than a typical result; a more realistic fresh-import comparison (unique images at several sizes) is in preparation. The update benchmark has no such caveat. Both plugins always faced the identical feed; this is not a universal benchmark — your data, images, hardware and hosting will differ.

Reproduce it yourself

Each scenario’s run page includes a download bundle with the exact CSV feed, taxonomy definitions, the Super Speedy Imports config and the WP All Import Pro template we used, plus our raw timing results and step-by-step instructions for both plugins. Start from the run links above. If your results differ significantly, tell us — we’d like to know.

FAQ

Is this a fair comparison?

We ran both plugins at their defaults on the same server, with the same feeds and images, and both produced the correct catalogue. We publish every dataset, config and template so you can verify it.

Do I need Scalability Pro?

Not for one-off imports — SSI is already fast without it. SPRO’s value is recurring updates (fast and reliable) and faster front-end serving on large catalogues. If you import from a supplier feed on a schedule, it’s worth it.

Does WP All Import really take that long?

These are the times we measured on a 4-vCPU VPS at default settings. WP All Import is a capable, general-purpose importer; the row-by-row model is simply what sets these times at scale. Download a bundle and check on your own hardware.

Will I see the same numbers?

Absolute times depend on your hardware, hosting and image sources. The relative differences — especially on large catalogues and updates — should hold.