{"id":1038,"date":"2026-08-05T09:57:08","date_gmt":"2026-08-05T07:57:08","guid":{"rendered":"https:\/\/aarkly.com\/?p=1038"},"modified":"2026-08-05T09:57:09","modified_gmt":"2026-08-05T07:57:09","slug":"wordpress-ttfb-optimization-reduce-time-to-first-byte","status":"publish","type":"post","link":"https:\/\/aarkly.com\/it\/wordpress-ttfb-optimization-reduce-time-to-first-byte\/","title":{"rendered":"WordPress TTFB Optimization: Get Time to First Byte Under 200ms"},"content":{"rendered":"

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)<\/strong>.<\/p>\n\n\n\n

TTFB is the time between a user’s browser requesting your page and receiving the first byte<\/em> of the response. It is the purest measure of how fast your server actually is \u2014 before a single image, script or style sheet is downloaded.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

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 \u2014 the target we guarantee on the Fortezza Digitale infrastructure.<\/p>\n\n\n\n

What Is a Good TTFB for WordPress?<\/h2>\n\n\n\n

Before optimizing, you need a benchmark. Here is the scale most performance engineers use:<\/p>\n\n\n\n

    \n
  • Under 100ms:<\/strong> Excellent. Only dedicated VPS or dedicated servers with tuned software reach this.<\/li>\n\n\n\n
  • 100\u2013200ms:<\/strong> Very good. A well-configured VPS with proper caching. This is the target for serious sites.<\/li>\n\n\n\n
  • 200\u2013500ms:<\/strong> Acceptable but lazy. Typical of shared hosting or an untuned VPS. Users notice it.<\/li>\n\n\n\n
  • 500ms\u20131s:<\/strong> Poor. Your server is the bottleneck. Visitors start to bounce.<\/li>\n\n\n\n
  • Over 1s:<\/strong> Critical. Something is fundamentally wrong with your hosting or configuration.<\/li>\n<\/ul>\n\n\n\n

    Google recommends a TTFB of under 800ms<\/strong>, but that is a floor, not a target. For a site that ranks and converts, aim for 200ms or less<\/strong>. Every 100ms of server latency directly delays your LCP and pushes your Core Web Vitals further from green.<\/p>\n\n\n\n

    The painful truth: if your TTFB is over 300ms, your hosting is the problem, not your site.<\/strong> You can polish the front end all day, but a slow server response caps everything.<\/p>\n\n\n\n

    How to Measure TTFB Correctly<\/h2>\n\n\n\n

    Most people measure TTFB wrong. A browser’s network panel includes DNS lookup, connection setup and TLS handshake, which can mislead you.<\/p>\n\n\n\n

    Measure at the Server Level<\/h2>\n\n\n\n

    The cleanest measurement is at the server itself, bypassing the network:<\/p>\n\n\n\n

    curl -o \/dev\/null -s -w \"TTFB: %{time_starttransfer}s\\n\" https:\/\/yourdomain.com<\/code><\/pre>\n\n\n\n
    This 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).<\/p>\n\n\n\n
    Measure from Multiple Locations<\/h2>\n\n\n\n
    A single measurement from your own office tells you little. Use:<\/p>\n\n\n\n
      \n
    • WebPageTest<\/strong> with a location far from your server to test global latency.<\/li>\n\n\n\n
    • GTmetrix<\/strong> waterfall view to see TTFB split by DNS, connection and wait time.<\/li>\n\n\n\n
    • Google PageSpeed Insights<\/strong> \u2014 look at the “server response time” field in the diagnostics.<\/li>\n<\/ul>\n\n\n\n
      Separate the Two TTFB Components<\/h2>\n\n\n\n
      A measured TTFB is actually two things: network RTT<\/strong> (how far your user is from your server) and server processing time<\/strong> (how long the server takes to build the response).<\/p>\n\n\n\n
      The curl command above shows you the total<\/em>. To isolate server processing, compare it to a simple latency test (ping<\/code> or curl<\/code> to a static file). If a static file is fast (20ms) but your homepage is 400ms, the problem is server-side processing<\/strong>, not the network.<\/p>\n\n\n\n
      This distinction matters: a CDN fixes network latency, but only server tuning fixes slow processing. Most WordPress TTFB problems are server-side \u2014 and profitable to fix because you control them.<\/p>\n\n\n\n
      The 8-Step Sequence to Cut WordPress TTFB<\/h2>\n\n\n\n
      Work through these in order. Each step addresses a different layer of the stack, and each compounds on the previous one.<\/p>\n\n\n\n
      Step 1: Fix the Hosting Itself<\/h2>\n\n\n\n
      TTFB starts with the foundation. If you are on shared hosting, this is your ceiling, period.<\/p>\n\n\n\n
      Shared hosting throttles CPU, limits inode usage and oversells server resources. Your “fast” neighbor’s traffic spike slows your site. No optimization \u2014 caching, CDN or otherwise \u2014 fully compensates for a host that throttles you.<\/p>\n\n\n\n
      Move to a VPS with guaranteed CPU and RAM<\/strong>. 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.<\/p>\n\n\n\n
      You do not need the most expensive plan. You need guaranteed resources<\/strong>. A modest but isolated VPS beats a nominally faster shared plan every time.<\/p>\n\n\n\n
      Step 2: Tune PHP-FPM<\/h2>\n\n\n\n
      PHP-FPM is the process manager that runs your PHP code. Its default configuration is designed for low memory, not speed \u2014 and it throttles high-traffic WordPress sites.<\/p>\n\n\n\n
      Open your php-fpm.conf<\/code> (or pool config) and adjust:<\/p>\n\n\n\n
      pm.max_children = 30\npm.start_servers = 5\npm.min_spare_servers = 5\npm.max_spare_servers = 10<\/code><\/pre>\n\n\n\n
      The exact numbers depend on your server’s RAM. A rough rule: each PHP worker uses about 40\u201380MB. A 4GB VPS comfortably runs 30\u201340 workers.<\/p>\n\n\n\n
      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.<\/p>\n\n\n\n
      Step 3: Use the Right PHP Version<\/h2>\n\n\n\n
      This is the cheapest TTFB win available. Each PHP major version is faster than the last.<\/p>\n\n\n\n
        \n
      • PHP 7.4 reached end of life and is dramatically slower than modern versions.<\/li>\n\n\n\n
      • PHP 8.1 is roughly 2x faster<\/strong> than PHP 7.4 for typical WordPress workloads.<\/li>\n\n\n\n
      • PHP 8.2 and 8.3 continue the gains with JIT support and opcache improvements.<\/li>\n<\/ul>\n\n\n\n
        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\u201350% with zero code changes. Verify your plugins and theme support the version first, but almost all modern plugins do.<\/p>\n\n\n\n
        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 \u2014 a significant server-side reduction.<\/p>\n\n\n\n
        Step 4: Optimize the Database<\/h2>\n\n\n\n
        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.<\/p>\n\n\n\n
        Start with query result caching<\/strong> (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.<\/p>\n\n\n\n
        Then clean the database:<\/p>\n\n\n\n
          \n
        • Remove transients, revisions and spam from the tables.<\/li>\n\n\n\n
        • Add proper indexes to the wp_options<\/code> and wp_postmeta<\/code> tables \u2014 these are the most-query-heavy tables in WordPress.<\/li>\n\n\n\n
        • Consider MariaDB or MySQL 8<\/strong> over older MySQL versions for better query optimizer and InnoDB performance.<\/li>\n<\/ul>\n\n\n\n
          A tuned database should answer a page’s worth of queries in under 30ms. If it takes 200ms, the database is your bottleneck.<\/p>\n\n\n\n
          Step 5: Add Page Caching at the Server Level<\/h2>\n\n\n\n
          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.<\/p>\n\n\n\n
          There are two tiers:<\/p>\n\n\n\n
            \n
          • Plugin page caching<\/strong> (e.g., WP Super Cache, cache plugins) works but still boots WordPress and PHP to serve the cached file \u2014 its TTFB is only marginally better than a dynamic page.<\/li>\n\n\n\n
          • Server-level cache<\/strong> (Nginx FastCGI cache, Varnish, Redis page cache) serves the cached HTML from memory before<\/em> PHP runs. For anonymous visitors this can push TTFB below 50ms.<\/li>\n<\/ul>\n\n\n\n
            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.<\/p>\n\n\n\n
            Step 6: Enable Compression and HTTP\/2<\/h2>\n\n\n\n
            Two protocol-level tweaks reduce the bytes transferred and the connection overhead:<\/p>\n\n\n\n
              \n
            • Gzip or Brotli<\/strong> compression shrinks HTML, CSS and JS by 60\u201380% before they hit the wire. Brotli generally compress better than gzip at the same settings.<\/li>\n\n\n\n
            • HTTP\/2<\/strong> multiplexes multiple requests over a single connection, eliminating the head-of-line blocking of HTTP\/1.1 and reducing round trips for page assets.<\/li>\n<\/ul>\n\n\n\n
              Both are configured under the hood at the web server or CDN level. They do not directly reduce server processing<\/em> time, but they shave real milliseconds from the total response \u2014 and they are free.<\/p>\n\n\n\n
              Step 7: Add a CDN with Edge Caching<\/h2>\n\n\n\n
              A Content Delivery Network (CDN) replicates your static assets \u2014 and, with edge caching, your whole page \u2014 to data centers closer to your visitors.<\/p>\n\n\n\n
              This addresses the network RTT<\/strong> component of TTFB. A user in Milan hitting a server in Frankfurt or Amsterdam has 30\u201360ms of round-trip latency. With a CDN edge node in Milan, that drops to under 10ms.<\/p>\n\n\n\n
              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.<\/p>\n\n\n\n
              Because we serve European clients with GDPR requirements, we use a CDN with EU-only edge locations and ensure no data leaves the EU.<\/p>\n\n\n\n
              Step 8: Monitor and Maintain<\/h2>\n\n\n\n
              Optimization is not a one-time task. TTFB degrades silently as your site grows, plugins accumulate and traffic patterns shift.<\/p>\n\n\n\n
              Set up a monitoring loop:<\/p>\n\n\n\n
                \n
              • Weekly:<\/strong> Run the curl measurement above and log the median.<\/li>\n\n\n\n
              • Monthly:<\/strong> Check Core Web Vitals in Search Console and PageSpeed Insights.<\/li>\n\n\n\n
              • On change:<\/strong> Re-test TTFB whenever you add a heavy plugin, change the theme, or alter the server config.<\/li>\n<\/ul>\n\n\n\n
                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.<\/p>\n\n\n\n
                A Real-World Diagnosis: From 900ms to 160ms<\/h2>\n\n\n\n
                To make this concrete, here is the exact sequence of findings from a typical slow WordPress site \u2014 the same pattern we see on nearly every site that arrives on Fortezza with “my site is slow.”<\/p>\n\n\n\n
                Starting point:<\/strong> 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.<\/p>\n\n\n\n
                Diagnosis (5 minutes):<\/strong><\/p>\n\n\n\n
                  \n
                • curl -w \"TTFB: %{time_starttransfer}s\"<\/code> \u2192 900ms. Already the whole problem.<\/li>\n\n\n\n
                • Serving a static file \u2192 40ms. So the network was fine; the server processing was 860ms.<\/li>\n\n\n\n
                • PHP version checked \u2192 still running PHP 7.4, end of life.<\/li>\n\n\n\n
                • pm.max_children<\/code> \u2192 set to a conservative 10 workers, all saturated during traffic peaks.<\/li>\n\n\n\n
                • Redis object cache \u2192 not installed. Every request repeated the same ~40 database queries.<\/li>\n\n\n\n
                • No server-level page cache. Every anonymous page load executed full PHP + MySQL.<\/li>\n<\/ul>\n\n\n\n
                  Fixes applied in order:<\/strong><\/p>\n\n\n\n
                    \n
                  • Upgraded PHP 7.4 \u2192 PHP 8.3: TTFB dropped from 900ms to ~500ms. The compiler and OpCache improvements alone did most of this.<\/li>\n\n\n\n
                  • Tuned PHP-FPM pm.max_children<\/code> from 10 to 32 and adjusted spare servers: TTFB dropped to ~350ms. No more queueing on free workers.<\/li>\n\n\n\n
                  • Installed Redis as the object cache backend: TTFB dropped to ~260ms. Repeated database queries stopped.<\/li>\n\n\n\n
                  • Enabled Nginx FastCGI cache for anonymous visitors: TTFB dropped to ~120ms, because PHP no longer ran at all for cached pages.<\/li>\n\n\n\n
                  • Added an EU-edge CDN for the residual geographic latency: TTFB measured from a remote European city dropped to ~90ms.<\/li>\n<\/ul>\n\n\n\n
                    Final result:<\/strong> TTFB of 90\u2013120ms (depending on location), LCP under 2.5s, Core Web Vitals fully green. Total time invested: under an hour, all server-side.<\/p>\n\n\n\n
                    The lesson is the same every time: the site was never broken \u2014 the stack was.<\/strong> 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.<\/p>\n\n\n\n
                    A Reference Nginx FastCGI Cache Config<\/h2>\n\n\n\n
                    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:<\/p>\n\n\n\n
                    # In the http context\nfastcgi_cache_path \/var\/cache\/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;\nfastcgi_cache_key \"$scheme$request_method$host$request_uri\";\n\n# In the server \/ location block that proxies PHP\nset $skip_cache 0;\nif ($request_uri ~* \"\/wp-admin\/|\/wp-json\/|\/xmlrpc.php|wp-.*.php\") { set $skip_cache 1; }\nif ($request_method = POST) { set $skip_cache 1; }\nif ($query_string != \"\") { set $skip_cache 1; }\n\nlocation ~ \\.php$ {\n    include fastcgi_params;\n    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;\n    fastcgi_pass unix:\/var\/run\/php\/php8.3-fpm.sock;\n    fastcgi_cache WORDPRESS;\n    fastcgi_cache_valid 200 60m;\n    add_header X-Cache $upstream_cache_status;\n    fastcgi_cache_bypass $skip_cache;\n    fastcgi_no_cache $skip_cache;\n}<\/code><\/pre>\n\n\n\n
                    The X-Cache<\/code> header lets you confirm the cache is working: HIT<\/code> appears on cached responses, MISS<\/code> on the first request. The $skip_cache<\/code> rules keep the admin area, the REST API and logged-in flows dynamic, so you never serve stale content to authenticated users.<\/p>\n\n\n\n
                    Note that WordPress sets Cache-Control<\/code> headers and you may need a small adjustment for full compatibility. For team behavior and logged-in sessions, edge cases matter \u2014 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.<\/p>\n\n\n\n
                    What NOT to Do: Common TTFB Mistakes<\/h2>\n\n\n\n
                    Several optimizations look helpful but waste your time or make things worse:<\/p>\n\n\n\n
                      \n
                    • Hiding TTFB with a loading spinner or skeleton.<\/strong> This does not fix the slow server; it only masks the delay from the user. Google still measures the true response time.<\/li>\n\n\n\n
                    • Fixing TTFB with front-end lazy loading.<\/strong> Lazy loading defers images and scripts \u2014 it does not speed up the server’s initial response. It helps LCP but not TTFB.<\/li>\n\n\n\n
                    • Suspicion of “cache everything” plugins that conflict.<\/strong> Too many caching layers fighting each other create stale pages and double work. Use one coherent stack, not five overlapping plugins.<\/li>\n\n\n\n
                    • Optimizing before measuring.<\/strong> If you cannot state your current median TTFB, you are optimizing blind. Measure first.<\/li>\n<\/ul>\n\n\n\n
                      Il punto fondamentale<\/h2>\n\n\n\n
                      TTFB is the most honest performance metric on the web, and the fastest route to a fast site is fixing it.<\/p>\n\n\n\n
                      Here is the sequence again, in one line: get off shared hosting \u2192 tune PHP-FPM \u2192 upgrade PHP \u2192 cache queries with Redis \u2192 add server-level page caching \u2192 enable compression and HTTP\/2 \u2192 put a CDN in front \u2192 monitor weekly.<\/strong><\/p>\n\n\n\n
                      Do all eight and you will land below 200ms<\/strong>, often below 100ms. Do nothing and every other performance effort you make is capped by a slow server.<\/p>\n\n\n\n
                      This is exactly the stack we run on Fortezza Digitale<\/strong>: dedicated VPS infrastructure, native caching, sub-200ms TTFB guaranteed, and continuous monitoring so performance never silently decays.<\/p>\n\n\n\n
                      A slow TTFB is not a mystery. It is a checklist. Now you have it.<\/p>","protected":false},"excerpt":{"rendered":"
                      Scopri come ridurre il Time to First Byte di WordPress sotto i 200ms: hosting, PHP-FPM, Redis, page caching lato server e CDN. Checklist operativa completa.<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ai_primary_source":"0","visibility_scope":"both","ai_summary":"","ai_intent":"","ai_related_resources":"","ai_priority":5,"ai_entity_type":"","ai_is_based_on":"","ai_citations":"","ai_mentions":"","ai_speakable_selector":"","ai_chunk_hints":"","footnotes":""},"categories":[3,6],"tags":[34,33,30],"ai_visibility":[22],"class_list":["post-1038","post","type-post","status-publish","format-standard","hentry","category-performance-hosting","category-wordpress","tag-caching","tag-site-speed","tag-wordpress-performance"],"blocksy_meta":[],"_links":{"self":[{"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/posts\/1038","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/comments?post=1038"}],"version-history":[{"count":1,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/posts\/1038\/revisions"}],"predecessor-version":[{"id":1039,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/posts\/1038\/revisions\/1039"}],"wp:attachment":[{"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/media?parent=1038"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/categories?post=1038"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/tags?post=1038"},{"taxonomy":"ai_visibility","embeddable":true,"href":"https:\/\/aarkly.com\/it\/wp-json\/wp\/v2\/ai_visibility?post=1038"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}