Website Speed and Hosting: What TTFB Actually Depends On

Hosting sets the floor for website speed and cannot raise the ceiling. Server location, time to first byte and available resources decide how fast a response can possibly start; page weight, render-blocking assets and layout stability decide what the user actually experiences. Fix the floor first — it is cheap and it is measurable — then fix the page.

The three numbers that matter

Google's Core Web Vitals are the useful shorthand, because they map onto what users notice:

Metric	Measures	Good	Mostly controlled by
LCP — Largest Contentful Paint	When the main content appears	≤ 2.5 s	TTFB, image weight, render-blocking CSS
INP — Interaction to Next Paint	Responsiveness to input	≤ 200 ms	JavaScript on the main thread
CLS — Cumulative Layout Shift	Visual stability while loading	≤ 0.1	Missing image dimensions, injected content

Only LCP has a large hosting component. INP and CLS are front-end problems, and no amount of server capacity improves them — worth knowing before you buy a bigger plan to fix a JavaScript issue.

Time to first byte: where hosting lives

TTFB is the sum of DNS lookup, TCP handshake, TLS negotiation, server processing and the first byte travelling back. It is the part of LCP you buy rather than build, and it decomposes into three things:

1. Distance

Light in fibre covers roughly 200 km per millisecond, and a connection makes several round trips before content moves. Serving European users from the US East Coast adds 90–120 ms per round trip, several times over. Choosing Frankfurt for German traffic or Warsaw for Polish traffic is the largest single speed improvement available to most sites, and it costs nothing extra — see choosing a datacenter location.

2. Server processing time

An uncached dynamic page typically spends 100–800 ms in the application. Caching removes that almost entirely:

# prove where the time goes before optimising
curl -o /dev/null -s -w \
  'dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n' \
  https://example.com/

If ttfb minus tls is large, the server is slow. If connect is large, the problem is distance. This one command tells you which of the two you have, and saves you optimising the wrong thing.

3. Resource contention

A server at its memory limit swaps; a server at its CPU limit queues. Both show up as inconsistent TTFB — fast when idle, slow under load. This is the case where a plan upgrade genuinely is the fix, and the performance guide covers how to tell contention from a configuration problem.

The hosting-side fixes, in order of leverage

1. Full-page caching. Serve rendered HTML without running the application. Takes TTFB from hundreds of milliseconds to tens.
2. Object caching. Redis or Memcached for the requests page caching cannot cover — logged-in users, carts, admin.
3. HTTP/2 or HTTP/3. Multiplexing removes head-of-line blocking for pages with many assets.
4. Compression. Brotli or gzip on text, JSON, CSS and JS — routinely 60–80% smaller.
5. Correct cache headers. Long, immutable caching on fingerprinted assets; short on HTML.
6. A CDN. Static assets served from the edge, close to every user rather than one.
7. Faster storage. Matters for database-heavy sites — see SSD versus NVMe.

Items 1 and 6 usually account for most of the achievable gain. The rest are worth doing and will not rescue an uncached site.

The page-side fixes hosting cannot do for you

• Image weight. Usually the majority of page bytes. WebP or AVIF, sized to display dimensions, lazy-loaded below the fold.
• Render-blocking CSS and JS. Inline critical CSS, defer the rest.
• Third-party scripts. Analytics, chat widgets, tag managers and ad scripts are the most common cause of poor INP, and each one is a request to a server you do not control.
• Explicit dimensions on images and embeds. The single most common cause of CLS is an image that has no reserved space until it loads.
• Font loading. font-display: swap and preloading the one font you actually need above the fold.

Measure lab and field, and know the difference

Lab tools — Lighthouse, WebPageTest — run one page on a defined connection. They are reproducible and good for comparing before and after a change. Field data — real users, in Chrome's CrUX dataset or your own RUM — reflects actual devices and networks, and is what search engines use.

They disagree regularly, and when they do the field data is the truth. A site that scores 95 in the lab and fails Core Web Vitals in the field usually has a slow mobile audience the lab did not simulate.

A realistic sequence

1. Measure TTFB with the curl command above, from your users' region.
2. If distance dominates, move the server closer. Nothing else on this list is as effective.
3. If processing dominates, add page caching, then object caching.
4. Put a CDN in front of static assets.
5. Fix images, then render-blocking resources, then third-party scripts.
6. Re-measure in the field, not just the lab.
7. Only now consider a larger plan — and only if you have evidence of resource contention.

Frequently asked questions

Will a faster server fix a slow website?

It fixes the server's share, which is TTFB. If your page ships 6 MB of images and blocking JavaScript, a faster server produces a page that starts loading sooner and still finishes slowly.

What is a good TTFB?

Under 200 ms is comfortable; under 100 ms is achievable with caching and a nearby server. Above 600 ms, look at caching and location before anything else.

Does hosting affect SEO?

Indirectly and genuinely. Core Web Vitals are a ranking signal, and hosting drives LCP through TTFB. It is one input among many, not a shortcut.

Is a CDN a substitute for good hosting?

For static assets, largely. For dynamic pages, personalised content and API responses, no — those reach the origin, and the origin's speed and location still decide.

Start with the floor

Put the server near your users and cache aggressively, and most sites find their remaining problems are front-end ones. Our KVM VPS plans deploy in under a minute across twelve locations on 1 Gbps unmetered ports — and because they bill hourly, measuring TTFB from a second region before committing costs a few cents.