Quick answer: Server response time is how long your server takes to start sending a page after a browser asks for it, often measured as Time to First Byte (TTFB). Slow response times usually come from the server building each page from scratch on every visit, slow or overloaded hosting, an outdated PHP version, heavy plugins and slow database queries, or long distances between the server and visitors. The biggest wins normally come from full page caching, a current PHP version, better hosting, an object cache for dynamic sites, removing slow plugins and using a CDN.
What server response time means
When someone visits a page, the browser:
- Looks up the domain name (DNS)
- Opens a connection to the server
- Negotiates HTTPS encryption
- Sends the request
- Waits while the server prepares the response
- Receives the first byte of the page
Time to First Byte covers all of this, from the request starting to the first byte arriving. Server response time, strictly, is step 5: the time the server spends working on the request. That waiting step is the part you control most directly, and it is what Lighthouse and PageSpeed Insights flag in the “Reduce server response times” audit.
Nothing on the page can start loading until the HTML begins to arrive. A slow server delays everything that follows, including images, scripts and the first content visitors see.
How fast is fast enough?
Google’s older PageSpeed guidance suggested aiming for a server response time under 200 milliseconds. Lighthouse flags the main document when the server takes longer than about 600 milliseconds. In practice:
- Under 200 ms is very good
- 200 to 500 ms is acceptable for many dynamic sites
- Over 600 ms is worth investigating
- Over a second points to a real problem
Measure several times and from different locations. One slow result can be a fluke.
How to measure it
- PageSpeed Insights or Lighthouse: shows server response time as a diagnostic.
- WebPageTest: shows a waterfall with separate DNS, connection, TLS and waiting times for the main document, from many locations.
- Chrome DevTools: in the Network panel, click the main document and open the Timing tab. “Waiting (TTFB)” is the server time.
- Uptime monitors: many record response time over days and weeks, which helps spot patterns. See our guide to uptime monitoring.
Test both cached and uncached pages. A homepage that is cached may respond in 100 ms while a search results page or logged-in dashboard takes two seconds.
Where the delay usually comes from
1. Building pages on every request
WordPress and most content management systems are dynamic. On each visit, PHP loads WordPress, every active plugin and the theme, runs database queries and assembles the HTML. Without caching, this happens for every visitor, even when the page has not changed.
Fix: full page caching. Store a ready-made copy of each page and serve it directly. This can cut response times dramatically for anonymous visitors. Options include server-level caching from your host, caching plugins and reverse proxies such as Varnish or Nginx FastCGI cache. Our guides to website caching and WordPress caching plugins explain the choices.
Some pages cannot be fully cached, such as carts, checkouts, account pages and anything personalised. Those need the other fixes below.
2. Slow or overloaded hosting
Cheap shared hosting puts many sites on one server. When neighbours are busy, your site slows down. Limited CPU, memory and slow disks all add to response time.
Fix: better hosting. A good managed WordPress host, a VPS or cloud server with enough resources, SSD storage and server-level caching often makes a large difference. Our articles on WordPress hosting and cloud hosting compare options.
3. Outdated PHP
Each major PHP release has made WordPress faster. PHP 7 was a big jump over PHP 5.6, and later 7.x releases improved further. PHP 7.4 was released at the end of November 2019. Old versions also stop receiving security fixes.
Fix: upgrade PHP to a supported 7.x version, after testing your theme and plugins on staging. Our guides to PHP 7 performance and PHP versions for WordPress explain how.
Also check that OPcache is enabled. It stores compiled PHP code in memory so it does not need to be recompiled on every request. Most good hosts enable it by default.
4. Heavy plugins and themes
Some plugins run expensive work on every page load: remote API calls, complex queries, logging, or loading large amounts of code even on pages that do not use it. Page builders and multipurpose themes can also add significant overhead.
Fix: find and remove the slow ones. The Query Monitor plugin shows database queries, slow hooks and which plugins are responsible. Test response time with plugins deactivated one by one on a staging site. Replace or remove the worst offenders.
5. Slow database queries
As sites grow, the database grows too. Large options tables full of autoloaded data, millions of rows of old logs or post revisions, and missing indexes can slow every request.
Fix: tidy and optimise the database. Remove old revisions, spam comments, expired transients and leftover data from deleted plugins. Check autoloaded options. Our guide to WordPress database optimization covers the steps.
6. No object cache on dynamic sites
For pages that cannot be fully cached, an object cache stores the results of database queries in memory so they can be reused.
Fix: use Redis or Memcached as a persistent object cache. This helps WooCommerce stores, membership sites and busy admin areas. See our guide to Redis object cache.
7. External API calls during page load
If your theme or a plugin fetches data from another service, such as social feeds, exchange rates or stock levels, while building the page, your response time depends on that service’s speed.
Fix: cache external data and refresh it in the background on a schedule, instead of calling the API on every page view.
8. Distance between server and visitors
Data takes time to travel. A server in the United States serving visitors in Australia adds noticeable delay to every round trip.
Fix: host close to your main audience and use a CDN. Some CDNs can cache whole HTML pages at the edge, not just images and scripts. Our Cloudflare for WordPress guide covers one common setup.
9. Slow DNS and connection setup
Slow DNS providers and missing HTTPS optimisations add time before the server even sees the request.
Fix: use a fast DNS provider, enable HTTP/2, keep TLS configuration modern and turn on features like session resumption. Our article on HTTP/2 explains the benefits.
A sensible order of work
- Measure response time for key page types, cached and uncached.
- Turn on full page caching if it is not already working.
- Upgrade PHP and confirm OPcache is enabled.
- Profile plugins and remove or replace slow ones.
- Clean up the database.
- Add an object cache for dynamic or logged-in pages.
- Move to better hosting if the server is still the bottleneck.
- Add a CDN for visitors far from the server.
Re-measure after each change so you know what made a difference.
Server response time and mobile visitors
Mobile visitors already deal with higher network latency. A slow server adds to that delay before anything appears. Our guide to mobile page speed covers the other factors that slow phones down.
FAQ
Is TTFB a ranking factor?
Google uses page speed as a ranking signal, and a slow server slows the whole page. Improving server response time helps visitors first and can support rankings.
Why is my site fast for me but slow in tests?
You may be seeing a cached version, or you may be close to the server. Testing tools often hit uncached pages or test from further away.
Will a caching plugin fix everything?
It fixes the biggest cause for most visitors, but carts, checkouts and logged-in pages still depend on fast hosting, PHP and database performance.
Does WooCommerce need special care?
Yes. Many WooCommerce pages cannot be fully cached, so hosting quality, object caching and lean plugins matter more. See our guide to WooCommerce speed.
Fix the first second
Every visitor waits for your server before anything else happens. Caching, current PHP, sensible hosting and lean plugins usually remove most of that wait. If you want a faster site that turns more visitors into customers, see our Turn visitors into customers service.
