What's a Good TTFB for WooCommerce? (And How to Fix It)

A good TTFB for a WooCommerce store is under 200ms on cached pages and under 600ms on cart, checkout, and account pages. Google flags anything over 800ms as needing improvement. The gap between those two numbers — cached vs. uncached — is where most stores quietly lose money, because caching plugins can't touch the pages that actually take orders.

What Is TTFB, and Why Does It Matter More for WooCommerce?

TTFB (Time to First Byte) measures how long your server takes to send the first byte of a response after a browser asks for a page. It's pure server-side work: DNS, connection, PHP execution, database queries. For a static brochure site, it's a footnote. For WooCommerce, it's the ceiling on every other performance metric you have.

Here's the thing most store owners never get told: a WordPress blog post can be served from a cache file in 40ms without PHP ever running. A WooCommerce checkout page cannot. It has to boot WordPress, load WooCommerce, read the session, calculate the cart, apply tax rules, check shipping zones, and query available payment gateways — every single time, for every single visitor.

So when your caching plugin dashboard says "TTFB: 180ms," it's telling you about your homepage. Your checkout is running blind.

What's a Good TTFB for WooCommerce? Real Benchmarks

Google's own guidance puts a "good" TTFB at under 800ms, with anything over 1.8 seconds classified as poor. That's the floor, not the target. Here's what we actually measure across managed WooCommerce stores, broken out by page type:

Two things to notice. First, the acceptable range for checkout is roughly double the homepage — that's normal and unavoidable, not a failure. Second, the "losing money" column for checkout starts at 1.2 seconds of server think time before a single pixel renders. Add rendering, JavaScript, and payment iframe loading, and you're looking at a 3-4 second checkout on mobile.

According to Deloitte's Milliseconds Make Millions study, a 0.1-second improvement in mobile site speed increased retail conversion rates by 8.4% and average order value by 9.2% (2020). TTFB is the first slice of that budget — and the only slice you can't optimize away with better images or lazy loading.

Google's Core Web Vitals research also found that as page load time goes from 1 second to 3 seconds, the probability of a mobile visitor bouncing increases 32% (2017). Your server is spending the first third of that window doing nothing visible.

Why Your Caching Plugin Can't Fix Checkout TTFB

Page caching works by storing a finished HTML file and serving it to everyone. That's brilliant for a blog post and catastrophic for a cart — imagine serving Customer A's cart contents to Customer B. So WooCommerce explicitly instructs caching layers to exclude /cart/, /checkout/, /my-account/, and any request carrying a woocommerce_items_in_cart or wp_woocommerce_session_ cookie.

Which means the moment a visitor adds something to their cart, every page they see afterward may bypass your cache entirely. On many stores, the highest-intent traffic — people actively shopping — gets the slowest experience.

We see this pattern constantly during audits. A store owner runs GTmetrix on their homepage, gets a 95 score, and concludes speed isn't their problem. Meanwhile their checkout is taking 1.8 seconds server-side because the site is on a shared plan with two PHP workers and a wp_options table full of expired transients. If your store feels sluggish despite a stack of optimization plugins, the seven hidden bottlenecks behind a slow WordPress site will look uncomfortably familiar.

What does help uncached pages:

• Object caching (Redis or Memcached) — caches database query results, so even uncached pages skip repeated lookups. This is the single biggest win for cart/checkout TTFB.
• OPcache — caches compiled PHP bytecode. Usually server-level, not something a plugin can enable properly.
• Persistent database connections and query optimization — see our guide to WordPress database optimization and slow queries.
• Cart fragment control — the AJAX ?wc-ajax=get_refreshed_fragments call fires on nearly every page load and hits PHP every time.

None of those are things a $49/year caching plugin can do for you. They're hosting decisions.

What's Actually Causing Your High TTFB? The Three Real Culprits

In our experience auditing WooCommerce stores, high checkout TTFB almost always traces back to one of three things — and it's rarely the one people expect.

1. PHP Worker Starvation

