Before a browser can show a page, it has to receive a response from the server. Time to First Byte (TTFB) measures that wait: it starts when the browser requests a resource and ends when the first byte of the response arrives.

TTFB is not the whole user experience, but it is a useful early signal. A slow response can delay content rendering, hurt the largest contentful paint, and make every later optimization feel less effective.

What contributes to TTFB?

TTFB includes more than application processing. It can include DNS resolution, establishing a connection, TLS negotiation, network distance, waiting at a CDN or load balancer, and generating the response. The exact mix depends on the test location and the page.

For a dynamic page, a slow TTFB often comes from one of these areas:

• A database query that is missing an index or returning too much data
• Cache misses that force expensive application work
• Too many redirects before the final page
• Busy application servers, limited CPU, or slow cold starts
• An origin server that is far from the visitor
• Third-party API calls made while building the page

Diagnose the delay before changing anything

Start with a website speed test and run it more than once. Compare a first visit with later visits, and test from locations near your customers. A delay only on the first visit can point to a cold cache or cold server process; a delay everywhere is more likely to be an origin, application, or database issue.

Then separate the question into stages:

1. Does the hostname resolve quickly? Check it with a DNS lookup.
2. Is the server reachable consistently? Use a ping test, keeping in mind that some healthy servers block ICMP.
3. Do redirects add extra round trips?
4. Does a cached page respond much faster than an uncached page?
5. Does the response time rise at busy times of day?

Application logs, APM traces, database slow-query logs, and CDN logs can turn those clues into a precise answer. Measure the full request path rather than guessing from a frontend score alone.

Fix the highest-impact cause

Cache pages and expensive data safely

Caching is often the quickest improvement when the same response is requested repeatedly. A CDN can cache public HTML and static assets near visitors. At the application layer, cache expensive database results, rendered fragments, or API responses with an expiry that matches how quickly the data changes.

Do not cache personalized content as if it were public. Vary the cache correctly for logged-in visitors, locale, device-dependent responses, and other inputs that change the output.

Make database work smaller and faster

Inspect the slowest queries instead of optimizing every query. Add appropriate indexes for common filters and joins, select only the fields a page needs, and avoid doing many small queries in a loop. For pages that collect data from several services, consider parallelizing independent work or moving nonessential data below the initial response.

Remove avoidable work from the request path

The request that serves a page should not wait for work that can happen before, after, or outside the request. Common candidates include image processing, analytics writes, sending notifications, and calls to optional third-party services. Queue that work where practical, and set sensible timeouts for dependencies that can fail.

Bring content closer to visitors

A CDN cannot eliminate every origin request, but it can deliver cacheable content from nearby locations and reduce the distance many visitors travel. If users are concentrated far from the origin, choose a hosting region closer to them or use edge caching for the pages they request most.

Re-test with the same conditions

After a change, test the same URL, location, and device profile again. Record several results and compare the median rather than celebrating one unusually fast run. Also monitor error rate and cache behavior—an aggressive cache that serves stale or incorrect content is not a performance win.

Reducing TTFB is about removing waiting from the first step of a visit. Once the server responds promptly, image, rendering, and JavaScript improvements can have a much clearer effect on the experience people actually feel.