Free · Fast · Privacy-first

Check TTFB Online (Time to First Byte)

Time to First Byte (TTFB) measures how long it takes your server to start responding after a browser requests a page, and it sets the ceiling for every other performance metric you might care about.

⚡

TTFB measurement to millisecond precision

🔒

Diagnosis guidance for high TTFB

✨

Comparison against good/poor thresholds

⚡

No sign-up required

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this Website Speed Test to your website

Drop the Website Speed Test into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Website Speed Test by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/web-tools/website-speed-test?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="Website Speed Test by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

TTFB: The Server-Side Performance Metric That Determines Your Performance Ceiling

Time to First Byte (TTFB) is the time between a browser sending an HTTP request and receiving the first byte of the server's response. It encompasses three distinct phases: DNS lookup time during which the domain is resolved to an IP address, TCP connection time during which the connection is established and the SSL handshake completes for HTTPS, and server processing time during which your server generates and sends the response. Of these, server processing time is the phase directly under your control and the one that varies most widely between sites. Google's Core Web Vitals threshold for Good TTFB is under 800ms; the web.dev documentation suggests targeting under 200ms for optimal performance on competitive pages. A TTFB above 1800ms is classified as Poor and effectively guarantees that LCP will also fall outside the Good range no matter how well the front-end is built.

The primary cause of high TTFB is absent or misconfigured server-side caching. When a CMS such as WordPress generates a page, it typically runs PHP, queries a MySQL database, and assembles the HTML, a process that takes 200ms to 2000ms depending on query complexity and server speed. Full-page caching stores the generated HTML as a static file and serves it directly without running PHP or querying the database, reducing TTFB from seconds to milliseconds with no functional trade-off for content that does not change on every request. WP Rocket and W3 Total Cache implement page caching for WordPress. For non-WordPress sites, Varnish Cache, Nginx FastCGI caching, or object caching with Redis accomplish the same result. On CDN-managed sites, edge caching at the CDN level using a Cloudflare Cache Everything rule, for example, reduces TTFB further by serving responses from the CDN edge node nearest to each user.

TTFB is the performance ceiling for every other metric. LCP cannot begin until after TTFB completes, FCP cannot happen before TTFB, and images cannot be downloaded before TTFB returns the HTML that references them. Every millisecond of TTFB adds directly to every downstream metric in a strict one-for-one relationship. A site with a 2-second TTFB cannot achieve a 2-second LCP regardless of how well-optimised its front-end is, because the browser has not yet received the document that tells it what to render. This is why TTFB optimisation should always come before image compression, JavaScript deferral, or any other front-end work. Front-end optimisations applied to a site with a slow TTFB produce smaller gains than the same optimisations applied after caching has reduced TTFB to a healthy range.

Diagnosing high TTFB requires identifying which of the three TTFB phases is consuming the time, because the fixes differ dramatically across phases. If DNS resolution is slow, the answer is moving to a faster DNS provider such as Cloudflare or Route 53. If TCP and SSL setup is slow, the answer is enabling HTTP/2 or HTTP/3, ensuring keep-alive is configured correctly, and using a CDN to terminate TLS closer to the user. If server processing is slow, the answer is caching, database query optimisation, application code profiling, or in extreme cases a hosting upgrade. Tools such as WebPageTest, Chrome DevTools Network panel timing breakdown, and curl with detailed timing flags expose each phase separately so you can target the correct fix rather than blindly trying solutions that address the wrong layer.

web.dev: Time to First Byte (TTFB) Metric web.dev: Optimize TTFB

How to use this tool

💡

Enter your URL to measure TTFB and diagnose server-side performance.

How It Works

Step-by-step guide to check ttfb online (time to first byte):

1
Enter your URL
Paste the URL of the specific page you want to test TTFB for, since TTFB can vary significantly between different page types on the same site. A cached homepage may return in 100ms while an uncached dynamic search results page on the same domain takes 1500ms. Test the page type that matters most for your audience and your revenue, not just whichever page happens to come to mind first when you open the tool.
2
Review the TTFB result
Check the TTFB value against the standard thresholds. Under 200ms is the target for competitive performance and signals an excellent server configuration. Between 200ms and 600ms is acceptable for most sites and unlikely to cause user-visible problems. Above 800ms exceeds Google's Core Web Vitals threshold for Good TTFB and effectively guarantees that LCP cannot reach the Good range without significant front-end gymnastics that should not be necessary.
3
Diagnose based on TTFB cause
High TTFB on a site with no CDN almost always indicates that adding a CDN is the highest-leverage fix available. High TTFB on cached pages, meaning the cache should be serving the response directly, indicates a hosting layer that is slow even when the application is doing minimal work, which typically calls for a hosting upgrade or migration. High TTFB on uncached pages points to investigating database query performance, application code profiling, and server-side caching opportunities to remove the slow generation path entirely.
4
Implement and re-test
After each server-side change such as enabling caching, attaching a CDN, upgrading the hosting plan, or tuning database indexes, re-test TTFB from the same tool to confirm the improvement is real rather than coincidental. Capture the before-and-after numbers in a shared note so the team has a permanent record of what each intervention delivered, and use that record to inform future decisions about where to invest the next round of server-side performance work.

