What server response time measures

How it works

TTFB stands for Time to First Byte: the time from the start of the request to the first byte of the answer. It is made up of four steps:

1. DNS: the domain name is resolved to an IP address.
2. Connection: the browser connects to the server.
3. TLS: browser and server negotiate encryption.
4. Waiting: the server builds the page and sends the beginning.

bytereport measures as on a first visit, with a fresh connection, and shows each step separately, so you can see where the time goes. Up to 800 ms counts as good, over 1800 ms as poor. These are the thresholds Google recommends on web.dev.

Redirects come on top. Each one costs a full request before the actual page is even asked for.

What matters

• The server's waiting time. If this is the biggest share, the application builds the page afresh on every request. A page cache that serves finished HTML is the biggest lever here.
• Slow database queries and extensions. In a CMS, single plugins that look up a lot on every request are often the brake.
• Distance. If the server is far from your visitors, connecting and TLS take longer. A CDN (content delivery network) answers from a location near them.
• One redirect at most. Redirect to the final address in one step, straight from https://example.com/ to https://www.example.com/, without a stop in between. From two redirects on, bytereport reports a chain.

Not to be confused with browser caching: that only helps on the next visit, a page cache already on the first.

How to set it up

Page cache and server performance are in the hands of your hosting provider or the agency that looks after the site. A CMS has caching plugins, and many hosting packages include a cache. On your own servers the cache sits in the web server or in front of it, for example in nginx or Varnish.

You set up redirects in the web server configuration, in your host's control panel or in the CMS. Measure several times afterwards: response time varies from one request to the next.