Time to first byte (TTFB) measures how long your server takes to send the first byte of the response after a request. It's pure server-side thinking time, and it sets the floor for everything else — you cannot render faster than your server responds.
What counts as slow
- Under 200ms: excellent — typically static files or a well-cached site behind a CDN.
- 200–600ms: good. Google's recommended range.
- 600ms–1.5s: sluggish. Visitors notice; Core Web Vitals suffer.
- Over 1.5s: severe. Fix this before any other optimisation.
Why it matters twice
First, rankings: speed is a confirmed signal, and TTFB feeds directly into Largest Contentful Paint. Second — and usually bigger — conversions: every additional second of wait measurably reduces the number of people who stay. A slow server costs you sales before it costs you rankings.
There's a third, quieter effect: Google allocates a crawl budget. A slow server means fewer pages crawled per visit, so new content is discovered more slowly.
The causes, in order of likelihood
1. No page caching
The dominant cause on WordPress, Magento and similar platforms. Without caching, every single visitor triggers PHP execution and a series of database queries to rebuild a page that hasn't changed in a month.
Full-page caching serves a pre-built HTML file instead. This is usually the single biggest win available — commonly 1,200ms down to under 200ms.
2. Cheap shared hosting
On budget shared hosting you're sharing CPU with hundreds of other sites. No amount of code optimisation compensates for a saturated server. If you've enabled caching and TTFB is still above a second, the host is the constraint.
3. Slow database queries
Common on older sites: a bloated options table, unindexed queries, or a plugin scanning thousands of rows on every page load. Query monitoring tools will identify the offender quickly.
4. No CDN, distant server
If your server is in London and your visitor is in Sydney, physics imposes a few hundred milliseconds before any code runs. A CDN serves cached content from a location near the user, largely eliminating that.
5. Too many plugins doing work on every request
Each active plugin can add queries and processing to every page load. Audit them: deactivate anything not earning its place, and be especially suspicious of anything doing external API calls during page render.
The fix order that works
- Enable full-page caching. Biggest win, least effort.
- Put a CDN in front. Cloudflare's free tier is sufficient for most sites.
- Upgrade hosting if you're still slow — from shared to a decent managed or VPS plan.
- Profile the database and fix the worst queries.
- Cut unnecessary plugins.
Do them in that order. People routinely start at step 5 and micro-optimise images while an uncached database rebuild is costing them a full second.
Measure yours
Our page speed checker reports your server response time on every audit, alongside compression and render-blocking scripts — the three server-side factors that most often explain a slow page.