WooCommerce TTFB Test: Measure Checkout Latency Right (2026)

If you ran a WooCommerce TTFB test today on your store’s homepage, you probably got a number between 80ms and 300ms, felt vaguely fine, and went back to work. That number is almost useless. The homepage is cached. The pages that decide whether your store feels fast (cart, checkout, my-account, and the AJAX endpoints WooCommerce hits during a purchase) are uncacheable by definition, and they are usually two to ten times slower than the page you tested. A proper WooCommerce TTFB test measures the routes a buyer actually traverses, from regions buyers actually live in, with a realistic plugin and cart payload. This guide walks through how to do that, what numbers to expect, and what to do when your TTFB is bad.

For the broader hosting picture this feeds into, see our best managed WordPress hosting for WooCommerce shortlist and the head-to-head Kinsta vs WP Engine for WooCommerce test. We will publish a multi-host TTFB benchmark on identical seed sites separately; this article is the methodology and a sane DIY recipe you can run on your own store today.

TL;DR

• Measure TTFB on /checkout/, /cart/, /my-account/, and ?wc-ajax=update_order_review, not the homepage.
• Test from at least three regions your buyers actually live in. A 50ms US-East TTFB means nothing if 60% of your customers are in Sydney.
• Use a real cart payload (1 to 3 products, logged-in session cookie) for cart and checkout. Empty-cart numbers are misleading.
• Good (managed WordPress, modern stack): 150ms to 350ms for /checkout/ from a same-region test point.
• Bad: 800ms+ consistently. Above 1.5 seconds you are losing measurable conversion.
• Hosting is the bottleneck about half the time. The other half is plugins, a bad object cache, or a slow payment gateway sitting in front of your checkout.

Jump to: why homepage TTFB lies, what to measure, the recipe, target numbers, interpreting results, FAQ.

Why a homepage TTFB test misleads you

WooCommerce explicitly sets DONOTCACHEPAGE and bypasses full-page cache on cart, checkout, and my-account, and any page where the woocommerce_items_in_cart cookie is present. The WooCommerce documentation has spelled this out for years: caching plugins and edge caches must exclude those routes, otherwise you serve a logged-out user’s cart to a logged-in customer (WooCommerce: caching).

The implication is uncomfortable. When you load https://yourstore.com/, your host returns a static HTML file from Nginx, Varnish, or Cloudflare in 60ms to 150ms. When a buyer loads /checkout/, the host runs PHP, hits the database, evaluates WooCommerce session and cart logic, fires wc-ajax requests on every field blur, and returns a response that took the full PHP-to-DB round trip. Same server. Different universe.

A homepage TTFB number tells you how fast your CDN is. A checkout TTFB number tells you how fast your store is.

What to measure (the four routes that matter)

Run TTFB measurements against these endpoints. Treat any of them coming back over 800ms as a real problem.

1. /checkout/ with one product in the cart and a logged-in session cookie. This is the route that gates revenue.
2. /cart/ with two or three products. Cart fragment behavior on this page is the most common source of admin-AJAX storms.
3. /my-account/ logged in. Slow account pages correlate with slow checkout because they hit the same uncached PHP path.
4. /?wc-ajax=update_order_review as a POST with a realistic billing address payload. This fires every time a customer changes a checkout field. If it is slow, the form feels broken even if the page rendered fast.

A homepage and a product page are useful as a control. They isolate “is the host fast at serving cached HTML” from “is the host fast at the actual store paths.” If your homepage TTFB is 90ms and your /checkout/ TTFB is 1.4 seconds, you have a PHP or database bottleneck, not a CDN problem.

The recipe: a WooCommerce TTFB test you can run in 30 minutes

You can do this with curl, a free WebPageTest account, and (optionally) k6 for load. Nothing exotic.

Step 1. Capture a real session cookie

Log in to your store as a test customer, open browser devtools, copy the wordpress_logged_in_* and woocommerce_session_* cookies. Save them to cookies.txt in Netscape format. Without these, you are testing the logged-out path, and the logged-out path is sometimes cacheable. You want the worst case.

Step 2. Add a product to the cart

