What Is Time to First Byte, and How Can I Reduce It?

Time to first byte, or TTFB, describes the wait until the first byte of a response arrives. For a page visit, that wait can include connection and network work as well as the server preparing its response.

It is not the time until the whole page is usable, and it is not a pure measurement of your hosting company’s processing speed. A slow result needs investigation before you decide to buy a different hosting package.

Separate response time from rendering time

A page can receive its first response promptly and still download oversized images or run too much code. Another page can be visually lightweight but wait a long time for the server to produce its HTML.

Google’s TTFB optimisation guidance explains why connection setup, redirects, server work and caching can all matter. Treat TTFB as one part of the loading sequence.

Our website speed guide is the starting point if you do not yet know which part of that sequence feels slow.

Use a fair comparison

Choose a real public page and record:

• the full address, including any redirect;
• the testing location and device;
• whether you are signed in;
• whether the response was cached;
• the time of the test and recent site changes;
• several results, not just the quickest or slowest run.

An administrator’s uncached preview and a customer’s cached public page are not equivalent tests. Nor is a test from another continent a direct measure of a local visitor’s experience.

If only one page is slow, compare it with another page on the same site before blaming the entire hosting service.

A server-versus-page diagnosis checklist

Use these observations to choose the next investigation.

Observation	Useful next question
Long wait before the document responds	Is the delay in redirects, connection or server processing?
Document responds quickly, main image appears late	Is image discovery, download or rendering responsible?
Signed-in view slow, public view quick	Are caching and personalised processing different?
Every page slows at particular times	Are resource limits, traffic or scheduled jobs involved?
Only one template is slow	Does it make extra database or external-service requests?

These are hypotheses, not diagnoses. Ask a developer or hosting provider to connect them to logs and a performance trace.

For an image-dominated loading problem, follow the Largest Contentful Paint guide rather than treating every delay as TTFB.

Make changes in a useful order

First check avoidable redirect chains. Then establish whether the platform is doing unnecessary work for a public response.

On a dynamic site, a developer may need to investigate database queries, extensions or slow external calls. On a static site, the delivery configuration and network route may be more relevant.

Review caching before adding complexity. A cache can improve eligible repeat responses, but it must not serve private information to the wrong visitor or hide required updates.

If WordPress is involved, our guide to slow WordPress websites provides broader context. Do not install several overlapping performance plugins in the hope that one happens to help.

When should hosting change?

Changing hosting makes sense when evidence shows the current service cannot reliably support the site’s requirements, or when the provider cannot resolve a demonstrated limitation.

Ask for the affected pages, repeated measurements and a proposed remedy. Compare the responsibilities included in shared and managed hosting, not just a headline package label.

The hosting cost guide helps frame ongoing costs. A more expensive plan is not automatically a cure for inefficient page generation or a badly configured redirect.

Where visitors are distributed geographically, a CDN may be relevant. Confirm what it would cache and which part of the delay it is expected to reduce.

Verify business functions after optimisation

Repeat the same tests after each meaningful change. Then check edited content, forms, account behaviour and any other critical journeys.

A faster response that contains yesterday’s price or someone else’s personalised information is a failed optimisation. Keep a rollback route and document which configuration changed.

Ask for an explanation you can act on

A useful report says where the delay occurs, what evidence supports the conclusion and what the next small change should be. “The server is slow” is too vague to approve a migration.

TTFB becomes useful when it narrows the investigation. Pair it with what the customer sees and does, then improve the part of the system that is actually holding the page back.

Thinking about your own rebuild?

Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.

Tell us about your project↗

• Website performance
• Small business