Why WooCommerce Is Slow: 924 ms to Build a Page, 27 ms to Serve It

Adrian Wadowski — Sun, 25 Oct 2026 19:13:29 +0000

Scrub Daddy's WooCommerce server needs 924 milliseconds to build a single product page from scratch. Its shoppers get that page in 27. The difference is a cache, and it's the reason a slow WooCommerce store and a fast one can run on the same kind of server.

Most WooCommerce stores don't get there. In August 2026, only 12.7% of WooCommerce sites got their first byte to phone visitors in 800 milliseconds or less, the line Google calls good, against 81.9% of Shopify stores, and the WooCommerce figure has barely moved in five years.

Shopify keeps every store on its own servers, and on WooCommerce it's the owner who picks the server, the PHP settings and the cache. So who falls through the cache, and what does it cost them?

If your WooCommerce store is slow, here's the server side of it, measured. I built a test store and measured it one layer at a time, using WooCommerce 11.1 with 600 products, 1,200 variations and the free Storefront theme, on PHP 8.3, MariaDB 11.4 and nginx, in Docker on my own workstation.

One product page took 473 milliseconds of server time without OPcache, 100 with it, and 1.1 from a page cache. Then I compared it with two real stores.

Why is WooCommerce slow?

WooCommerce is slow when PHP has to build each page from the database while the shopper waits. Every request starts WordPress, WooCommerce, the theme and every active plugin, which on my test store meant loading 1,392 PHP files and running 90 database queries for one product page, and only then does the first byte go out.

A page cache skips all of it, and that's why fast WooCommerce stores build pages rarely and let a cache answer everyone else.

Server response (Time to First Byte) counts everything before that first byte arrives: redirects, the DNS lookup, the connection and its encryption handshake, then the server's own work.

Good is 800 milliseconds or less. It doesn't count as a Core Web Vital itself, yet Loading (Largest Contentful Paint) can't begin until it ends, and only 43.7% of WooCommerce sites pass Loading on phones, against 87.3% of Shopify stores. The full comparison is in the speed data by platform, and the three scores themselves in the Core Web Vitals article.

Distance eats part of that budget too. A phone on a mobile network can use a few hundred milliseconds reaching a distant server and agreeing on encryption before your server starts any work, so the server itself doesn't get the whole 800 milliseconds. My benchmark measures only the server's own work, inside the same network, so read its numbers as the server's share of the wait.

Step 1: Measure the server, cached and uncached

You'll want two numbers from a product page: the server response a shopper gets, and the time your server needs when it has to build the page itself. The first decides whether you pass. The second shows how much your cache is hiding, and it's close to what every cart, checkout and account page costs, because WooCommerce never lets those be cached.

Run the Store Speed Test on a product page: paste the address of your best-selling product. The report shows the real-visitor scores Google holds for that page, and it raises "Your server takes a long time to answer" when the first byte took longer than 800 milliseconds in the lab run.
Open the same page in Chrome DevTools: in an Incognito window press F12, open the Network tab and reload. The row whose Type reads document is the page itself, and its Time column is the whole request. Click it and open the Timing tab to split that time: "Waiting for server response" is the server's share.
Repeat it with a made-up query string: add ?nocache=12345 to the address and change the number on every try. Most page caches have never stored that address, so the wait you see now is PHP building the page from scratch.
Read the cache headers: on the same row, the Headers tab names the cache that answered. cf-cache-status: HIT is Cloudflare, x-litespeed-cache: hit is LiteSpeed Cache, and an x-cache header reading HIT usually comes from your host's own cache.

From a terminal, curl gives the same two numbers. The address is a placeholder, and you'll put your own product page there, and the first command is worth running twice, because the first request may only fill the cache.

# What a shopper gets: the cached page
curl -o /dev/null -s -w 'first byte: %{time_starttransfer}s\n' https://shop.example.com/product/blue-mug/

# What PHP needs: an address no cache has stored yet
curl -o /dev/null -s -w 'first byte: %{time_starttransfer}s\n' "https://shop.example.com/product/blue-mug/?nocache=$RANDOM"

I add a third request when I test any store, mine or a competitor's: the same address with a random gclid on it, like an ad click.

