Time to First Byte, or TTFB, is one of those metrics that does not get the attention it deserves. People talk a lot about page load times, image optimization, and caching. TTFB is upstream of all of that. If your server is slow to respond, no amount of front-end work fixes it.
TTFB measures how long it takes for the browser to receive the first byte of data from your server after making a request. It is the foundation that everything else builds on. A slow TTFB means a slow site, no matter how well-optimized everything else is.
This piece covers what TTFB is, why it matters, what causes a slow TTFB, and how to fix it.
What TTFB Actually Measures
TTFB is the time between the browser sending a request and the server responding with the first byte of data. It breaks down into three parts.
DNS Lookup
The browser has to figure out the IP address of the server. The DNS lookup typically takes 20 to 120 milliseconds depending on the DNS provider and if the result is cached.
TCP Connection
The browser establishes a connection to the server. This includes the TCP handshake and, for HTTPS sites, the SSL handshake. Combined, this is usually 100 to 300 milliseconds.
Server Processing
The server processes the request and starts sending the response. This is where the variation gets wide. A static file might take 5 milliseconds to start sending. A complex database-driven page might take 2,000 milliseconds.
The total of these three steps is your TTFB. Google considers a good TTFB to be under 200 milliseconds. Up to 600 milliseconds is acceptable. Anything over that is slow.
Why TTFB Matters
The metric matters for reasons that show up across the business.
SEO Implications
Google uses page speed signals in ranking, and TTFB is one of those signals. Sites with slow TTFB consistently rank lower than sites with fast TTFB, all else being equal.
More directly, Core Web Vitals like LCP (Largest Contentful Paint) include TTFB as part of their measurement. If your TTFB is slow, your LCP cannot be fast. And LCP is one of the metrics Google uses to evaluate page experience.
Conversion Impact
Visitors do not wait. Studies have shown that conversion rates drop measurably with each additional second of load time, and TTFB is part of that load time. A page that delivers its first byte in 200 milliseconds feels fast. A page that takes 2 seconds feels broken.
Crawl Budget
Google’s crawler has a limited amount of time to spend on your site. If pages take a long time to respond, the crawler visits fewer of them per session. For larger sites, slow TTFB can mean Google never finds large portions of your content.
Foundation for Everything Else
Caching, CDNs, image optimization, code splitting. All of these are good practices, but they work on top of TTFB. If your TTFB is 2 seconds, your fastest possible page is still 2 seconds plus whatever else takes time. Fixing TTFB is foundational.
What Causes Slow TTFB
The causes break down into a few main categories.
Slow Hosting
The server hardware and software underneath your site is the biggest single factor. Cheap shared hosting often produces slow TTFB because the server is overloaded with too many sites, the hardware is old, or the configuration is not tuned.
A site on a slow shared host might have a TTFB of 1,000 milliseconds. The same site moved to a faster host might drop to 200 milliseconds without changing anything else.
Slow Database Queries
For dynamic sites (WordPress, e-commerce, anything with a backend), the database is often the bottleneck. Slow queries, missing indexes, bloated tables, and inefficient ORM-generated queries all add to TTFB.
A WordPress site with a large posts table and no caching can spend half a second on database queries alone.
Heavy Backend Code
PHP, Python, Ruby, Node.js. Whatever runs your site has to execute before the server can respond. Heavy frameworks, inefficient code, and lots of plugins all add to processing time.
WordPress sites with 30+ plugins often have slow TTFB because every plugin adds something to every request.
No Caching
Without caching, the server does all the work from scratch on every request. With caching, the work happens once and the result gets reused.
The difference is huge. A page that takes 800 milliseconds to generate from scratch might serve in 20 milliseconds from cache.
Long DNS Lookup
A slow DNS provider can add 100+ milliseconds to TTFB. Some hosting companies bundle DNS service that is slower than what you would get from a dedicated DNS provider.
Distance from Server
The physical distance between your server and your visitor affects TTFB. A visitor in Singapore loading a site hosted in Virginia has to wait for data to cross the ocean and back.
Light travels fast but not instantly. The trip itself adds latency that no amount of optimization can avoid without moving the server or adding a CDN.
SSL Configuration
A poorly configured SSL setup can add 100 to 300 milliseconds to the connection time. Older SSL versions, missing OCSP stapling, or certificate chain issues all add overhead.
How to Measure TTFB
You cannot fix what you do not measure. A few tools give you the data.
Chrome DevTools
Open the Network tab in Chrome DevTools, reload your page, and look at the request for the HTML document. The “Waiting (TTFB)” line shows the TTFB for that request.
This is the quickest way to see TTFB for your own site as you browse it.
WebPageTest
WebPageTest gives you detailed TTFB measurements from multiple global locations. It shows the breakdown by stage (DNS, connect, SSL, server processing) so you can see exactly where the time goes.
This is the most useful tool for diagnosing TTFB issues because it shows what is slow, not just that something is slow.
GTmetrix
GTmetrix reports TTFB as part of its broader performance analysis. The free version covers most needs.
PageSpeed Insights
Google’s tool shows server response time as part of its analysis. The data is less detailed than WebPageTest but it is tied directly to what Google measures for ranking purposes.
Curl from the Command Line
For technical users, curl is the most direct way to measure TTFB. The command curl -w “TTFB: %{time_starttransfer}\n” -o /dev/null -s https://yoursite.com gives you a clean TTFB measurement without browser overhead.
How to Reduce TTFB
The fixes break down into a few main categories. Most sites benefit from working through them in order.
Upgrade Your Hosting
If you are on slow shared hosting, no amount of optimization will give you a great TTFB. The server itself is the bottleneck.
Look for hosts with NVMe storage (fast disks), modern processors, sensible resource limits, and a track record of good TTFB in benchmarks. Premium managed WordPress hosts like Kinsta, WP Engine, and SiteGround consistently produce better TTFB than budget shared hosts.
For non-WordPress sites, look at hosts that run modern web servers (LiteSpeed, Nginx) and tune their stacks for performance.
Add Server-Side Caching
Server-side caching cuts TTFB more than anything else for dynamic sites. With caching, the heavy work of generating a page happens once and the result gets served from a cache for subsequent requests.
For WordPress, options include built-in caching at hosts like Kinsta, plugins like WP Rocket and LiteSpeed Cache, and external solutions like Varnish.
The improvement is dramatic. A page that takes 800 milliseconds to generate might serve in 20 milliseconds from cache. The difference is the difference between a slow site and a fast one.
Add Object Caching
Object caching saves the results of expensive operations (database queries, API calls) so they do not have to be repeated. Redis and Memcached are the two common object caches.
For database-heavy applications, object caching can cut TTFB by 200 to 500 milliseconds.
Optimize Your Database
For dynamic sites, the database often holds the answer to slow TTFB. Add indexes to common queries. Remove old data you do not need. Optimize tables that have accumulated overhead. Replace slow plugins with faster alternatives.
For WordPress specifically, plugins like WP-Optimize can clean up the database. For more advanced work, you may need a developer to look at slow queries directly.
Use a CDN
A CDN can reduce TTFB for visitors who are far from your server. The CDN caches static assets at edge locations close to the visitor, cutting the physical distance the data has to travel.
For dynamic content, modern CDNs like Cloudflare also offer features like “Cache Everything” that can cache full HTML pages at the edge, dramatically cutting TTFB for cached pages.
Switch to a Faster DNS Provider
If your DNS provider is slow, switching can shave 50 to 150 milliseconds off TTFB. Cloudflare DNS, AWS Route 53, and DNSimple are all fast options.
The switch is free or low-cost and produces measurable improvement.
Use HTTP/2 or HTTP/3
Newer HTTP versions are faster than HTTP/1.1. HTTP/2 has been standard for years. HTTP/3 (which runs on QUIC instead of TCP) is newer and even faster in many cases.
Most modern hosting platforms support HTTP/2 by default. HTTP/3 support varies. If your host does not support HTTP/2, the host is behind the times.
Optimize SSL Configuration
Make sure SSL is configured well. Enable OCSP stapling. Use a modern certificate. Use TLS 1.3 if your platform supports it. Use ECC certificates instead of RSA where possible.
Most hosts handle this automatically with Let’s Encrypt or similar setups. If you manage your own SSL, double-check the configuration with a tool like SSL Labs.
Reduce Backend Work
For custom applications, look at what your code is doing on every request. Are you making API calls that could be cached? Are you doing complex calculations that could be precomputed? Are you loading data you do not actually need?
Code-level optimization is harder than configuration changes, but it produces real results for sites with custom backends.
Geographic Server Placement
If your audience is concentrated in one region, host your server in that region. A site that serves mostly European visitors should host in Europe. A site that serves mostly Australian visitors should host in Australia.
The physical distance affects TTFB in ways that other optimizations cannot fix. Moving the server closer to the audience can drop TTFB by 100 milliseconds or more for non-cached requests.
How Much Can You Improve TTFB
The answer depends on where you are starting and how much work you are willing to do.
A site on slow shared hosting with no caching might have a TTFB of 1,500 milliseconds. Moving to a faster host and adding caching can drop it to 100 milliseconds. The improvement is dramatic.
A site already on a good host with basic caching might have a TTFB of 400 milliseconds. Optimizing further might drop it to 150 milliseconds. The improvement is real but smaller.
A site already on a premium host with full caching might have a TTFB of 100 milliseconds. Further optimization might drop it to 50 milliseconds. The improvement is small at this point because you are near the floor.
Diminishing returns are real. The first round of optimization produces the biggest gains. Each subsequent round produces smaller gains. For most sites, getting under 300 milliseconds is achievable and worthwhile. Getting under 100 milliseconds takes more work and may not be worth it for every site.
Closing Thoughts
TTFB is the foundation of site speed. You cannot have a fast site with a slow TTFB. Everything else you do to optimize sits on top of how fast the server responds.
The good news is that TTFB is improvable. Better hosting, server-side caching, database optimization, and CDN use can drop a slow TTFB into the fast range. The improvements are measurable and they show up in rankings, conversions, and user experience.
If your TTFB is over 600 milliseconds, fixing it should be one of the highest priorities for your site. The work is concrete, the results are measurable, and the impact is real. Start with hosting and caching. Add object caching and database optimization. Add a CDN. Each step produces gains, and the cumulative effect is dramatic.
Sites that take TTFB seriously load fast and rank well. Sites that ignore it spend years wondering why their other optimizations are not producing results. The bottleneck is at the server. Fix that first.