TTFB Checker: How to Measure Time to First Byte and Fix a Slow Server Response

CodexFuse Team · 2026-11-07T04:05:10.972Z · 11 min read min read

A TTFB checker measures time to first byte — the wait before your server starts responding. Learn good scores, causes of slow TTFB, and fixes.

A TTFB checker measures time to first byte — the gap between a visitor requesting your page and your server sending back the first byte of data. It is the single clearest number for answering one question: is my server slow, or is something else slow? A high TTFB points at hosting, server configuration, or an overloaded backend. A low TTFB with a slow-feeling site points at images, scripts, or third-party code instead. Knowing which one saves hours of fixing the wrong thing.

TTFB matters because every other part of loading waits for it. The browser cannot render anything, fetch CSS, or start JavaScript until that first byte arrives. Google treats server response time as a ranking and user-experience signal, and visitors feel the delay directly — a page that takes two seconds just to start responding feels broken, even if the rest loads quickly. This guide explains what TTFB is, what good numbers look like, how to measure yours with a free TTFB checker, and what to fix when the number is too high.

What Is TTFB, Exactly?

Time to first byte is the time from the moment a browser sends an HTTP request until it receives the first byte of the response. It covers DNS lookup, the TCP connection, the TLS handshake, the time the server spends thinking, and the first packet travelling back. It does not include downloading the full page, images, or scripts — only the wait before anything arrives.

Think of it like ordering at a restaurant. TTFB is how long you wait before the waiter acknowledges your order and brings the first item. The total meal time is page load time. A slow waiter ruins the experience even if the kitchen is fast, and a fast waiter cannot save a kitchen that takes an hour. Both numbers matter, but they point at different problems.

What counts as a good TTFB?

Google recommends a server response time under 200 milliseconds, though in practice a TTFB under 600 ms is considered acceptable for most sites, and anything above 1 second needs attention. The table below gives a practical reading of the numbers.

Context matters. A static page served from a CDN can answer in under 100 ms. A WooCommerce checkout or a database-heavy dashboard will naturally take longer. Compare your number against similar sites, not against a static landing page.

How Do You Check TTFB?

You check TTFB by sending a request to a URL and timing how long the first byte takes to come back, using a dedicated checker, your browser's developer tools, or a command-line request. A dedicated TTFB checker is the fastest option: you paste the hostname, run the check, and get a number in seconds with no setup. For a one-off check, browser developer tools work too — open the Network tab, reload, click the first document request, and read the "waiting (TTFB)" figure in the timing breakdown.

Whichever method you use, test the right page. Your homepage is usually cached and fast; a product page, a blog post, or a logged-in dashboard page tells the truer story. Test two or three different URLs, and test more than once — a single reading can be skewed by a cold cache or a momentary spike.

How to use the CodexFuse TTFB checker

The free TTFB checker on CodexFuse keeps the process to two steps:

1. Enter a hostname — type the domain or full URL you want to measure.
2. Check simulated TTFB — run the check and read the result instantly.

There is no software to install and no limit on checks. You will need a free CodexFuse account to use it — sign in once and the tool is ready whenever you need a quick reading.

What Makes TTFB Slow?

TTFB is slow when the server takes too long to produce a response, and the causes fall into a short list. The most common is shared or underpowered hosting: hundreds of sites competing for the same CPU and memory means your request waits in a queue. Next is an uncached dynamic page — every request forces the server to query the database, run PHP or application code, and build the page from scratch. Slow database queries, bloated plugins, and distant servers (a visitor in Lahore hitting a server in Frankfurt) add their own delays, and an overloaded server during traffic spikes makes all of it worse.

• Weak or crowded hosting: the server simply cannot answer quickly because it is oversold or underpowered.
• No page caching: every visit rebuilds the page instead of serving a ready copy.
• Slow database queries: unindexed tables and heavy queries stall the response before it starts.
• Too many plugins or heavy code: each plugin adds work the server must finish before responding.
• Far-away server location: physical distance adds network round-trip time no code can remove.
• No CDN in front: every request travels to the origin server instead of a nearby edge node.

Worked Example: A Slow Online Store, Diagnosed in an Afternoon

Consider a fictional example. Ayesha runs a small online clothing store in Karachi on WordPress and WooCommerce, hosted on a budget shared plan. Customers complain the site feels sluggish, and her bounce rate on product pages has crept up to 68%. She runs the CodexFuse TTFB checker on her homepage and gets 1,850 ms. On a product page it is 2,300 ms. On a plain HTML test page on the same host it is 420 ms.

Those three numbers tell the whole story. The plain page at 420 ms shows the host itself is mediocre but not catastrophic. The jump to 1,850 ms on the homepage and 2,300 ms on product pages shows the slowness is in the application layer — WordPress building pages from scratch on every visit, with no page cache and 34 active plugins, several of which query the database on every load.