The plain address is what shoppers get, and the nocache one shows the server without its cache (roughly what the cart and checkout cost). If the gclid one looks like the nocache one, every paid click waits for PHP, and that's a cache setting you can fix without a bigger server.

Step 2: Turn on OPcache and run PHP 8.3 or newer

OPcache did more for PHP itself than any other setting in the test. PHP turns every file it runs into bytecode before executing it, and without OPcache it'll repeat that work on every request, for all 1,392 files a product page loads. With OPcache the compiled code stays in memory between requests.

On one CPU core the product page dropped from 473 to 100 milliseconds, and the core served about 9 pages a second instead of 1.9.

Most hosts switch OPcache on, but some cheap plans leave it off, and you won't find a word about it in the WordPress dashboard. In cPanel, open Select PHP Version and look for opcache among the ticked extensions. On other hosts, ask support to confirm that opcache.enable is 1 for your site's PHP; the command line on the server usually has its own setting, so a check you run there won't prove anything about your pages.

The PHP version doesn't matter as much for speed. PHP 8.3 built the same pages between 2% and 9% faster than PHP 7.4 on two cores (the biggest gain was on the variable product page, 123 against 135 milliseconds).

Security is the stronger reason to upgrade: PHP 7.4 has had no security fixes since November 2022 and PHP 8.1 none since December 2025, and PHP 8.2 gets its last ones in December 2026. You'll find your version under WooCommerce > Status. Move to 8.3 or 8.4 on a staging copy first, because it's usually an old plugin that breaks.

Step 3: Cache whole pages for shoppers who aren't logged in

A page cache stores the finished HTML of a page and hands it to the next visitor without starting WordPress, and it moves the number more than anything else. In the test, Cache Enabler, a small page cache plugin, answered the product page in 1.7 milliseconds and the nginx cache in front of PHP in 1.1, against 100 milliseconds for PHP with OPcache.

With 20 shoppers asking at once, the nginx cache on one CPU core delivered 9,973 pages a second, and PHP with OPcache about 9.

Where the cache sits decides how much work it skips. Cache Enabler, like WP Rocket on an nginx server, still starts PHP for every request and only skips WordPress. WP Rocket on Apache uses rewrite rules in .htaccess to send the stored file without PHP, LiteSpeed Cache is served by the LiteSpeed web server itself, and a host cache built on Varnish or nginx answers before PHP is involved at all.

A CDN cache such as Cloudflare's goes one step further and answers from a data center near the shopper.

Don't run more than one page cache. Two plugins that both cache pages, or a cache plugin on top of a host cache that already does the job, mostly add ways for a stale page to survive a purge.

If your host caches pages, use its plugin to clear the cache and switch WP Rocket's page caching off; WP Rocket's other features (delaying JavaScript, optimizing CSS and images) work in the browser and can still be worth keeping.

What a page cache can't answer is where the slow part of a WooCommerce store lives:

The cart, checkout and My Account pages. WooCommerce marks them as never cacheable, and every cache respects that. In the test the cart page took 133 milliseconds even while the nginx cache served every product page in about 1 millisecond.
Logged-in customers. Most caches hand them pages built by PHP, and many also skip shoppers who have something in the cart, so your best customers get the slow version.
The cart fragments request, the one in step 5.
The first visitor after a purge. Saving a product, a stock change or a plugin setting can empty part of the cache, and the next shopper on each of those pages waits for PHP again.
Security tokens older than a day, and addresses the cache has never seen: search results, filtered category pages and ad links with tracking parameters. The two real stores show both.

Two fast stores, and the shoppers who fall through their cache

Scrub Daddy and Van Leeuwen Ice Cream both sell on WooCommerce, and both serve their product pages faster than most Shopify stores do. I measured one product page from each on October 4, 2026, from my own connection in Poland, three requests per test, with a script that takes the connection setup out of the server number, then opened both in Chrome DevTools.

The Scrub Daddy product page document arrives in 37 ms, answered from Cloudflare's cache

Van Leeuwen Ice Cream serves its cached product page document in 30 ms