Either via the UI in the same browser session, or curl -b cookies.txt -c cookies.txt "https://yourstore.com/?add-to-cart=<product_id>". Confirm /cart/ shows the product.

Step 3. Time the four routes from one region

Use curl with timing format:

curl -o /dev/null -s -w "DNS:%{time_namelookup} TTFB:%{time_starttransfer} Total:%{time_total}\n" \
  -b cookies.txt -c cookies.txt \
  "https://yourstore.com/checkout/"

Repeat 10 times. Throw out the first run (cold cache). Take the median of the remaining 9. Do the same for /cart/, /my-account/, and the wc-ajax POST.

For the AJAX call:

curl -o /dev/null -s -w "TTFB:%{time_starttransfer}\n" \
  -b cookies.txt -c cookies.txt \
  -X POST \
  -d "country=US&state=CA&postcode=94110&payment_method=stripe" \
  "https://yourstore.com/?wc-ajax=update_order_review"

Step 4. Repeat from at least two more regions

This is where DIY gets thin. A curl loop on your laptop only measures from one place. Use one of:

• WebPageTest (webpagetest.org) with the scripted login + add-to-cart pre-step. Free tier covers a handful of runs from a generous list of agent locations.
• k6 cloud (k6.io/cloud) with three or more load zones, even at 1 VU, just for the latency view.
• curl on a small VPS in each target region. A $5/month DigitalOcean droplet in NYC, AMS and SYD lets you script the same nine-run median from three continents.

Three regions is the floor. Five is better. The hosts that win in one region routinely lose in another.

Step 5. Write down the numbers and date them

Put them in a spreadsheet. Include: route, region, median TTFB, P95, date, host plan, plugin count, whether object cache was confirmed hitting (use Query Monitor or your host’s stats page). Without this context the numbers age into noise within a quarter.

What good and bad numbers look like

These ranges come from disclosed vendor performance commitments and from the operational benchmarks we have run on five managed hosts during real WooCommerce migrations. We will replace the ranges below with our own multi-region medians from the seed-site rig as it comes online (see methodology).

The gap between homepage and /checkout/ is the most diagnostic single number. On a healthy managed-WordPress setup with persistent object cache, that gap is roughly 2x to 3x. On a misconfigured store (no object cache, slow plugin doing a wp_options autoload on every request, payment gateway calling an external API synchronously) the gap is 5x to 20x.

Interpreting your results

A few patterns recur often enough to be worth naming.

Homepage fast, checkout slow. PHP or database bottleneck. Confirm persistent object cache is active (Redis or Memcached) and that it is hitting (redis-cli info stats or your host’s panel). If the object cache is fine, look at plugins: deactivate suspects one by one and re-run the test. The usual offenders are page builders, “related products” plugins running unbounded SQL, and analytics plugins that write to the database on every page view.

Slow from one region, fast from another. Origin location problem. If your origin is in Frankfurt and your buyers are in Sydney, no amount of CDN tuning helps the uncacheable checkout path. Either pick a host with a multi-region origin option, or pick a region closer to where your revenue lives.

Cart and checkout slow, AJAX fast. Plugin overhead on page render. Cart and checkout templates often hook every “cart updated” filter; one bad filter callback can add 300ms per render.

Cart and checkout fast, AJAX slow. Payment gateway or shipping calculator latency. The update_order_review call recalculates shipping and tax on every field change. A slow shipping API (real-time UPS or DHL rate lookups, anyone) shows up here.

Everything slow, evenly. Host or plan is undersized. PHP worker exhaustion looks like this under any concurrency. Cheapest-tier managed plans with 2 PHP workers will queue requests when you have more than a handful of concurrent buyers. We dug into the math in the Cloudways vs Kinsta comparison.

When the answer is “change hosts”

If your TTFB is poor across all four routes from all regions, you have already swept plugins and confirmed object cache is alive, and your store is in the $50k to $500k revenue band, the answer is usually a hosting upgrade. Where to go depends on your traffic shape and your appetite for operations. The best managed WordPress hosting for WooCommerce shortlist ranks the eight hosts we benchmark against this exact set of routes and the same regional spread.

FAQ