Choosing an Ajax Type
The Ajax Type setting controls how the plugin fetches each visitor’s real price after the cached page loads. All five types return the same data and use the same on-page markup — they differ only in how much of WordPress and WooCommerce loads to answer the request, which trades speed against compatibility.
You’ll find it on Super Speedy → AJAX Prices → Settings tab, as a single radio group. It replaces the older Transport + Enable Fast Ajax options (stores that had those set are migrated automatically).
The one rule that matters: faster types skip more of WordPress. Some pricing, membership and bundle plugins depend on the parts that get skipped, so a faster type can quietly return base prices instead of dynamic ones. Never switch to a faster type without confirming your prices still match — the built-in Benchmark and Test tools do exactly this. See Verify before you switch below.
For most stores, start on Normal Ajax, run the benchmark, then switch to Fast Ajax if it is faster and still returns the right prices. Only reach for REST or Ultra once the benchmark confirms them for your plugin stack.
The five types
| Type | Option value | How it fetches | Speed | Compatibility |
|---|---|---|---|---|
| Normal Ajax | normal-ajax | admin-ajax.php, all plugins load | Baseline | Highest — the safe default |
| Normal REST | normal-rest | REST route (/wp-json/ssap/v1/prices), all plugins load | Baseline | Good, but see REST caveat |
| Fast Ajax | fast-ajax | admin-ajax.php, loads only WooCommerce, this plugin and the plugins you tick | Fast | High |
| Fast REST | fast-rest | REST route, same trimmed plugin list | Fast | See REST caveat |
| Ultra Ajax | ultra | Bypasses WordPress routing entirely; hand-boots only WooCommerce, this plugin and the ticked plugins, returns JSON and exits | Fastest | Most aggressive — verify first |
Normal Ajax (default, recommended starting point)
admin-ajax.php with your full plugin stack loaded — exactly the environment WooCommerce expects. Every pricing, membership, currency and bundle plugin behaves as it does on a normal page load, so prices are always correct. It’s slower than the trimmed types only because it loads every active plugin to answer the request. If you’re not sure which type to use, use this one.
Normal REST
The same full plugin load, delivered over the WordPress REST API instead of admin-ajax.php. Only useful if you specifically prefer REST. If you use it, exclude /wp-json/ssap/ from your page cache and CDN. Read the REST caveat below — it is not automatically equivalent to Normal Ajax.
Fast Ajax
admin-ajax.php, but a bundled must-use helper trims the active-plugin list for just this request down to WooCommerce, this plugin, and the price-affecting plugins you tick in Plugins Fast/Ultra Ajax loads. On a store with 30+ plugins this is a large saving, because a price lookup doesn’t need most of them. Because it still runs over admin-ajax.php, it keeps the high compatibility of Normal Ajax. This is the recommended “fast” choice for most stores.
Fast Ajax and Ultra skip every plugin a price lookup does not need. On a store with 30+ plugins that is a large saving on every price request, with no change to the prices themselves.
Fast REST
The same trimmed load, over REST. Same speed profile as Fast Ajax; same REST caveat as Normal REST.
Ultra Ajax
The most aggressive. Its endpoint intercepts the request before WordPress loads the other plugins, the theme, the main query or the routing layer, hand-boots only WooCommerce + this plugin + your ticked plugins, computes the prices, returns JSON and exits. It skips the most, so it’s the fastest — and the one most worth verifying, because a store whose prices depend on a plugin that isn’t ticked (or that expects a normal request lifecycle) can get base prices. (Ultra Ajax is REST-like in nature; “Ultra Ajax” is simply its name.)
The REST caveat (important)
WooCommerce only sets up the session, cart and customer object for requests it considers “frontend” — and it deliberately does not treat REST API requests as frontend. Many dynamic-pricing and membership plugins hang their logic on that customer/session context, so on a REST request they can skip it and fall back to the base price.
In practice this means the admin-ajax.php types (Normal Ajax and Fast Ajax) are the most compatible, and the REST types (and sometimes Ultra) may not reflect plugin-driven dynamic prices on some stacks.
- Every customer sees plugin-driven dynamic prices (dynamic pricing, memberships, wholesale)
- The benchmark flags a price mismatch for that type
- You cannot verify member prices as well as guest prices
Real-world example. A store running Advanced Dynamic Pricing + ADP Custom Filters + WPC Product Bundles + WooCommerce Memberships found that only Normal Ajax and Fast Ajax returned the correct dynamic prices — Normal REST, Fast REST and Ultra Ajax returned base prices for members. That store’s correct choice is Fast Ajax: it works with the full plugin combo and still captures most of the speed win by skipping the ~30 unrelated plugins.
This is exactly why the plugin ships verification tools rather than asking you to guess.
Verify before you switch
Two tools on the settings page confirm a type is both fast and correct on your store, before you commit to it:
- Benchmark (Settings tab). Times all five types on your own shop’s products and — critically — checks that each type returns the same prices as a full page load. Any type that returns different prices is flagged “prices differ” and is never recommended. Use the subject dropdown (top right) to run the benchmark as a guest, a country, or a specific logged-in customer — member-only pricing rules only fire for the member, so this is how you catch a type that’s fine for guests but wrong for members.
- Test — “See what each customer sees” (Main tab). Shows the actual prices two visitors (two countries, or Guest vs a customer) would get, side by side, with an Ajax Type dropdown so you can switch types and watch the prices. If a type shows identical prices where they should differ, that type isn’t safe for your store.
Switching to a REST or Ultra type after benchmarking as a guest only. Guest prices often match while member prices do not, so always run the benchmark as a logged-in customer who gets special pricing before you commit.
Recommended process:
- Leave it on Normal Ajax and confirm everything is correct.
- Open the Benchmark, run it as a guest and as a logged-in customer who gets special pricing.
- Pick the fastest type that the benchmark marks as returning the same prices for every subject.
- For most stores with dynamic pricing that’s Fast Ajax. For simple stores (geolocation/tax only, no plugin-driven rules) Ultra Ajax is often safe and fastest.
- Save, then spot-check a real product page and a member session.
The plugin list (Fast and Ultra only)
Plugins Fast/Ultra Ajax loads (Settings tab) is the allow-list Fast Ajax, Fast REST and Ultra Ajax load in addition to WooCommerce and this plugin. Likely price-affecting plugins are pre-ticked; add any other plugin that changes your prices (dynamic pricing, memberships, wholesale, multi-currency). Normal Ajax and Normal REST ignore this list — they load everything. If a Fast/Ultra type returns wrong prices in the benchmark, the usual fix is ticking the plugin that was providing the missing price rule.
Also skip the theme trims the active theme from Fast/Ultra requests. The price response is pure data, so the theme is not needed; leave it on unless a theme-provided pricing filter is involved (the benchmark will show it if so).
Quick recommendation
- Want it correct with zero thought? Normal Ajax.
- Want speed with high safety on a plugin-heavy store? Fast Ajax (verify with the benchmark).
- Simple store, chasing the lowest latency? Ultra Ajax (verify with the benchmark).
- Prefer REST for infrastructure reasons? Normal/Fast REST — but confirm dynamic prices survive with the benchmark first, as REST is the least compatible transport.
Comments