Skip to main content
短.be

TTFB

The time from when a browser sends a request to when it receives the first byte of the response. A fundamental metric for server responsiveness.

Aug 25, 2026 · About 1 min read

Redirect

TTFB (Time to First Byte) measures the elapsed time from the moment a browser starts navigating to a page to the moment the very first byte of the server's response begins to arrive. It is the most fundamental indicator of server responsiveness and the starting point for all web performance analysis.

TTFB covers the time spent on redirects, service worker startup, DNS lookup, connection and TLS negotiation, and finally the request itself up to the point where the first byte of the response arrives. Server-side processing sits inside that last segment, so when TTFB is high it pays to separate slow server work from time spent waiting on name resolution and connection setup.

Google classifies TTFB as a supplementary Core Web Vitals metric. A good TTFB is 800 ms or less, the 800 ms to 1800 ms band needs improvement, and anything above 1800 ms counts as poor. For shortened URL redirects, where the server simply looks up a mapping and returns a 301/302, the target should be under 50 ms.

Optimization techniques for a URL shortening service include CDN deployment (serving responses from edge locations close to the user), in-memory caching with Redis (caching URL mappings for sub-millisecond lookups), database index tuning, and enabling HTTP/2 for connection multiplexing.

Measurement tools include the Waiting (TTFB) entry in the timing breakdown of the Chrome DevTools Network panel, Lighthouse performance audits, curl (curl -w '%{time_starttransfer}' URL), and WebPageTest. Separating server processing time from network transit time pinpoints the actual bottleneck.

Share on XHatena

Was this article helpful?

Related Terms

Related Articles

FAQ

What is the difference between TTFB and LCP?
TTFB measures the time until the server starts responding. LCP (Largest Contentful Paint) measures the time until the largest visible content element is rendered. TTFB precedes LCP, so whatever TTFB costs also raises the floor for LCP. Google notes, however, that a server-rendered page can have a higher TTFB and still reach better FCP and LCP values, so TTFB alone does not decide whether LCP is good.
What is a good TTFB target?
Google considers 800 ms or less to be good for general web pages. For shortened URL redirects, aim for under 50 ms. With a CDN and caching in front, some setups get down to the 10-30 ms range.
What causes a slow TTFB?
Common causes include insufficient server capacity, slow database queries, physical distance between server and user, and SSL/TLS handshake overhead. Deploying a CDN and optimizing caching are the most impactful improvements.

Put the terms to work

Shorten a URL for Free