A PHP worker is a single lane of traffic. One worker handles one uncached request at a time. Budget shared hosting typically allocates 2-4 workers per site; a mid-size WooCommerce store needs 6-12, and a busy one needs more.

Here's the math that matters. If a checkout request takes 600ms of PHP time and you have 2 workers, you can process roughly 3.3 uncached requests per second. Fine at 2am. During a Black Friday promo email drop, requests queue — and queue time gets added to TTFB. Your server isn't slow; it's full. That's why TTFB looks fine on your Tuesday morning test and terrible during your best sales hour.

This is also why a site can pass every synthetic speed test and still lose carts. Synthetic tests run one request at a time.

2. Database Queries Against a Bloated Schema

WooCommerce stores product attributes, order metadata, and session data in wp_postmeta and wp_options — tables that were designed for blog posts. A store with 2,000 variable products can easily carry 400,000+ postmeta rows.

The specific killers we find over and over:

• Autoloaded options bloat. Every page load fetches all autoloaded rows from wp_options. Abandoned plugins leave data behind. We've seen sites with 8MB of autoloaded options — that's 8MB read from disk before WordPress renders a single character.
• Expired transients that never get cleaned. Without object caching, transients live in the database and pile up indefinitely.
• Legacy order storage. If you haven't moved to High-Performance Order Storage, your order queries are still hammering the posts table. Our WooCommerce HPOS migration guide covers the switch — it's one of the highest-leverage TTFB fixes available for stores with order history.

3. Shared Neighbors Consuming Your CPU

On shared hosting, your "unlimited" plan sits on a box with 200-800 other accounts. When someone else's site gets crawled aggressively or runs a bulk import, your PHP execution slows down. You didn't change anything. Your TTFB doubled anyway.

This is the variance nobody explains: your TTFB isn't a number, it's a distribution. Test it ten times over a day and if your fastest and slowest results differ by more than 2x, you have a neighbor problem, not a code problem. The difference between shared and managed WordPress hosting is largely about whether your resources are guaranteed or borrowed.

How to Measure Your Real WooCommerce TTFB in 10 Minutes

Most people measure the wrong page. Do this instead:

1. Test the homepage with WebPageTest or your browser's Network tab. Note TTFB. This is your cached baseline.
2. Add a product to your cart, then reload the homepage. If TTFB jumped 3-5x, your cache is being bypassed for shopping sessions — expected, but now you know the real number.
3. Load the checkout page with items in cart. This is the number that matters most.
4. Repeat all three at your peak traffic hour, and again at 3am. The spread tells you whether you have a capacity problem.
5. Check wp-admin. If the admin is slow, it's almost always the database, not the frontend stack.

Command line version, if you're comfortable:

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" \
  https://yourstore.com/checkout/

Run it ten times. Record the range, not the average. Consistency is a hosting quality signal.

What Fixing TTFB Is Actually Worth

Let's put real numbers on this, because "faster is better" isn't a business case.

Take a store doing $40,000/month in revenue with a 2.1% conversion rate and 60,000 monthly sessions. Checkout TTFB is 1,400ms — a common number for a mid-tier shared plan carrying a real catalog.

The conversion lifts here are modeled on Deloitte's measured 8.4% retail conversion improvement per 0.1s of mobile speed gain — deliberately discounted, because TTFB is only one component of perceived load time and real-world results vary by store, traffic mix, and audience.

Even at the conservative end, that's roughly $3,200-5,300/month in recovered revenue against a hosting cost difference of maybe $60-70/month. The math isn't close. And that's before you count the orders you're losing to timeouts during your highest-traffic hours, which don't show up in your conversion rate at all — they show up as sessions that vanish.

If you want the full breakdown of how server response time flows through to revenue, we covered it in how WordPress site speed directly impacts revenue.

What Actually Fixes WooCommerce TTFB (In Order of Impact)

Ranked by what we see move the needle most on real stores:

