How to Reduce Server Response Time (TTFB) on WordPress

On this page

1. What TTFB actually measures
2. How to check your TTFB
3. Common causes of slow server response
4. Fix 1: Turn on page caching, and check it works
5. Fix 2: Better hosting, closer to your visitors
6. Fix 3: Find heavy plugins and slow queries
7. Fix 4: WooCommerce and other dynamic pages
8. Smaller fixes, then re-test

Before a visitor sees anything on your website, their browser has to wait for your server to send back the first part of the page. On a slow WordPress site, that wait can be the single biggest delay, and every image, font and script queues up behind it. This guide explains what server response time (usually called TTFB) measures, how to check yours, and which fixes to try first.

What TTFB actually measures

Time to First Byte is the time from the browser asking for a page to the first byte of the reply arriving. It covers several steps:

• Redirects: for example from http to https, or from the non-www address to the www one
• Connection setup: looking up your domain, connecting to the server and setting up the secure HTTPS connection
• Server processing: WordPress running PHP, querying the database and building the HTML, unless a ready-made cached copy exists

TTFB isn't one of the three Core Web Vitals, but it comes before all of them. The page can't show its main image or heading until the HTML has arrived, so a slow server pushes back Largest Contentful Paint as well; see how to fix slow LCP. Google's guidance treats roughly 0.8 seconds or less as a good TTFB for most sites, as a rough guide rather than a hard rule.

How to check your TTFB

PageSpeed Insights

If your site has enough traffic, the real-user section at the top includes Time to First Byte alongside the Core Web Vitals. Further down, the lab report has a diagnostic for how long the server took to respond, labelled something like "Reduce initial server response time" or "Document request latency" depending on the version.

Browser developer tools

1. Open the page in a private or incognito window, so you're logged out of WordPress
2. Press F12 in Chrome or Edge and go to the Network tab
3. Reload the page and click the first request in the list, which is the page itself
4. Open the Timing tab and look at "Waiting for server response"

Reload a few times, as the first load may build the page fresh. Many hosts, caching plugins and CDNs also add a response header, visible under the Headers tab, showing whether the page was a cache "hit" or "miss". And always test logged out: WordPress normally skips the page cache for logged-in users, so your own view is often slower than your visitors'.

Common causes of slow server response

Cause	What's happening	Typical clue
No page caching	WordPress builds every page from scratch for every visitor	Every load is slow, not just the first
Slow or overloaded hosting	Too little CPU, memory or PHP capacity, or a crowded shared server	Slow even when cached; worse at busy times
Heavy plugins and queries	Plugins running slow database queries or calling outside services on each request	Uncached pages are far slower than cached ones
Uncached WooCommerce pages	Cart, checkout, account pages and shoppers with items in the cart bypass the cache	Product pages are fine, checkout drags
Distant server	The server is on another continent from most of your visitors	Fast when tested near the server, slow from India

Outdated PHP and redirect chains add to the delay too. Work through the fixes below in order: on a typical business site, the earlier ones usually make the biggest difference.

Fix 1: Turn on page caching, and check it works

A page cache stores ready-made HTML so the server can send it without running WordPress. Use your host's server-level cache if it has one (on LiteSpeed servers, via the LiteSpeed Cache plugin), or one reputable caching plugin. Then check the headers to confirm visitors really get cached pages. Common reasons they don't:

• The whole cache is cleared too often, for example by a plugin that purges everything on every small edit
• A plugin sets a cookie for every visitor, which some caches treat as a reason to skip caching
• Pages are only cached after the first visitor arrives, so rarely visited pages are always slow; a preload option fixes this

The setup options are covered in WordPress caching explained.

Fix 2: Better hosting, closer to your visitors

If cached pages still respond slowly, the server itself is the problem. Check three things:

• Location: a data centre in or near India if most customers are here
• Resources: whether your hosting panel shows CPU or memory limits being hit
• Software: a current, supported PHP version, tested first, and server-level caching

If the plan is simply underpowered, moving is often the fix that makes everything else work; see how to choose WordPress hosting in India. A CDN can help too, and some can cache whole pages, as long as carts, checkouts and logged-in pages are excluded.

Fix 3: Find heavy plugins and slow queries

For pages that can't be cached, and for every cache miss, WordPress's own processing time matters. On a staging copy of the site:

• Use a debugging plugin such as Query Monitor to spot slow database queries, outside requests and the plugin responsible
• Deactivate plugins one at a time and re-time an uncached page to see which adds the most
• Look for plugins that contact outside services, such as social feeds, on every page load
• Clean up the database, especially large autoloaded settings left behind by removed plugins

Then replace or remove what's slow; sometimes one feature from a heavy plugin can be rebuilt as a small snippet.

Fix 4: WooCommerce and other dynamic pages

Stores, membership sites and booking systems have pages built fresh for each person. For these:

• Ask your host about an object cache such as Redis, which keeps database results in memory
• Make sure your plan can handle several shoppers checking out at once, especially before festival sales
• Stop background cart-update requests from running on pages that don't need them

The WooCommerce speed optimisation guide covers these in more detail.

Smaller fixes, then re-test

• Use your final https address in ads, social profiles and Google Business Profile, so visitors skip redirects
• Remove redirect chains, such as http to https to www
• Use a reliable DNS provider; many CDNs include one

After each change, clear the cache, test logged out and time several page types, including product and checkout pages for stores. Lab results vary, so compare a few runs. Real-user data covers the previous 28 days, so improvements there appear gradually.

Still slow after caching? That usually needs a proper diagnosis. My WordPress speed optimisation service covers this, and if the answer is a better host, see WordPress migration and hosting.