WordPress TTFB Benchmark: Methodology and Raw Numbers (2026)

Most “WordPress TTFB benchmark” articles you find on the open web have the same problem: a single uncached homepage curled once from one US data center, ranked into a leaderboard that bears no resemblance to what your buyers experience. We are building a multi-host, multi-region, multi-route lab on identical seed sites to replace that genre of content with numbers you can actually use. This article is the methodology, the target ranges we expect from disclosed vendor specs, and the way we will publish raw data so anyone can reproduce or argue with it.

If you want to run a TTFB test on your own store today, the WooCommerce TTFB test recipe walks through the four routes that actually matter for a real store. This page sits one layer up: how we run a defensible cross-host benchmark, what we will publish, and what the raw numbers will look like once the seed-site rig is online.

TL;DR

• A WordPress TTFB benchmark is only useful if it tests identical seed sites on each host, from at least five regions, on multiple routes (homepage, product page, cart, checkout, AJAX), with the cold-start runs thrown away.
• Single-region homepage curls are not a benchmark. They are a CDN test that says nothing about how a logged-in checkout responds.
• Expected good ranges on healthy managed WordPress in 2026: homepage 60 to 150 ms (cached), product 120 to 250 ms, uncached PHP routes (cart, checkout) 200 to 450 ms from a same-region test point.
• The hosts that win consistently across regions are the ones with Cloudflare Enterprise tiered cache plus a persistent object cache. See our Cloudflare Enterprise on WordPress hosting breakdown for which vendors actually bundle the full feature set.
• We publish raw numbers, dates, plan tiers, and the seed-site commit hash. If you cannot reproduce a result, the result is not real.

Jump to: what TTFB is and is not, the seed site, the test rig, routes and payloads, expected ranges, how we report, FAQ.

What TTFB is, and what it is not

TTFB (“time to first byte”) is the wall-clock time from the moment a client opens a TCP connection and sends a request until the first byte of the HTTP response arrives back. It includes DNS lookup if you are measuring end to end, the TLS handshake on a cold connection, the network round trip to the origin or edge node, and (for any uncacheable path) the server’s full request-handling time.

What it does not measure: rendering time in the browser, JavaScript execution, image loading, Largest Contentful Paint, or anything Lighthouse calls a “Core Web Vital”. TTFB is upstream of all of those. A page with a 90 ms TTFB can still score badly on Core Web Vitals if the HTML or JS payload is bloated. A page with a 1,200 ms TTFB will fail Core Web Vitals no matter how lean the front end is. Google has called out a “good” TTFB target of under 800 ms in its web.dev TTFB guidance, with under 200 ms recommended for the document request when possible.

For a hosting benchmark, TTFB is the cleanest single number we can attribute to the host. Everything else (paint timing, layout shift, JS execution) is mostly a theme and plugin problem. TTFB is mostly a host problem, with object-cache configuration as the dominant secondary factor.

The seed site (one site, eight hosts)

The single biggest mistake in published WordPress TTFB benchmarks is testing different sites on each host. A “Kinsta vs WP Engine” article that loads kinsta.com against wpengine.com is a marketing-page benchmark, not a hosting benchmark. We are doing the opposite: one site, deployed identically across every host we cover.

The seed-site spec, kept in a public GitHub repo and referenced from the methodology page:

• WordPress 6.x on PHP 8.3, vendor-default config.
• WooCommerce with the Storefront theme.
• 200 simple products, generated from a fixed CSV, prices and SKUs deterministic.
• Plugin stack: WooCommerce, Yoast SEO, Contact Form 7, Query Monitor (active during tests for attribution, deactivated for headline numbers), and a payment gateway in test mode (Stripe).
• Identical content: same posts, same media library, same uploads bucket synced from the repo.
• Vendor-default caching: we accept each host’s recommended caching stack (Kinsta’s Cloudflare Enterprise + Redis, WP Engine’s EverCache + global edge, Rocket.net’s Cloudflare Enterprise, Cloudways with Breeze + Varnish + Redis on the Vultr HF plan, etc). The point is to compare hosts as a buyer would use them, not to flatten the differences they sell.
• No paid theme builders, no page-builder bloat. A real-world WooCommerce store has Elementor or similar; we will publish a “with Elementor” follow-up benchmark separately so it does not contaminate the host comparison.

The repo, deploy scripts, plugin list with versions, and product CSV all live in the public seed-site GitHub repo linked from the methodology page. If a host is missing from a published table, it is because we did not (yet) have a working deployment on that host, not because it failed silently.

The test rig

The measurement loop runs from infrastructure we control. We do not rely on a single SaaS dashboard, because every SaaS speed test makes different assumptions about cache warming, keep-alive, and TLS reuse. Three independent measurement paths, cross-checked, are how we tell a real TTFB delta from an artifact of one tool.

1. curl from five small VPS nodes (Hetzner CX22 in Falkenstein, DigitalOcean droplets in NYC and SFO, Vultr in Singapore, AWS Lightsail in Sydney), driving a scripted nine-run median per route with a fresh connection each run. This is the canonical number we publish.
2. k6 cloud with three to five load zones, single VU at first (to compare against the VPS curl numbers as a sanity check), then 10 to 50 VUs for a separate concurrency-aware view.
3. WebPageTest scripted runs from a subset of the same regions for visual confirmation and a third opinion. We do not use WebPageTest for the headline TTFB number because its agent-side timing varies between locations.