1. Server-level object caching (Redis). Biggest single win for uncached pages. Cuts repeated database lookups on cart and checkout. Should be provided by your host, not a plugin you configure.
2. Adequate PHP workers. Eliminates queue-time TTFB spikes during traffic peaks. Non-negotiable for stores running paid ads or email campaigns.
3. HPOS migration. Moves orders to purpose-built tables. Dramatic improvement for stores with 5,000+ orders, especially in wp-admin.
4. Autoloaded options cleanup. Free, takes an hour, and often shaves 100-200ms off every uncached request.
5. Modern PHP + OPcache. PHP 8.3 executes meaningfully faster than 7.4. Our best PHP version for WordPress guide has the compatibility details.
6. Plugin audit. Every plugin adds boot time to uncached pages. Ten plugins that each add 20ms is 200ms on every checkout view.
7. CDN. Helps a lot for global visitors and static assets — but note it does not fix uncached checkout TTFB unless you're running full page-rule edge logic. See the WordPress CDN setup guide.

Steps 4 and 6 you can do yourself this week. Steps 1, 2, and 5 are hosting-layer decisions — you either have them or you don't, and no plugin will substitute.

Where TopSyde Fits

We built our stack around the assumption that the uncached request is the one that matters. Every plan includes Redis object caching, dedicated PHP workers sized to your traffic, PHP 8.3 with OPcache tuned for WooCommerce, and 24/7 monitoring that alerts on TTFB regression — not just uptime, because a store that responds in 4 seconds is technically "up" and practically closed. You can see the full configuration on our hosting spec sheet.

Plans start at $89/mo per site, and support responds in under 2 hours during business hours — including the migration, which we handle for you. If it doesn't fix your numbers, there's a 30-day money-back guarantee, so the test costs you nothing but a DNS change.

The honest version: if your checkout TTFB is already under 500ms and stable across the day, you don't have a hosting problem and you should spend your money elsewhere — probably on checkout UX optimization, which is usually the next-biggest lever. But if your numbers swing wildly, or your checkout is north of a second, no amount of frontend work will save you. You're optimizing a page that hasn't started loading yet.

Next step: run the 10-minute measurement above, then compare it against our pricing and included stack. If the numbers justify a move, we'll migrate you.

Frequently Asked Questions

What is a good TTFB for a WooCommerce store?

Under 200ms for cached pages like the homepage and product listings, and under 600ms for cart, checkout, and my-account pages. Google classifies TTFB above 800ms as needing improvement. Checkout will always be slower than cached pages because it cannot be cached — that's expected, not a defect.

Why is my WooCommerce checkout slow when my homepage is fast?

Because WooCommerce excludes cart, checkout, and account pages from page caching to prevent showing one customer's data to another. Those pages run full PHP and database work on every load, so they expose the true performance of your server — PHP workers, database health, and CPU availability — while your homepage hides it behind a cache file.

Can a caching plugin fix high TTFB on checkout?

No. Page caching plugins can't cache checkout by design. Object caching (Redis or Memcached) does help uncached pages by storing database query results, but it needs to run at the server level. If your host doesn't offer Redis, a plugin alone won't deliver most of the benefit.

Does a CDN improve WooCommerce TTFB?

For cached pages and static assets, yes — significantly, especially for geographically distant visitors. For cart and checkout, mostly no, because those requests must reach your origin server. A CDN reduces network latency but not PHP execution or database time, which is where slow checkout TTFB actually comes from.

How much revenue does slow TTFB actually cost?

Deloitte's retail research found a 0.1-second mobile speed improvement raised conversion rates by 8.4% (2020). For a $40,000/month store, cutting checkout TTFB from 1.4 seconds to under 500ms models to roughly $3,000-5,000/month in recovered revenue — though actual results depend on your traffic mix, audience, and how much of your delay is server-side versus frontend.

Marcus Webb

DevOps & Security Lead

12+ years DevOps, Linux & cloud infrastructure certified

Marcus leads infrastructure and security at TopSyde, managing the server fleet and AI monitoring systems that keep client sites fast and protected. Former sysadmin turned WordPress hosting specialist.

XLinkedIn