Most website owners obsess over Lighthouse scores, image compression and plugin counts. But there is one number that reveals more about your infrastructure than any other: Time to First Byte (TTFB).
TTFB is the time between a user’s browser requesting your page and receiving the first byte of the response. It is the purest measure of how fast your server actually is — before a single image, script or style sheet is downloaded.
A slow TTFB means your server itself is slow. No amount of image optimization or caching plugins can hide that. This is why Google’s Core Web Vitals treat TTFB as the foundation of the Largest Contentful Paint (LCP): a slow server delays everything that follows.
In this guide, you will learn what a good TTFB looks like, how to measure it, and the exact eight-step sequence to drop your WordPress TTFB below 200ms — the target we guarantee on the Fortezza Digitale infrastructure.
What Is a Good TTFB for WordPress?
Before optimizing, you need a benchmark. Here is the scale most performance engineers use:
- Under 100ms: Excellent. Only dedicated VPS or dedicated servers with tuned software reach this.
- 100–200ms: Very good. A well-configured VPS with proper caching. This is the target for serious sites.
- 200–500ms: Acceptable but lazy. Typical of shared hosting or an untuned VPS. Users notice it.
- 500ms–1s: Poor. Your server is the bottleneck. Visitors start to bounce.
- Over 1s: Critical. Something is fundamentally wrong with your hosting or configuration.
Google recommends a TTFB of under 800ms, but that is a floor, not a target. For a site that ranks and converts, aim for 200ms or less. Every 100ms of server latency directly delays your LCP and pushes your Core Web Vitals further from green.
The painful truth: if your TTFB is over 300ms, your hosting is the problem, not your site. You can polish the front end all day, but a slow server response caps everything.
How to Measure TTFB Correctly
Most people measure TTFB wrong. A browser’s network panel includes DNS lookup, connection setup and TLS handshake, which can mislead you.
Measure at the Server Level
The cleanest measurement is at the server itself, bypassing the network:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://yourdomain.comThis isolates the server’s raw response time. Run it 5 times and take the median, not the average (a single cold request inflates the number).
Measure from Multiple Locations
A single measurement from your own office tells you little. Use:
- WebPageTest with a location far from your server to test global latency.
- GTmetrix waterfall view to see TTFB split by DNS, connection and wait time.
- Google PageSpeed Insights — look at the “server response time” field in the diagnostics.
Separate the Two TTFB Components
A measured TTFB is actually two things: network RTT (how far your user is from your server) and server processing time (how long the server takes to build the response).
The curl command above shows you the total. To isolate server processing, compare it to a simple latency test (ping or curl to a static file). If a static file is fast (20ms) but your homepage is 400ms, the problem is server-side processing, not the network.
This distinction matters: a CDN fixes network latency, but only server tuning fixes slow processing. Most WordPress TTFB problems are server-side — and profitable to fix because you control them.
The 8-Step Sequence to Cut WordPress TTFB
Work through these in order. Each step addresses a different layer of the stack, and each compounds on the previous one.
Step 1: Fix the Hosting Itself
TTFB starts with the foundation. If you are on shared hosting, this is your ceiling, period.
Shared hosting throttles CPU, limits inode usage and oversells server resources. Your “fast” neighbor’s traffic spike slows your site. No optimization — caching, CDN or otherwise — fully compensates for a host that throttles you.
Move to a VPS with guaranteed CPU and RAM. This alone frequently drops TTFB from 600ms to 150ms because you stop competing for resources. Choose a provider with fast NVMe storage and data centers near your audience.
You do not need the most expensive plan. You need guaranteed resources. A modest but isolated VPS beats a nominally faster shared plan every time.
Step 2: Tune PHP-FPM
PHP-FPM is the process manager that runs your PHP code. Its default configuration is designed for low memory, not speed — and it throttles high-traffic WordPress sites.
Open your php-fpm.conf (or pool config) and adjust:
pm.max_children = 30
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10The exact numbers depend on your server’s RAM. A rough rule: each PHP worker uses about 40–80MB. A 4GB VPS comfortably runs 30–40 workers.
Under-provisioning PHP-FPM means requests queue up waiting for a free worker. This directly inflates TTFB. Tune it so you never wait on a worker under normal traffic.
Step 3: Use the Right PHP Version
This is the cheapest TTFB win available. Each PHP major version is faster than the last.
- PHP 7.4 reached end of life and is dramatically slower than modern versions.
- PHP 8.1 is roughly 2x faster than PHP 7.4 for typical WordPress workloads.
- PHP 8.2 and 8.3 continue the gains with JIT support and opcache improvements.
If you are still on PHP 7.x, upgrading to 8.3+ is a single dropdown in most control panels and can cut TTFB by 30–50% with zero code changes. Verify your plugins and theme support the version first, but almost all modern plugins do.
Enable the OpCache extension if it is not already active. OpCache caches compiled PHP bytecode in memory, eliminating the parse and compile step on every request — a significant server-side reduction.
Step 4: Optimize the Database
WordPress’s database is a frequent hidden TTFB killer. Every page load runs dozens of queries, and an unoptimized database makes each one slower and repeats work.
Start with query result caching (object caching). As covered in our Redis guide, installing Redis as the object cache backend dramatically reduces the number of repeated database queries per request. This is one of the highest-impact server-side changes available.
Then clean the database:
- Remove transients, revisions and spam from the tables.
- Add proper indexes to the
wp_optionsandwp_postmetatables — these are the most-query-heavy tables in WordPress. - Consider MariaDB or MySQL 8 over older MySQL versions for better query optimizer and InnoDB performance.
A tuned database should answer a page’s worth of queries in under 30ms. If it takes 200ms, the database is your bottleneck.
Step 5: Add Page Caching at the Server Level
Page caching serves a static HTML copy of each page instead of executing PHP on every request. This is the single biggest TTFB reduction available.
There are two tiers:
- Plugin page caching (e.g., WP Super Cache, cache plugins) works but still boots WordPress and PHP to serve the cached file — its TTFB is only marginally better than a dynamic page.
- Server-level cache (Nginx FastCGI cache, Varnish, Redis page cache) serves the cached HTML from memory before PHP runs. For anonymous visitors this can push TTFB below 50ms.
The difference is huge. Server-level caching intercepts the request at the web server, never touching PHP. This is why our Fortezza setup uses a native caching layer rather than relying on plugins alone.
Step 6: Enable Compression and HTTP/2
Two protocol-level tweaks reduce the bytes transferred and the connection overhead:
- Gzip or Brotli compression shrinks HTML, CSS and JS by 60–80% before they hit the wire. Brotli generally compress better than gzip at the same settings.
- HTTP/2 multiplexes multiple requests over a single connection, eliminating the head-of-line blocking of HTTP/1.1 and reducing round trips for page assets.
Both are configured under the hood at the web server or CDN level. They do not directly reduce server processing time, but they shave real milliseconds from the total response — and they are free.
Step 7: Add a CDN with Edge Caching
A Content Delivery Network (CDN) replicates your static assets — and, with edge caching, your whole page — to data centers closer to your visitors.
This addresses the network RTT component of TTFB. A user in Milan hitting a server in Frankfurt or Amsterdam has 30–60ms of round-trip latency. With a CDN edge node in Milan, that drops to under 10ms.
For full-page edge caching, the CDN caches the HTML output at the edge and serves it to anonymous visitors without ever contacting your origin server. Combined with server-level caching, this gives you sub-50ms TTFB for the vast majority of requests.
Because we serve European clients with GDPR requirements, we use a CDN with EU-only edge locations and ensure no data leaves the EU.
Step 8: Monitor and Maintain
Optimization is not a one-time task. TTFB degrades silently as your site grows, plugins accumulate and traffic patterns shift.
Set up a monitoring loop:
- Weekly: Run the curl measurement above and log the median.
- Monthly: Check Core Web Vitals in Search Console and PageSpeed Insights.
- On change: Re-test TTFB whenever you add a heavy plugin, change the theme, or alter the server config.
Watch for slow creep. A TTFB that climbs from 150ms to 300ms over three months signals a plugin regression or an under-provisioned server that needs scaling.
A Real-World Diagnosis: From 900ms to 160ms
To make this concrete, here is the exact sequence of findings from a typical slow WordPress site — the same pattern we see on nearly every site that arrives on Fortezza with “my site is slow.”
Starting point: TTFB of 900ms measured via curl, page load of 4.2 seconds, LCP of 5.4s. The owner had already tried four image-optimization plugins and three cache plugins with no real improvement.
Diagnosis (5 minutes):
curl -w "TTFB: %{time_starttransfer}s"→ 900ms. Already the whole problem.- Serving a static file → 40ms. So the network was fine; the server processing was 860ms.
- PHP version checked → still running PHP 7.4, end of life.
pm.max_children→ set to a conservative 10 workers, all saturated during traffic peaks.- Redis object cache → not installed. Every request repeated the same ~40 database queries.
- No server-level page cache. Every anonymous page load executed full PHP + MySQL.
Fixes applied in order:
- Upgraded PHP 7.4 → PHP 8.3: TTFB dropped from 900ms to ~500ms. The compiler and OpCache improvements alone did most of this.
- Tuned PHP-FPM
pm.max_childrenfrom 10 to 32 and adjusted spare servers: TTFB dropped to ~350ms. No more queueing on free workers. - Installed Redis as the object cache backend: TTFB dropped to ~260ms. Repeated database queries stopped.
- Enabled Nginx FastCGI cache for anonymous visitors: TTFB dropped to ~120ms, because PHP no longer ran at all for cached pages.
- Added an EU-edge CDN for the residual geographic latency: TTFB measured from a remote European city dropped to ~90ms.
Final result: TTFB of 90–120ms (depending on location), LCP under 2.5s, Core Web Vitals fully green. Total time invested: under an hour, all server-side.
The lesson is the same every time: the site was never broken — the stack was. Once the server was given real resources, a modern PHP, a query cache and a native page-cache layer, the “slow site” disappeared without touching a single front-end line.
A Reference Nginx FastCGI Cache Config
If you run Nginx as your web server and want server-level page caching, a FastCGI cache is one of the highest-impact things you can enable. Here is a minimal working reference:
# In the http context
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
# In the server / location block that proxies PHP
set $skip_cache 0;
if ($request_uri ~* "/wp-admin/|/wp-json/|/xmlrpc.php|wp-.*.php") { set $skip_cache 1; }
if ($request_method = POST) { set $skip_cache 1; }
if ($query_string != "") { set $skip_cache 1; }
location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 60m;
add_header X-Cache $upstream_cache_status;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
}The X-Cache header lets you confirm the cache is working: HIT appears on cached responses, MISS on the first request. The $skip_cache rules keep the admin area, the REST API and logged-in flows dynamic, so you never serve stale content to authenticated users.
Note that WordPress sets Cache-Control headers and you may need a small adjustment for full compatibility. For team behavior and logged-in sessions, edge cases matter — this is why a well-tested, pre-built caching layer (like the one in a managed setup) beats hand-rolling it on a busy site.
What NOT to Do: Common TTFB Mistakes
Several optimizations look helpful but waste your time or make things worse:
- Hiding TTFB with a loading spinner or skeleton. This does not fix the slow server; it only masks the delay from the user. Google still measures the true response time.
- Fixing TTFB with front-end lazy loading. Lazy loading defers images and scripts — it does not speed up the server’s initial response. It helps LCP but not TTFB.
- Suspicion of “cache everything” plugins that conflict. Too many caching layers fighting each other create stale pages and double work. Use one coherent stack, not five overlapping plugins.
- Optimizing before measuring. If you cannot state your current median TTFB, you are optimizing blind. Measure first.
The Bottom Line
TTFB is the most honest performance metric on the web, and the fastest route to a fast site is fixing it.
Here is the sequence again, in one line: get off shared hosting → tune PHP-FPM → upgrade PHP → cache queries with Redis → add server-level page caching → enable compression and HTTP/2 → put a CDN in front → monitor weekly.
Do all eight and you will land below 200ms, often below 100ms. Do nothing and every other performance effort you make is capped by a slow server.
This is exactly the stack we run on Fortezza Digitale: dedicated VPS infrastructure, native caching, sub-200ms TTFB guaranteed, and continuous monitoring so performance never silently decays.
A slow TTFB is not a mystery. It is a checklist. Now you have it.