Time to First Byte (TTFB) measures how long a browser waits before the first byte of a page response starts arriving. If TTFB is slow, every later loading step starts late — so even a well-designed page can feel sluggish before the browser has had a fair chance to render it.
For most business websites, the fix is not “compress more images.” TTFB problems usually live earlier in the chain: redirects, network distance, hosting, caching, database work, backend code, or slow third-party dependencies.
What TTFB Actually Measures
TTFB starts when navigation begins and ends when the response starts arriving.
According to web.dev's TTFB guidance, that elapsed time can include:
- redirects;
- service-worker startup where applicable;
- DNS lookup;
- connection and TLS negotiation;
- the request travelling to the server;
- server-side processing;
- the beginning of the response travelling back.
“Slow TTFB” does not automatically mean “bad server.” Distance, redirects, and dynamic backend work can all add delay, so TTFB is best treated as a diagnostic starting point.
What Is a Good Website TTFB?
web.dev recommends that most sites aim for a TTFB of roughly 0.8 seconds or less. Between about 0.8 and 1.8 seconds needs improvement; above 1.8 seconds is considered poor in its guidance.
TTFB is not itself a Core Web Vital. A site can have a slightly higher TTFB and still deliver a good experience, but consistently high TTFB makes later metrics harder to improve because the browser receives the starting HTML later.
Do not chase the lowest possible number in isolation. Diagnose whether TTFB is actually delaying useful content.
The Most Common Causes of Slow TTFB
Too many redirects
Every extra redirect before the final page costs time.
Common causes include:
- HTTP to HTTPS redirects;
- non-www to www redirects;
- old campaign URLs;
- outdated internal links;
- chained redesign redirects.
A single necessary redirect is different from a chain of avoidable ones.
The server is too far from the visitor
Physical distance still matters.
A business serving customers across a large country or internationally may benefit from a CDN or edge cache that serves content closer to users. For a local audience already near the server, the benefit may be small.
Dynamic pages are doing too much work
Database queries, authentication, API calls, CMS processing, or complex server-side rendering can raise TTFB. That is why a static page may be fast while an uncached CMS page on the same domain is slow.
Caching is missing or ineffective
If the server rebuilds the same public page for every visitor, it may be doing unnecessary work. Appropriate page, object, CDN, or platform caching can reduce repeat processing.
Hosting is underpowered or poorly configured
Hosting can become the bottleneck when CPU, memory, database performance, or request concurrency is inadequate. Before upgrading, confirm that the application is not simply wasting server time.
Veil Vertex's guide to choosing web hosting for a small business covers the broader hosting questions beyond headline speed claims.
How to Diagnose Slow TTFB Before Changing Anything
Start with measurement, not migration.
1. Check real-user and lab data
PageSpeed Insights can expose field and lab signals when enough public Chrome data is available. web.dev's TTFB optimization guide recommends prioritising field data because real-user TTFB includes redirects and geographic network conditions.
2. Compare several pages
Test:
- the homepage;
- a simple static page;
- a complex service page;
- a logged-out dynamic page;
- pages with and without expensive data fetching.
If every page is slow, infrastructure or network factors become more likely. If only certain templates are slow, investigate their backend work first.
3. Test more than one location
A fast result near the server does not prove that remote customers receive the same experience. Test locations that reflect the actual audience.
4. Compare cached and uncached responses
If the first request is slow but repeated requests are much faster, caching is an important clue.
5. Measure backend stages
For custom backends, Server-Timing headers or application-performance monitoring can separate authentication, database time, and external API calls. That is more useful than guessing that “the host is slow.”
Use the BYTE Framework to Fix TTFB in the Right Order
Veil Vertex uses a simple troubleshooting sequence:
B — Bypass redirects: Remove unnecessary redirect hops and update internal links to the final URL.
Y — Yield cached responses: Cache public content where appropriate so repeated requests do not rebuild identical pages.
T — Trace backend work: Measure database queries, server-side rendering, API calls, plugins, and middleware before replacing infrastructure.
E — Edge and environment: After the application is understood, evaluate CDN placement, server region, hosting resources, runtime configuration, and platform limits.
This order prevents an expensive hosting upgrade from hiding inefficient application behaviour.
When a CDN Helps TTFB
A CDN can help when geography is part of the delay and content can be served or cached near users. It is especially useful for national or international audiences, static content, and traffic distributed across regions.
It will not automatically fix slow database queries or backend code that still runs at the origin for every request.
When Hosting Really Is the Problem
Consider upgrading or changing hosting when measurement shows that:
- server processing stays slow even after application optimisation;
- CPU or memory regularly saturates;
- database performance is consistently poor;
- the platform prevents useful caching;
- the server region is badly matched to the audience;
- traffic bursts overwhelm the current environment.
If a builder or hosting stack is creating broader performance and platform limitations, Veil Vertex's website migration service explains how a move can be planned without treating migration as the first answer to every speed problem.
TTFB Checklist for a Slow Business Website
Before changing platforms, check:
- Is there a redirect chain before the final page?
- Is TTFB slow for real users or only in one lab test?
- Is the problem global or limited to one template?
- Are public pages cached appropriately?
- Is the database or CMS doing expensive work?
- Are external API calls delaying the initial HTML?
- Is the server located far from the target audience?
- Would edge caching or a CDN reduce meaningful latency?
- Are hosting resources actually saturated?
- Does the change improve user-facing loading metrics, not just TTFB?
The goal is getting useful page content to visitors quickly and consistently, not chasing a perfect benchmark score.
Fix the Delay Before Optimising What Comes After It
TTFB happens before the browser can do most of the visible work on a page. If the first response is consistently late, frontend optimisation starts from behind.
Measure where the time is going, remove unnecessary redirects, cache intelligently, trace backend work, and only then decide whether the server or platform needs to change.
If your site feels slow but the cause is unclear, Veil Vertex can review the performance path as part of a free tailored website audit and identify the highest-impact issue before you start replacing infrastructure.