Real-world examples

Common situations where this approach makes a real difference:

Hosting upgrade evaluation

A site owner testing a new managed WordPress host uses the TTFB checker to compare the current host, which shows an 850ms TTFB on a typical content page, against the new host, which shows 95ms TTFB on the identical content. The clear nine-fold improvement provides concrete evidence the upgrade is justified before signing the annual contract, and the numbers transfer directly into the migration business case shown to the finance team for approval. The same comparison post-migration confirms the production environment delivered what the trial promised.

CDN effectiveness verification

A developer enabling a CDN for the first time checks TTFB before and after activation to confirm the CDN is correctly serving cached responses from its edge nodes rather than passing every request through to the origin. TTFB drops from 420ms to 45ms when measured from a geographically distant location, confirming the CDN is working as expected. The developer then deliberately tests an uncached path to verify that pages requiring origin fetch still respond reasonably and that the cache rules are not too aggressive in ways that would break personalised content for logged-in users.

Database query optimisation

An e-commerce developer investigating high TTFB on product category pages uses the TTFB data alongside database query profiling output from the application performance monitoring tool to identify an unindexed database query adding 1.2 seconds to server response time on every category request. Adding the missing index reduces query execution from 1200ms to 8ms, TTFB drops correspondingly, and Lighthouse mobile scores on category pages jump by roughly twenty points without any front-end changes. The fix takes one afternoon and is captured in a runbook so similar issues can be diagnosed faster next time.

When to use this guide

Use this when investigating slow overall load times, when diagnosing server-side performance before optimising the front-end, or when evaluating a new hosting provider.

Pro tips

Get better results with these expert suggestions:

Enable full-page caching as your first TTFB fix

Full-page caching is the single highest-impact TTFB optimisation for CMS-based sites because it stores generated HTML as static files and serves them without running application code or hitting the database. For WordPress, install WP Rocket or W3 Total Cache and configure the cache lifetime to match how often your content actually changes. For custom PHP, Python, or Ruby sites, implement Varnish or Nginx FastCGI caching in front of the application. TTFB reductions from 1500ms to under 200ms are typical and routine after enabling page caching properly.

Use a CDN with edge caching to minimise network latency

Even with fast server processing, network latency between the user and the origin server adds directly to TTFB and cannot be reduced through application optimisation alone. A CDN with edge nodes worldwide reduces this latency to near zero for most users by serving the response from a physically closer location. Cloudflare's free tier can improve TTFB for geographically distant users by 200ms to 500ms simply by serving cached responses from the nearest edge node rather than your origin server, with no configuration beyond pointing your DNS at Cloudflare.

Check for external API calls in your request path

If your server makes external API calls during page generation, for example fetching product data from an external service or loading widget content from a third party, those calls add directly to your TTFB because the user waits for them. Identify the calls using server-side timing headers, application performance monitoring tools, or simple log analysis of the request path. Cache external API responses server-side with a short time-to-live to avoid making live API calls on every page request, while still keeping the data fresh enough for the use case.

Monitor TTFB in Google Search Console crawl stats

Google Search Console's Crawl Stats report under Settings shows the average server response time experienced by Googlebot itself, which is the TTFB that matters for crawl budget efficiency on large sites. A slow TTFB in crawl stats indicates Googlebot is experiencing delayed responses, which reduces how many pages it can crawl per day and slows the rate at which new content enters the index. Watch this report alongside your user-facing TTFB to spot situations where one looks healthy while the other is silently struggling.

Target TTFB under 200ms for good performance

Google's Core Web Vitals guidelines consider a TTFB under 800ms as "Good", but for a competitive website, targeting under 200ms gives the best foundation. A 500ms TTFB adds 500ms to every metric including LCP.

TTFB is the foundation of all other metrics

LCP cannot be faster than your TTFB. If TTFB is 1.5 seconds, LCP will be at least 1.5 seconds even with perfect front-end optimisation. Fix server speed first.

Implement full-page caching before other optimisations

For WordPress and CMS sites, a full-page caching plugin (WP Rocket, W3 Total Cache) can reduce TTFB from 1–2 seconds to under 100ms by serving cached HTML instead of processing PHP/database on every request.

FAQ

Frequently asked questions

TTFB measures the time between a browser sending an HTTP request and receiving the first byte of the server's response, encompassing DNS resolution, TCP connection, SSL handshake, and server processing time as a single end-to-end duration. Good TTFB is under 800ms according to Google's Core Web Vitals threshold, while web.dev recommends targeting under 200ms for optimal performance on competitive pages. TTFB above 1800ms is classified as Poor and signals fundamental server-side issues that no amount of front-end optimisation can compensate for. TTFB is the performance baseline that determines the ceiling for all other metrics including LCP, FCP, and TTI.

