You click a link to your own website and wait. The tab shows a spinner, the screen stays blank, and for a second or two nothing seems to happen at all. Then the page appears all at once and loads quickly from there. It is not the images, and it is not the scripts. The page is slow before it even starts, because the server is taking its time to answer.
That waiting time has a name: Time to First Byte, or TTFB. It is the foundation of everything else a visitor experiences, and it is also one of the most fixable performance problems. This checklist explains what makes a server slow to respond and the practical fixes that bring it down.
What TTFB actually measures
TTFB is the time between the browser asking for a page and receiving the first byte of the response. It includes:
- Connection setup: looking up the domain, connecting to the server and negotiating HTTPS.
- Redirects, if the address you requested sends the browser somewhere else first.
- Server processing: the time the server spends building the page, often running code and database queries.
- The first data travelling back across the network.
Nothing can appear on screen until the first byte arrives. That is why a slow TTFB drags down Largest Contentful Paint, one of Google's Core Web Vitals, no matter how well optimised the rest of the page is; our guide to Core Web Vitals explains how the two connect.
What is a good TTFB?
As a practical target, aim for under 600 ms for your pages, and under about 200 ms for cached pages served from a well-configured server or CDN. Google's Core Web Vitals guidance treats around 0.8 seconds as good for real users, measured at the 75th percentile.
How to measure it properly
Measuring from your own laptop mixes in your connection and whatever else your computer is doing. The Website Speed Tester downloads a page's HTML from our server and reports the server response time, the full HTML download time, the number of redirects and how much time they add, the HTML size before and after compression, the compression method, and the Cache-Control header. It grades the result from A to F using six clearly listed checks, so you can see exactly what to fix.
Two tips for reliable measurements:
- Run the test twice. The first request may hit a cold cache or wake up a sleeping server. The second result is closer to what most visitors get.
- Test more than the homepage. Product, category and article pages often use different templates and different amounts of database work.
The checklist
1. Turn on page caching
On most dynamic sites, especially WordPress, the server builds every page from scratch on every visit: running PHP, querying the database, assembling the HTML. A page cache stores the finished HTML and serves it instantly to the next visitor.
This is usually the single biggest improvement available. It is common for a cache to take TTFB from well over a second to a small fraction of that. Most WordPress hosts offer built-in caching, and caching plugins are widely available. Just remember to exclude pages that must stay personal, such as carts, checkouts and account areas.
2. Remove unnecessary redirects
Every redirect adds a full round trip before the real page starts. A visitor who types http://example.com might go through https://example.com and then https://www.example.com before anything loads. Check your common entry addresses with the Redirect Checker and make sure each one reaches its destination in a single step. Our guide to 301 vs 302 redirects covers how to collapse chains.
3. Enable compression
Gzip or Brotli compression typically shrinks HTML by 70 to 90 percent, so it arrives much faster. It is usually a single setting in your hosting panel, server configuration or CDN. The speed test shows whether compression is active.
4. Use a CDN
A content delivery network serves your site from locations close to each visitor. Even without caching full pages, it can shorten the connection setup, and with full-page caching at the edge, response times can drop dramatically for visitors far from your server. To see how your site performs from different parts of the world, run an HTTP check from more than 30 countries with the Ping & Uptime Checker.
5. Reduce the work each page does
If pages cannot be cached, make building them cheaper:
- Deactivate plugins you do not need. Each one can add code that runs on every request.
- Look for slow database queries, often from related-posts widgets, complex filters or bloated options tables.
- Use object caching (such as Redis or Memcached) if your host supports it, so repeated database results are kept in memory.
- Update PHP to a current version. Newer versions are significantly faster at running the same code.
6. Check your hosting
If you have done everything above and TTFB is still high, the server itself may be underpowered or overcrowded. Very cheap shared hosting can put hundreds of sites on the same machine. Signs to watch for: response times that vary wildly throughout the day, or that stay slow even for cached pages. Moving to a better plan or host can be the right call.
7. Set sensible cache headers
The Cache-Control header tells browsers and CDNs how long they may keep a copy of a response. Pages sent with no-store or no-cache on everything force a full trip to the server every time, even for returning visitors. Static files such as images, CSS and JavaScript can usually be cached for a long time, while HTML pages can often be cached briefly or revalidated. The speed test shows the header your page sends, so you can confirm your caching setup is doing what you intended.
8. Choose the right server location
Physical distance adds unavoidable delay. If most of your visitors are in India, a server in the United States adds latency to every request. Host your site, or at least your CDN edge, close to your audience.
A realistic order of work
| Step | Effort | Typical impact |
|---|---|---|
| Page caching | Low | Very high |
| Remove redirect hops | Low | Medium |
| Compression | Low | Medium |
| CDN | Low to medium | Medium to high |
| Plugin and query clean-up | Medium | Medium |
| PHP upgrade | Low to medium | Medium |
| Better hosting | Medium | High, if hosting is the bottleneck |
When the site is slow only sometimes
If your site is fast most of the time but occasionally crawls or times out, the cause is usually resource limits: traffic spikes, background tasks such as backups or scheduled jobs, or other sites on the same server. Check whether slow periods line up with backups or cron jobs, and whether your host reports CPU or memory limits being hit. If the site sometimes fails completely, our guide on whether your website is down or it is just you helps you tell a local problem from a real outage.
Fast from the first byte
Visitors never see your server. They only feel the pause before the page appears, and they notice it every single time. Test your key pages with the Website Speed Tester, work through the checklist from the top, and re-test after each change. A few focused improvements, usually starting with caching, are often enough to make your whole site feel quicker.