Product page	Scrub Daddy	Van Leeuwen Ice Cream
Cached page, server wait	27 ms	21 ms
Cached page in Chrome DevTools	37 ms	30 ms
Answered by	Cloudflare's cache	Cloudflare's cache, with a server cache behind it
Same page built by PHP	924 ms	646 ms
Ad click address (gclid, fbclid, utm_source)	27 to 52 ms, still cached	228 to 233 ms, past Cloudflare
Cart fragments on a first visit	Sent, answered in 767 ms	Not sent until the cart has an item
Braintree payment setup request	Refused with 403 after 0.5 to 0.8 s	Not on the page
HTML of the page	407 KB, 150 script tags	119 KB, 71 script tags
Theme	Shoptimizer	Their own
Plugins with files on the page	15	10

Server wait is the time to the first byte minus the connection setup, the median of three requests; DevTools shows the whole request, download included, in its Time column. The cart fragments and Braintree rows come from a fresh Chrome profile with nothing in the cart.

Neither store is fast at building pages. Scrub Daddy's server needs those 924 milliseconds because the page carries a premium theme, 15 plugins with files on the page and 407 KB of HTML, more than nine times what my one-core test store needs with OPcache.

Hardly any shopper pays for it, though. Cloudflare holds a copy of the page, and every request I made, including the ones from ad links, got that copy in under 60 milliseconds.

The copy that was 36 hours old

That long cache has a price. The copy of the product page Cloudflare handed me was 130,315 seconds old, about 36 hours, and the page carries a WordPress security token, a nonce, that the Braintree payment plugin sends back when it sets up the payment buttons, and WordPress won't accept a nonce that's older than 24 hours.

On every load I recorded, that request came back 403 Forbidden after 0.5 to 0.8 seconds of PHP, with the answer WordPress gives an expired or invalid nonce: Cookie check failed.

The slowest request on the cached Scrub Daddy page is the Braintree setup call, and the server refuses it: 403 after 544 ms

So a page that carries a nonce should leave the cache within 12 hours, the shortest time WordPress guarantees a nonce stays valid, and that's why WP Rocket's default cache lifespan is 10 hours.

Scrub Daddy's Cloudflare rule keeps the page for a year, an s-maxage of 31,536,000 seconds, and that's fine for a page with no tokens. With one, the page needs a purge at least twice a day, or the plugin has to fetch its token from a request no cache stores.

Want to know whether a page carries one? Open its source with Ctrl+U and search for nonce.

The ad click that misses the cache

Every ad click arrives with a unique tag on the address: gclid from Google Ads, fbclid from Meta, utm_source and its siblings from newsletters and campaigns. To a cache that stores pages by their full address, each tagged address is a new page, so the visitor you've paid for is the one who waits.

Opened from an ad link, the same Van Leeuwen page is a new address to Cloudflare because of the gclid, and the document takes 232 ms instead of 30

Van Leeuwen shows the cost. With a fresh gclid its product page missed Cloudflare, and the document took 232 milliseconds in DevTools against 30 for the plain address (my measured server wait was about 230 against 21).

The server cache behind Cloudflare caught it, and a store without that second layer would've built the page in PHP, which for this page takes about 650 milliseconds. Scrub Daddy's Cloudflare cache doesn't care about the parameters, and its ad visitors got the same 27 to 52 milliseconds as everyone else.

It's a setting you can fix. WP Rocket ignores a long list of these parameters by default and serves the cached page. In LiteSpeed Cache, add them to Drop Query String on the Cache tab; fbclid, gclid and utm* cover the common ones.

On Cloudflare, check what your cache rule does with query strings, because by default the full address, query string included, is the cache key, and the options to leave single parameters out depend on your plan.

Step 4: Match PHP workers to CPU cores

A PHP worker builds one page. Managed WordPress plans sell them as PHP workers or PHP threads, and a store builds as many pages at once as it has workers with a free CPU core under them. When every worker is busy, the next request waits in a queue, and that's where an uncached page turns from slow into unusable.

With twenty shoppers at once on an uncached product page, the wait falls with OPcache and with every added CPU core, and a page cache removes it

I sent 20 simultaneous shoppers at the uncached product page for 20 seconds per setup. On one core without OPcache the median shopper waited 10.4 seconds, because the core could finish only 1.9 pages a second.

OPcache on the same core cut the wait to 2.0 seconds, two cores to 1.0 second and four cores to 0.5 seconds, as throughput rose from 9 to 21 and then 39 pages a second. From the nginx cache it was 0.6 milliseconds.