The most common causes are absent page caching, where the server runs database queries and application code on every request even when the response could be served from a cached copy; slow hosting such as shared plans with insufficient CPU and memory resources during peak periods; complex or unoptimised database queries that run synchronously inside the request path; external API calls that block page generation while waiting for third-party services to respond; and geographic distance from the origin server without a CDN to terminate connections closer to users. Enabling full-page caching addresses the first cause and is the fastest TTFB fix for most CMS-based sites.

The five highest-leverage TTFB fixes in rough order of impact are to enable full-page caching using WP Rocket for WordPress or equivalent server-side caching for other platforms, to add a CDN with edge caching such as the Cloudflare free tier, to upgrade from shared hosting to VPS or cloud hosting if the current plan is starved of resources, to optimise database queries using indexing and query result caching, and to cache external API responses server-side so live API calls do not block page generation. These five fixes resolve the majority of high-TTFB cases in production, and they should be tried roughly in that order because each one is easier to implement than the one before it.

Google's threshold for Good TTFB in its Core Web Vitals guidance is under 800ms, and pages exceeding that threshold are flagged in Search Console as having a Page Experience issue. The web.dev documentation recommends targeting under 200ms for optimal performance. From a practical SEO standpoint, achieving under 200ms TTFB gives Googlebot fast crawl access to your pages, helps keep LCP comfortably under the 2.5-second threshold, and signals a well-optimised server configuration to Google's crawlers. Pages with TTFB under 200ms also tend to perform well on Lighthouse Performance scores because the server-side ceiling does not constrain the achievable front-end optimisations.

TTFB is not a direct ranking signal in its own right, but it strongly affects LCP which is, so the practical effect on rankings is real even when the chain of causation passes through an intermediate metric. Since LCP cannot complete before TTFB, a high TTFB makes achieving Good LCP under 2.5 seconds physically impossible for many pages regardless of front-end work. Additionally, Googlebot's crawl efficiency is directly affected by TTFB: slow-responding servers reduce the number of pages Googlebot can crawl per day within its allocated budget, which slows indexation of new and updated content on large sites with many URLs to cover.

Several methods produce reliable TTFB measurements. Google PageSpeed Insights shows TTFB in its timing breakdown alongside other Core Web Vitals. WebPageTest provides the most detailed view, breaking down DNS, connection, SSL, and server processing time separately in its waterfall view. Chrome DevTools Network tab shows TTFB for each request when you hover over any request in the Timing column. The curl command line tool with timing flags such as curl -o /dev/null -s -w '%{time_starttransfer}' URL provides a quick check from any terminal. Google Search Console Crawl Stats shows TTFB as Googlebot experiences it, which is what matters for crawl efficiency.

TTFB measures when the server starts sending a response, while FCP (First Contentful Paint) measures when the browser first renders visible content from that response. The gap between TTFB and FCP is spent downloading HTML, parsing it, discovering and downloading CSS and other render-blocking resources, and then rendering the first piece of content to the screen. TTFB is always the first metric in the timing chain because nothing can happen before the server responds, and FCP follows after the browser has received and processed enough resources to begin rendering. Improving TTFB improves FCP one-for-one, but FCP can still be slow even when TTFB is fast if the front-end pipeline is poorly configured.

TTFB varies between consecutive tests for several reasons that are usually benign rather than indicating a problem. Server load fluctuates moment to moment as other requests arrive and depart, the database may be running a maintenance job, the CDN cache may be warm on one test and cold on another, and the network path between the test server and your origin may shift as routers update their tables. Modest variation of 50ms to 200ms between runs is normal. Variation larger than that, particularly when it crosses the 800ms threshold randomly, indicates a real underlying problem worth investigating with deeper server-side monitoring.

Static sites typically have excellent TTFB by default because no application code runs on the server during a request and the response is read directly from disk or memory. However, TTFB for static sites can still degrade if the hosting provider is slow, if HTTPS is misconfigured causing slow SSL handshakes, or if the static files are served from a single origin without CDN coverage for geographically distant users. For static sites, the main TTFB lever is adding a CDN such as Cloudflare or Netlify's built-in edge network to minimise network latency, after which TTFB usually settles below 200ms globally without further intervention.

Shared hosting can deliver good TTFB if the host is well-engineered, the site is not resource-intensive, and full-page caching is enabled to bypass application code on most requests. Many sites on shared hosting achieve TTFB under 300ms thanks to caching plugins that serve responses from static cache files before the host's PHP layer is invoked. However, shared hosting becomes a TTFB bottleneck during traffic spikes, when the cache misses, or when the database is shared with noisy neighbours running heavy queries. If TTFB is consistently slow even with caching enabled, the host itself is the limiting factor and a migration to managed hosting or a VPS is the appropriate next step.