Every test point logs: route, region, run index, DNS time, TCP connect time, TLS handshake time, TTFB, total time, response size, HTTP status, and the response header that identifies cache hit or miss (x-cache, cf-cache-status, x-kinsta-cache, etc). Raw logs go into a CSV per benchmark sweep, committed to the public repo with a date and the seed-site commit hash.

Cold-start handling matters more than people admit. The first request after a deploy or after a long idle window will hit the origin and warm caches, and that number is misleading on every host. Our rule: discard the first three runs in every nine-run loop, take the median of the remaining six. We additionally run a “burst” measurement (50 sequential requests in five seconds) to catch hosts that throttle or warm-up slowly.

The routes and payloads we measure

A WordPress TTFB benchmark needs to test more than one URL, because hosts cheat in predictable ways on the homepage and lose on the routes that matter for revenue.

Two payload configurations per route where it matters: logged out, no cart, and logged in with one product in the cart. Logged out is what crawlers see and what cold-shopper landing-page hits look like. Logged in with a cart is what every dollar of revenue actually traverses.

For the AJAX route we POST a realistic billing-address payload (country, state, postcode, payment_method) and measure the same way. This call fires on every checkout-field blur in a real session, so it is the silent killer of perceived checkout speed.

What good and bad TTFB numbers look like in 2026

The table below is the range we expect from disclosed vendor specs, public Cloudflare Enterprise documentation, and the operational TTFB numbers we have seen on real WooCommerce migrations across five managed hosts. We will replace these with our own measured medians per host as the seed-site rig finishes deploying. Today’s numbers are directional, not a leaderboard.

The two diagnostic ratios we watch in every host benchmark:

1. Homepage vs. checkout: a healthy stack lands at 2x to 3x. A 5x or higher gap means the uncached PHP path is bottlenecked, usually by missing or cold object cache.
2. Same-region vs. far-region: a CDN-heavy stack should see homepage TTFB stay within 50 ms across regions, while uncached routes scale with origin distance. A host whose checkout TTFB jumps from 250 ms in-region to 1.5 seconds at 200 ms RTT has an origin-only stack with no multi-region acceleration. That matters if your buyers are not in one place.

How hosting stack choices move TTFB

For people skimming for an actionable answer: the three stack decisions that move WordPress TTFB more than anything else.

• Cloudflare Enterprise (or equivalent) with tiered cache and Argo Smart Routing. This is the single largest lever on cached-route TTFB across regions. Rocket.net and Kinsta ship it in the box (see the Cloudflare Enterprise on WordPress hosting breakdown). Standard free-plan Cloudflare in front of a single-region origin is not the same product.
• Persistent object cache (Redis or Memcached) with a hit ratio above 95%. This is what keeps uncached PHP routes from doing the full database round trip on every cart-update. Most managed hosts include Redis on mid-tier plans; some gate it to higher tiers. If your TTFB gap between homepage and checkout is over 5x, this is the first thing to check.
• PHP worker count tuned to concurrency. Two PHP workers will serialize checkout requests under any real Black Friday burst. The math, and how it interacts with checkout TTFB under load, is in the Cloudways vs Kinsta comparison.

Plan recommendations from disclosed specs (we will refresh these against measured numbers as soon as the rig ships):

• Multi-region origin + Cloudflare Enterprise included: Rocket.net (every plan) and Kinsta (Pro and above on Premium DNS). Check Rocket.net plans · Check Kinsta plans
• DIY tunability at lower price: Cloudways on Vultr High Frequency with Breeze, Varnish, and Redis. Fewer guardrails, more knobs, lower floor. Check Cloudways plans
• Enterprise compliance plus speed: WP Engine on a Premium plan with the global edge add-on, when the budget allows.

For the broader buyer’s framing (host shortlist with prices and per-host verdicts) see the best managed WordPress hosting for WooCommerce ranking.

How we will publish results

The benchmark is only useful if it is reproducible. Every published WordPress TTFB benchmark on this site will include:

• A dated headline table with median TTFB per host, per region, per route.
• The seed-site commit hash that was deployed.
• The plan tier tested on each host, with the monthly price as listed on that vendor’s pricing page on the test date.
• A link to the raw CSV in the public repo, with timestamps, run indices, and the cache-status header per request.
• A change log with what changed since the previous sweep (new plan tested, host removed, methodology tweak).

If a host requests inclusion or a re-test, the answer is yes, provided they let us deploy our seed site on a normal paid plan (we do not accept review hardware or special configurations). Sponsored placement does not exist. The affiliate-program link in our recommendation table is the same link the host gives every other publisher.

When we publish a result, we will tell you the date, the plan, the regions, and the median run. We will not tell you the host is “fast” without a number, and we will not say it is “slow” without a number either. If your interpretation of our table differs from ours, we are happy to argue about the data in a corrections box on the article.

FAQ