I'd expected more pages from more workers on one core, and I got fewer:

PHP workers on one core	Pages a second	Median wait	Memory the workers held
2	10.3	1.8 s	93 MB
8	9.3	2.0 s
32	7.1	2.6 s	467 MB

A worker without a free core only waits for one, and the core then switches between more half-built pages, so each one finishes later.

Count before you buy: pages a second is roughly the number of CPU cores divided by the server time of one page. One core and a 100 millisecond page make about 9 to 10 pages a second, and a page that grows to 232 milliseconds with 15 plugins cuts that by more than half.

How many workers, then? About two per CPU core. Beyond that, workers add memory and a longer queue, so a plan that's selling many workers on a few cores is really selling you a longer queue. A store that serves most pages from a cache needs few, because only the cart, checkout, account pages and cart fragments reach PHP.

And it's rarely memory that runs out: hosting panels and the top command showed 85 MB per worker (the resident figure, RSS), but most of that is OPcache and libraries every worker shares. When I read the proportional figure (Pss) from /proc//smaps_rollup, which splits shared memory between the processes that share it, it was 31 MB per worker, and each worker beyond eight added about 12 MB.

Step 5: Stop the cart fragments request where nothing needs it

Cart fragments is the script that keeps the cart total in a store's header up to date. It sends a request to ?wc-ajax=get_refreshed_fragments, which no page cache answers, on the first page a shopper opens in each browser tab and again after every cart change. Since WooCommerce 7.8 the script loads only where the classic Cart widget is shown, but many themes still load it everywhere.

Storefront 4.6.2, WooCommerce's own theme, loads it on every page, and so does Scrub Daddy, whose product page sent the request on a first visit in a fresh Chrome profile and waited 767 milliseconds for the answer. Van Leeuwen's page loads the script only once the shopper has put something in the cart.

Each request is a full WordPress start. On the test store it took 40 milliseconds of server time, small on its own, but twenty at once on one core took 648 milliseconds each and the core topped out at 32 a second.

The request doesn't hold up the first paint, because the browser sends it after the page has loaded. It spends the PHP workers that the cart and checkout need, and it's doing that just as a campaign brings a crowd.

I nearly missed it myself. When I took the screenshots, I filtered the Scrub Daddy page by wc-ajax and found no cart fragments request at all. That was my mistake: I'd reloaded the page in the same tab a few times by then, and the script keeps the fragments in the tab's sessionStorage and skips the request while they're fresh, so after the first view there's nothing to see.

A fresh browser profile showed it at once, one POST, 767 milliseconds. Test this one in a new window, and look before you reload.

After a few reloads in one tab there's no cart fragments request, because the tab already holds the fragments, and the one wc-ajax request left is the Braintree call, refused with 403

There are three ways to stop it, from cleanest to quickest:

Use the Mini-Cart block: WooCommerce's block version of the header cart reads the cart without cart fragments, and block themes offer it in the Site Editor.
Switch it off in your optimization plugin: Perfmatters, for one, has a Disable Cart Fragmentation setting in its WooCommerce options.
Hold it back with a snippet. This one keeps cart fragments on the page but withholds its address until the browser finds the woocommerce_cart_hash cookie, which WooCommerce sets when something goes into the cart. Add it with the free WPCode plugin or your child theme's functions.php.

// Load WooCommerce cart fragments only for shoppers who have something in the cart.
// The check runs in the browser, so it also works on pages served from a page cache.
add_filter( 'script_loader_tag', function ( $tag, $handle ) {
    if ( 'wc-cart-fragments' !== $handle || is_cart() || is_checkout() ) {
        return $tag;
    }
    $loader = <<<'LOADER'
<script>
(function () {
    function load() {
        var held = document.querySelector('script[data-cart-src]');
        if (!held || !/(^|;\s*)woocommerce_cart_hash=/.test(document.cookie)) return;
        var s = document.createElement('script');
        s.src = held.getAttribute('data-cart-src');
        held.removeAttribute('data-cart-src');
        document.head.appendChild(s);
    }
    if (document.readyState === 'loading') {
        document.addEventListener('DOMContentLoaded', load);
    } else {
        load();
    }
    document.addEventListener('click', function () { setTimeout(load, 1000); });
})();
</script>
LOADER;
    return str_replace( ' src=', ' data-cart-src=', $tag ) . $loader;
}, 10, 2 );