Her fix list, in order: enable full page caching (TTFB drops to around 350 ms on cached pages), remove 11 unused plugins, add a database index on the product table, and put a CDN in front of the site. A re-test after the changes shows 320 ms on the homepage and 480 ms on product pages. Total spend: one afternoon and no new hosting bill. If the plain-page test had shown 1,800 ms too, the diagnosis would have been different — the host itself would have been the problem, and no amount of plugin cleanup would have fixed it.

How Do You Fix a High TTFB?

Fix a high TTFB by working through the causes in order of impact, starting with caching, then the database and code, and finally the hosting itself. Caching is almost always the biggest single win on a dynamic site: a cached page can answer in tens of milliseconds because the server does no real work at all. After that, profile slow queries, remove plugins and code you do not need, and keep the server close to your visitors with a CDN.

If the plain-page test is slow too, none of the above will save you — the hosting is the bottleneck, and the honest fix is moving to a better host or a managed setup where someone else tunes the server for you. This is the point where many site owners waste weeks optimising code on a host that cannot go faster.

A practical fix checklist

1. Enable page caching — serve a ready copy instead of rebuilding every page.
2. Use a CDN — answer visitors from a nearby edge location.
3. Clean up plugins and themes — deactivate anything unused; each one costs server time.
4. Optimise the database — index slow queries, clean revisions and transients.
5. Upgrade PHP and the server stack — newer versions answer measurably faster.
6. Move closer to your visitors — pick a server region your audience actually lives near.
7. Change hosting if the baseline is slow — a plain-page TTFB over 600 ms means the host is the problem.

TTFB vs Page Load Time: What Is the Difference?

TTFB and page load time measure different parts of the same journey, and confusing them leads to fixing the wrong thing. TTFB is the wait before the first byte arrives; page load time is the wait until everything — images, stylesheets, scripts, fonts — has finished downloading and rendering. A site with a 200 ms TTFB can still take five seconds to load, and a site with a 900 ms TTFB can feel fine if the rest is light. Use a TTFB checker to judge the server, and a full page speed test to judge the whole experience. If both are bad, fix TTFB first — nothing else can start until the server answers.

What the CodexFuse TTFB Checker Does Not Do

Honest limits matter. The CodexFuse checker gives a simulated TTFB reading for a hostname — it is a quick diagnostic, not a replacement for real monitoring. It does not test from multiple global locations, so it cannot show how your site performs for visitors in other countries. It does not measure full page load, images, or scripts, and it cannot see inside your server to name the slow query or plugin. For those, use your hosting logs, a real-user monitoring tool, or a ping check from different networks alongside it. Treat the checker as the first five minutes of diagnosis: it tells you whether the server is the problem, and then the deeper tools take over.

Frequently Asked Questions

What is a TTFB checker?

A TTFB checker is a free online tool that measures time to first byte — how long a server takes to start responding to a request for a web page. It helps you tell whether slowness comes from the server and hosting or from the page content itself.

What is a good TTFB score?

Under 200 ms is excellent, 200–600 ms is good for most dynamic sites, and anything above 1 second needs fixing. Static pages on a CDN should be well under 200 ms, while database-heavy pages can legitimately sit in the 300–600 ms range.

Does TTFB affect SEO?

Yes, indirectly but genuinely. Google uses page experience signals in ranking, and a slow server response delays everything else — rendering, interactivity, and Core Web Vitals. A high TTFB also increases bounce rates, which hurts traffic even when rankings hold.

Why is my TTFB high but my page loads fast?

That combination is unusual but possible: a slow server start followed by a very light page. More often the reverse is true — a fast TTFB with a slow-feeling page means images, scripts, or third-party code are the real problem, not the server.

Is the CodexFuse TTFB checker free?

Yes, it is free and unlimited. You need a free CodexFuse account to sign in, and then you can check as many hostnames as you like with no usage limits.

How often should I check TTFB?

Check after any hosting change, theme or plugin update, and traffic spike, and monthly as routine maintenance. TTFB creeps up silently as plugins accumulate and databases grow, so a regular check catches the drift before visitors notice.

Stop Guessing — Measure Your Server Today

TTFB is the fastest honest answer to the question every site owner asks: is my server the problem? Run the free checker on your homepage and one product or article page, compare the numbers against the 600 ms line, and work the fix list in order — cache first, then code, then hosting. If the plain-page test shows your host itself is slow, stop optimising around it. Move your hosting and email to CodexFuse: fully managed servers, caching and tuning handled for you, on pay-as-you-go credits with no subscriptions and no server babysitting. Check your TTFB now, and if the number is over a second, make the move this week — your visitors have already been waiting long enough.