By Hridoy Ahmed | Last updated: October 2026 | 9 min read
Short answer: TTFB (Time to First Byte) is how long a browser waits for the first byte of your page after asking for it. Google’s web.dev says most sites should aim for 0.8 seconds or less. To reduce TTFB on WordPress, start with good hosting, then add page caching, use a CDN, run a supported PHP version, and remove slow plugins, queries and redirects.
In this guide
- What TTFB is
- What is a good TTFB?
- How to measure it
- Common causes on WordPress
- How to reduce TTFB
- FAQ
What TTFB is
TTFB measures the time from when a browser starts to request a page until the first byte of the response arrives. According to web.dev, it includes redirect time, connection setup and the wait for the server’s response. On WordPress, the slow part is often the server building the page: running PHP and asking the database.
TTFB comes before every other speed metric. A high TTFB adds delay to First Contentful Paint and Largest Contentful Paint.
What is a good TTFB?
web.dev gives a rough guide: 0.8 seconds or less is good, more than 1.8 seconds is poor, and anything in between needs improvement.
TTFB is not one of the Core Web Vitals. web.dev says it is not essential to have an excellent TTFB, as long as it does not make it hard to score well on the metrics that matter. So use TTFB as a diagnostic: when LCP is slow, check whether the server is the cause. See how to improve LCP, INP and CLS on WordPress.
How to measure it
- PageSpeed Insights: it shows TTFB in the field data when enough real-user data exists. Field data shows what real visitors experience.
- Chrome DevTools: open the Network tab, click the first request (your page) and read the waiting time for the server response. This is lab data.
- Test more than once. The first visit may be slower than later cached visits. Test a cached page and an uncached page, such as a page with a random URL parameter, to see the difference.
- Test from different places. If visitors are far from your server, TTFB can be high for them even when it is fine near the server.
Lab and field numbers will differ. Use field data to see the real problem, and lab data to test fixes.
Common causes on WordPress
- Slow or overloaded hosting: weak servers, shared servers under heavy load or far from your visitors.
- No page caching: WordPress builds every page from scratch for every visit.
- Heavy plugins and themes: some run many database queries or remote requests on every page.
- Slow database queries: large tables, unindexed queries or too much old data.
- Old PHP version: a version that is not supported or is slower than current ones.
- Redirect chains: http to https to www to a final URL adds time before the page even starts.
- No CDN for far-away visitors: every request has to travel to the origin server.
- Pages that cannot be cached: logged-in users, carts and checkouts.
How to reduce TTFB
Work in this order. Test after each change so you know what helped.
1. Check your hosting first
web.dev says hosting is the first thing to consider before other optimizations. If your server is slow or overloaded, other fixes only go so far. Ask your host about server location, resources and caching support. See why your WordPress site may be slow.
2. Turn on page caching
Page caching saves a finished copy of a page, so the server does not rebuild it for every visitor. Many hosts have server-level caching. If not, use one caching plugin, not several. See my guide to the best caching setup for WordPress.
3. Use a CDN
A CDN serves content from locations closer to visitors. web.dev notes that users far from your origin server may still see high TTFB even if your backend is well optimized. A CDN that can cache full pages helps most.
4. Use a supported PHP version
Ask your host which PHP versions they offer. Move to a currently supported version, and test your theme and plugins on a staging copy first.
5. Audit plugins and queries
Disable plugins one at a time on a staging site and compare TTFB. A query profiling tool can show which plugin or query is slow. Remove plugins you do not need.
6. Clean up the database
Remove old revisions, expired transients and spam only after a backup. Do not run cleanup tools on a live site without a restore point.
7. Reduce redirects
Link to the final URL. Make sure http goes to the final https version in one step.
8. Use an object cache if your host supports it
Object caching stores the results of common database queries in memory. It helps most on dynamic sites such as shops. It needs host support, so ask first.
9. Handle dynamic pages separately
Carts, checkouts and logged-in pages usually cannot be fully cached. Keep these pages light, and avoid heavy plugins on them.
If you want a proper diagnosis with before and after tests, see my speed and performance optimization service.
Common mistakes
- Installing several caching plugins that conflict
- Testing only a cached page and assuming the whole site is fast
- Chasing a perfect TTFB score instead of fixing the pages that feel slow
- Cleaning the database without a backup
- Blaming the theme before checking hosting
- Making many changes at once, so you cannot tell what worked
FAQ
Is TTFB a Core Web Vital?
No. web.dev says it is not a Core Web Vitals metric, but it comes before FCP and LCP, so a high TTFB can make them worse.
What is a good TTFB for WordPress?
web.dev suggests 0.8 seconds or less as a rough guide for most sites. Over 1.8 seconds is considered poor.
Does a CDN reduce TTFB?
It can, especially for visitors far from your server, and most of all if the CDN caches full pages.
Will changing hosting fix a high TTFB?
Often it helps, but not always. Check caching, plugins and queries too, and test before you decide to move.
Want a clear diagnosis of why your site is slow? I test your TTFB, find the cause and fix it with before and after results. See my speed and performance optimization service.
About the author: Hridoy Ahmed is an SEO specialist and WordPress security expert based in Dhaka, Bangladesh. He has 8+ years of experience and works with clients worldwide.