The decision happens in the shopper's browser, so it'll hold on pages served from any cache, and Van Leeuwen's own version does the same in a few lines. On the test store, Storefront as shipped sent the request on a first visit with an empty cart; with the snippet that visit sent nothing, Add to cart sent it once, and the header showed 1 item.

Check it yourself: in a fresh Incognito window, type wc-ajax into the Network filter, open a product page and expect nothing, then add a product and expect one get_refreshed_fragments request.

Step 6: Add Redis object caching for the uncacheable pages

An object cache keeps the results of database queries in memory between requests, so the next page can skip them. WordPress has one built in that forgets everything when the request ends; Redis Object Cache, the most widely used plugin for a persistent one, stores the results in Redis, which your host has to run for you.

On the test store it did what it promises and cut the database queries for a product page from 90 to 26, and the page didn't get any faster: 103 milliseconds with Redis against 100 without, and the cart 128 against 132. A database on the same machine with every row in memory answers those 64 queries in a few milliseconds anyway.

So does Redis make WooCommerce faster? It pays off on a slow database. With the 15-plugin stack the product page ran 292 queries, Redis cut them to 62, and the page went from 232 to 213 milliseconds, about 8% faster.

The client made little difference: PhpRedis, the compiled extension, and Predis, the fallback written in PHP that the plugin uses when the server lacks the extension, finished within 2 milliseconds of each other on every page I measured. When the database runs on another server, every query becomes a network round trip, and that's the store Redis helps most.

So use it for the pages a page cache can't answer: the cart, the checkout, My Account, logged-in customers and the admin, which are also the pages where a slow server stands between a shopper and the order.

Install Redis Object Cache only if your host provides Redis, then open Settings > Redis to confirm the status reads Connected. A store that measured fast in step 1 won't gain much from it, and huge autoloaded options made it slower, as step 7 shows.

High-Performance Order Storage helps the same set of pages from another side. On by default for new stores since WooCommerce 8.2, it moves orders out of the WordPress posts tables into tables of their own, built for the lookups orders need, so checkout writes, the orders screen and reports get faster, while product and category pages, which don't read orders, stay exactly as they were.

Step 7: Keep autoloaded options and background jobs in check

Autoloaded options are the settings WordPress reads from the wp_options table on every request, in one query, whether the page uses them or not. Plugins add to them, and many leave their rows behind after they're deleted. WordPress 6.6 stopped autoloading options larger than 150 KB unless a plugin asks for it, and Site Health flags a site whose autoloaded options add up to more than 800 KB.

I measured what the bloat costs by adding junk options shaped like the logs and statistics caches plugins leave behind:

Autoloaded data	Added to an uncached product page
68 KB (the clean store)	nothing, the baseline
1.1 MB	9 ms
4.2 MB	12 ms
16.6 MB	26 ms, plus 26 MB of memory in every PHP worker
16.6 MB with Redis on	53 ms

Redis doubles the cost there because the object cache moves the whole block between Redis and PHP on every request. It's a slow leak, so clean it before it grows, and expect a few milliseconds back, not a new store.

To see your own total and the largest rows, run this in phpMyAdmin, which most hosts include in cPanel, and replace wp_ with your table prefix if it differs:

-- Total autoloaded size in KB
SELECT ROUND(SUM(LENGTH(option_value)) / 1024) AS autoload_kb
FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto');

-- The 20 largest autoloaded options
SELECT option_name, ROUND(LENGTH(option_value) / 1024) AS kb
FROM wp_options WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY LENGTH(option_value) DESC LIMIT 20;

An option named after a plugin you removed can usually go, after a database backup. One you don't recognize belongs to something still installed, and turning its autoload off is safer than deleting it.

WP-Cron and Action Scheduler

WordPress doesn't have a clock of its own. WP-Cron checks for due tasks on page loads, so on a store with a page cache it fires only when a request reaches PHP, and the background jobs WooCommerce queues in Action Scheduler wait for it: order emails, webhooks, stock syncs, subscription renewals.

