Time to First Byte, or TTFB, measures how long it takes from the moment a browser requests a page until the first byte of the answer arrives. It captures the delay before anything at all comes back: the network hop, the server thinking, and the response starting to travel.

Picture ordering at a counter. TTFB is not how long the whole meal takes; it is how long before the staff even acknowledge your order and start moving. If that first response drags, everything after it feels slow too. A high TTFB usually points to a sluggish server, heavy database work, or pages being rebuilt on every visit, which is common with unrefined server-side rendering.

Because it sits at the very start, TTFB influences later metrics like Largest Contentful Paint and your overall Core Web Vitals. The usual fixes are a CDN to shorten the network distance, caching so the server reuses work, and trimming slow database queries. A good target is under 800 milliseconds.

It helps to know where the time actually goes. Picture a visitor in Sydney hitting a server in Frankfurt: the round trip alone can eat 300 milliseconds before the server runs a line of code. A CDN puts a copy near Sydney and that distance shrinks. The rest is server work, so a page that runs three database queries and renders a template fresh every time will always lag behind one served straight from a cache.

One caveat: TTFB is only the opening move. A site can answer fast and still feel slow if the page then ships a wall of JavaScript. So treat it as one signal in your Core Web Vitals, not the whole story.

At TopDevs we keep TTFB low through caching and edge delivery, so every page starts responding before visitors have a chance to notice the wait.