What it measures
When a browser requests a page, there is a gap between sending the request and receiving the first piece of the answer. That gap is often called server response time or time to first byte. It includes the time to reach the server, the time the server spends preparing the page and the time for the first part of the reply to travel back.
Nothing else on the page can begin until this first answer arrives. The browser cannot fetch images it does not know about, apply styles it has not received or run scripts it cannot see. Slowness here therefore adds to everything that follows, which is why it appears early in many page speed investigations.
What counts as slow
There is no single official threshold that suits every site. Search engine guidance on speed tends to describe a first response that is quick as helpful, and some public guidance treats a few hundred milliseconds as a reasonable goal, with longer times flagged for attention. Treat any number as a rough guide, not a rule. What matters more is the pattern: is the response consistently slow, or only on certain pages, at certain times or from certain places?
What makes servers answer slowly
Underpowered or crowded hosting. On shared plans, many sites compete for processing power and memory. If a neighbor is busy, your response time can rise. This is part of hosting quality, and it can show up as speed that varies by time of day.
Heavy page generation. Dynamic sites build pages on request by running code and querying a database. Complex templates, many add-ons and large queries all add work. A page that needs dozens of database lookups will usually answer more slowly than a simple one.
Database problems. Large, unoptimized databases, missing indexes and leftover data from removed add-ons can slow queries. Over time, some systems accumulate clutter that adds delay.
No stored copies. Without page caching, the server repeats the same work for every visitor. Adding a cache often produces the largest improvement for content sites, though the first uncached request remains slow.
Outdated server software. Old versions of the programming language or database can be slower than current ones. Hosts that offer a supported modern version often allow switching in settings.
Distance. The farther the server is from the visitor, the more time each request spends traveling. A delivery network can reduce this for static files and, in some setups, for pages.
Network and connection setup. A secure connection requires a short handshake before data flows. Modern servers do this efficiently, but misconfigured ones can add noticeable delay. Redirect chains add further round trips before the final page even starts.
Third-party calls made by the server. If the server must wait for an outside service, such as a license check or a feed, before sending the page, that service’s slowness becomes yours.
Traffic spikes and bots. Sudden surges, aggressive crawlers or malicious traffic can use up capacity. A site that has been compromised may also be running unwanted code that consumes resources.
Resource limits. Some hosts throttle accounts that reach their allotted limits, which can look like random slowness.
How to recognize it in an audit
Use several measurements rather than a single test.
- Test more than one page. Compare the home page, a simple static page and a complex page. If all are slow, suspect the server or hosting. If only complex pages are slow, suspect code or the database.
- Test at different times. Try morning, evening and a busy period. Large swings suggest shared resource contention.
- Test from different locations. If response is quick nearby and slow from far away, distance is a factor.
- Compare cached and uncached requests. Many testing tools let you request a page twice. If the second is much faster, caching works but the underlying generation is slow.
- Look at real-visitor data. Field data from actual visits shows what people experience across devices and networks, while lab tests show a controlled snapshot. Differences between them are informative.
- Check for server errors. Spikes of server errors, especially during peaks, suggest capacity problems and can interrupt crawling and indexing.
- Review reports. Crawl statistics in search reporting often show average response time for crawler requests. A sustained rise is worth investigating.
When measuring, take several samples and look at the typical value rather than the single best or worst. Individual runs vary a lot.
What to try first
Work from the cheapest, lowest-risk changes up.
- Enable or tune page caching.
- Remove unused add-ons and clean up database clutter, after taking a backup.
- Update to a supported, current version of server software if your host allows it.
- Fix redirect chains so visitors reach the final address in one step.
- Consider a content delivery arrangement for static files.
- Review the hosting plan and whether the resources match your traffic.
Change one thing at a time and remeasure, recording each result in a change log. Otherwise you will not know what helped.
Keep expectations realistic
A faster first response helps, but it is only part of the picture. Large images, render blocking scripts and slow fonts can still make a page feel sluggish even if the server is fast. Improving speed supports a better experience and may help search performance indirectly, but it does not guarantee any change in rankings.