When it does fire, it takes a PHP worker for as long as the jobs run. The fix is a real schedule, set once:

Disable the page-load trigger: add define( 'DISABLE_WP_CRON', true ); to wp-config.php, before the line that says to stop editing.
Run cron from the server every 5 minutes: in cPanel's Cron Jobs, add a job that calls wp-cron.php every 5 minutes at your own address, or ask your host to run it with WP-CLI.
Check the queue under WooCommerce > Status > Scheduled Actions, which lists pending, past-due and failed jobs. A long past-due list means cron isn't running often enough; thousands of failed jobs from one plugin point at the plugin.

# Every 5 minutes: run the due WP-Cron events and Action Scheduler jobs
*/5 * * * * wget -q -O /dev/null "https://shop.example.com/wp-cron.php?doing_wp_cron"

Which plugins slow down WooCommerce?

Plugins don't cost much one at a time, and they cost a lot together. I activated 16 popular plugins one by one on the test store, out of the box and not connected to their services, and measured the uncached product page with each. Wordfence Security added the most, 19 milliseconds, followed by Jetpack, YITH WooCommerce Wishlist and WooCommerce PayPal Payments at 11 to 12 each, and six stayed under 3 milliseconds.

Server time each popular plugin added to an uncached product page, one at a time, out of the box

Then I switched 15 of them on together, the kind of stack a store collects over a few years. The product page went from 104 to 232 milliseconds, more than double.

PHP loaded 4,199 files instead of 1,392 and ran 292 database queries instead of 90 for a single page, and every page the cache can't answer pays that, so the cart and the checkout feel a long plugin list long before a cached product page does.

I expected the stack to cost roughly the sum of its parts. Added up one at a time, the 15 plugins came to about 91 milliseconds; together they cost 128 in one run and 139 in another, and I didn't trace where the extra time went.

Plugins hook into the same WordPress events and into each other, so the only number that tells you what your stack costs is one measured with your stack. That's how I audit a store: every plugin on, then one at a time off.

The browser pays a separate bill. With the 15 plugins active, the product page carried 73 script tags instead of 31, 17 stylesheets instead of 8 and 97 KB of HTML instead of 74.

None of that shows up in server time, and all of it is what the Store Speed Test measures on the shopper's side, so a plugin that's cheap on the server can still be the slowest thing on the page.

What WP Rocket and LiteSpeed Cache fix, and what they can't

The HTTP Archive spots caching plugins and hosts on the sites it visits every month, and the Chrome UX Report tells you how those sites did for real visitors, so together they show how often each group gives phones a good server response and passes Loading.

Don't skip the caveat: these rows count every site where the technology was detected, any platform, not only stores, because the data can't be narrowed to sites that run WooCommerce and the plugin together.

Technology	Sites	Pass all three	Good server response	Good Loading
WooCommerce, all sites	557,369	39.5%	12.7%	43.7%
WordPress, all sites	2,752,367	48.7%	23.5%	55.8%
WP Rocket	272,660	51.3%	30.0%	61.8%
LiteSpeed Cache	391,972	50.7%	29.8%	59.0%
W3 Total Cache	81,968	44.5%	21.7%	51.3%
WP Fastest Cache	41,670	55.8%	42.2%	64.2%
NitroPack	11,320	56.5%	23.5%	69.3%
FlyingPress	4,585	56.6%	37.7%	70.2%
Perfmatters	17,195	53.7%	29.8%	65.5%
Autoptimize	78,265	46.2%	19.4%	53.6%
WP-Optimize	48,087	49.4%	27.2%	56.1%

Share of sites with each technology detected, mobile, from real Chrome visitors, August 2026. Server response is good at 800 milliseconds or less, Loading at 2.5 seconds or less.

WP Rocket and LiteSpeed Cache sites beat WordPress as a whole on every column, W3 Total Cache and Autoptimize sites trail it, and still only about 3 in 10 WP Rocket and LiteSpeed Cache sites give phones a good server response.

A cache plugin can only make cached pages fast: it can't shorten the distance to a server on another continent, answer the cart and checkout, catch ad clicks it wasn't told to ignore, or add CPU to a host that has none to spare.

NitroPack shows the other side of the trade, with one of the best Loading rates in the table, 69.3%, from heavy image and script work in the browser, and server response at 23.5%, level with WordPress overall.

The hosts' rows count every site on the host, any software, any country and any plan, so they describe the customers as much as the servers:

Host or server	Sites	Pass all three	Good server response	Good Loading
Pantheon	14,376	71.2%	48.6%	81.4%
WP Engine	83,985	65.0%	31.2%	75.1%
Kinsta	31,012	58.6%	21.3%	66.6%
SiteGround	112,334	52.4%	21.6%	59.6%
Hostinger	349,478	46.6%	30.4%	56.1%
Bluehost	36,414	43.1%	21.6%	50.7%
Varnish (any host)	152,229	60.8%	59.7%	80.6%
Cloudflare (any host)	3,979,838	50.7%	47.3%	64.8%
LiteSpeed web server	558,939	50.0%	31.2%	58.3%
Nginx	2,094,351	56.0%	42.2%	68.3%

Same source and date. Varnish and Cloudflare rows count every site that sends their headers, whoever the host is.

No host on the list gives even half of its sites a good server response; Pantheon comes closest at 48.6%. Sites that send Varnish headers, a cache that sits in front of the web server, beat every host at 59.7%, which matches the benchmark: the layer that answers before PHP decides the number.

Kinsta, SiteGround and Bluehost sit near 21%, worse than WordPress as a whole. The host sets the ceiling, and the cache setup and the plugins decide how close you'll get to it.

How the benchmark was run

Hardware: my workstation, an AMD Ryzen 9 3900X, with the PHP container limited to 1, 2 or 4 cores. One core with two PHP workers stands in for a budget shared plan; four cores with eight workers for a small dedicated server.
Software: WordPress 7.1, WooCommerce 11.1.2 with High-Performance Order Storage on, Storefront 4.6.2, PHP 8.3 in the official WordPress PHP-FPM image (plus the PhpRedis extension), MariaDB 11.4 with a 1 GB buffer pool, Redis 7 and nginx 1.27, all in Docker.
Catalog: 600 products in 12 categories, every third one a variable product with 6 variations, long descriptions, a featured image and three gallery images, built by a seeded generator so every run builds the same store.
Measurement: time to the first byte, taken by a client inside the same Docker network, so the network adds almost nothing. Sequential tests are the median of 40 requests after 5 warm-up requests; load tests keep 20 shoppers asking without pause for 20 seconds.
Page cache: Cache Enabler 1.8 for the plugin, nginx fastcgi_cache for the server, with the cart, checkout, account pages, wc-ajax requests and WooCommerce cookies excluded.
Plugins: each one activated alone on two cores with OPcache, measured, and deactivated; then 15 together, with Rank Math left out because it does the same job as Yoast SEO. Out of the box: not connected to their services and not configured.
The two stores: one product page each, measured from my connection in Poland on October 4, 2026, three requests per test, with the connection setup subtracted; their wc-ajax requests recorded in a fresh Chrome profile with nothing in the cart; the screenshots from my own Chrome.
Cart fragments snippet: tested in Chrome on the test store with and without it: a first visit, Add to cart, the same page again in the same tab, then a new tab.

A lab box is quieter than a shared host, where other customers' sites use the same CPU, and its database sits next to PHP with every row in memory, so you'll find real servers slower than these numbers. The ratios between setups are the part that travels: what OPcache, a page cache, an extra core or a plugin does to the same page.

And a faster theme won't fix the rest on its own. Storefront is one of the lightest WooCommerce themes, and the test store still needed 473 milliseconds per page without OPcache and 100 with it, before a single extra plugin was added. A theme decides how much work each page takes; the server and the cache decide how often that work happens.

Sources

WooCommerce developer blog: Best practices for the use of the cart fragments API, June 16, 2023.
WordPress core: Options API: disabling autoload for large options (WordPress 6.6), and Hooking WP-Cron into the system task scheduler.
WP Rocket: Caching query strings. LiteSpeed: LSCache for WordPress, Cache settings. Cloudflare: Cache Rules settings.
PHP: Supported versions. Google, web.dev: Time to First Byte.
Field data: HTTP Archive Technology Report, August 2026, and CartHacker's open dataset behind ecommerce speed by platform.

DEV Community: Adrian Wadowski