What Is TTFB and Why Does Your Website Seem Slow?

You have high TTFB and don't know who's to blame

You open the website. The browser shows a blank page for a few seconds, and then everything loads at once. The PageSpeed report says your TTFB is 1.8 seconds. The developer says "our server is fast," the hosting manager says "your code has issues," and you're left wondering where to spend your money.

The truth is, both of them might be right. TTFB (Time To First Byte) isn't just the time it takes for the first byte to reach the browser; it's the sum of three separate parts: network time, queue and processing time on the server, and response generation time. If you don't separate these three, any optimization is blind.

This article is written precisely for that moment. Not to define TTFB, but to help you find out where the bottleneck is with a few commands and a clear measurement method, and which optimization actually makes a difference in the user's browser.

Separating network time from server time with one command

The first tool you need is curl. Not PageSpeed Insights, not GTmetrix. Because those show the final result, but here we need the details. Run the following command from a server outside Iran (for example, a VPS in Germany or the Netherlands) on your own website:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://example.com

The output will look something like this:

DNS: 0.042s
Connect: 0.187s
TLS: 0.351s
TTFB: 0.890s
Total: 1.240s

Now interpret the numbers. The gap between Connect and TLS is the time for the security handshake. The gap between TLS and TTFB is what you want: the time the server spent before sending the first byte. If this number is above 0.5 seconds, the problem is with your server or code. If Connect and TLS are high but TTFB is low, the problem is the network path.

One important note: run this test from inside Iran too. A significant difference between the external and internal test results indicates issues with sanctions, filtering, or the quality of international routes. Keep in mind that the result of this test from inside Iran is usually higher due to international internet routes.

Here's where they go wrong: testing from their own system

The most common mistake I've seen is that the website owner runs the test from their own laptop connected to the company's internal network. The result looks great, but a user in Mashhad on mobile internet has a completely different experience. The test should be run from where the real user is. Tools like SEO and webmaster tools usually test from multiple points around the world, but for initial diagnosis, this curl command is enough.

Server time: where the most optimization is possible

Let's say your TTFB is 0.9 seconds, and 0.6 seconds of that is spent on server-side processing. This number means your server works for 600 milliseconds on each request. This isn't unusual for a simple WordPress page without caching. But it's not acceptable either.

The first step is to enable page caching. In WordPress, install a plugin like WP Rocket or LiteSpeed Cache and enable page caching. Then measure TTFB again. If the number drops below 0.2 seconds, the problem was PHP processing and database queries. If not, the culprit is elsewhere.

The second step is to check database queries. If you're using MySQL, run this command in the server terminal:

mysql -u root -p -e "SHOW GLOBAL STATUS LIKE 'Slow_queries';"

If the Slow_queries number is high (more than a few hundred per hour), you need to find the heavy queries. The Query Monitor plugin in WordPress can show you exactly which query is slow and which plugin is to blame.

Don't forget object cache

Page caching only works for guest users. A logged-in user or an active shopping cart doesn't benefit from page caching. For these cases, you need Redis or Memcached. Installing Redis on the server and connecting it to WordPress with a plugin like Redis Object Cache can reduce response time for dynamic requests by up to 70%. I'm saying this number from experience, not from a sales catalog.

Network time: when the problem isn't the server

Now consider the second scenario. Your TTFB from an external test is 0.3 seconds, but from inside Iran it's 1.2 seconds. This means your server is fast, but the network path between the Iranian user and your server has issues. No code optimization will help here.

The solutions fall into two categories. First, using a CDN with presence in Iran or a nearby region (Turkey, UAE). Second, moving the site to a server inside Iran. The choice between these depends on your budget and needs. If your users are mainly in Iran and your site isn't subject to sanctions, an internal server is a better option. If you have an international audience, a CDN with a data center in the Middle East is a more logical choice.

For a more detailed check of your domain's DNS and infrastructure status, you can use domain and DNS technical check. Sometimes the problem is a high DNS TTL that causes users to connect to an old IP.

Browser time: the part TTFB doesn't show

TTFB only measures up to the first byte. But the user doesn't care about the first byte. They're waiting for the full page to render. Between these two points, the browser needs to process the HTML, download and execute CSS and JavaScript, and load images. This part isn't visible in TTFB but is visible in LCP (Largest Contentful Paint).

There are sites with an excellent TTFB of 0.1 seconds but an LCP above 4 seconds. The problem is heavy JavaScript or unoptimized images. For these cases, don't touch TTFB. Instead, optimize images with modern formats like WebP and AVIF or troubleshoot the LCP issue.

A simple metric to diagnose where the problem is: if TTFB is low but the page loads slowly, it's a browser problem. If TTFB is high, the problem is network or server. This simple separation eliminates 80% of the wrong optimization paths.

Which one should you reduce first?

If your TTFB is above 0.8 seconds, reduce it first. Because any other browser-side optimization is built on a slow foundation. If TTFB is below 0.4 seconds, move on to LCP and CLS. I've applied this order on dozens of sites and it has worked.

There are exceptions too. If your site is a web application with heavy interaction and users spend a long time on the page after initial load, optimizing INP (Interaction to Next Paint) might be more important than TTFB. But for 90% of content and e-commerce sites, the rule above holds true.

For a complete review of all speed metrics, read the practical Core Web Vitals guide. Also, if you're just getting started, the complete website speed optimization guide shows the step-by-step path.

A real scenario of a common mistake

A few months ago, I was reviewing a site with a TTFB of 2.2 seconds. The site owner had spent a week optimizing code with no results. The curl test showed that TLS time was about 1.4 seconds. That meant the problem was the security handshake, not the code. Further investigation revealed that the server was using TLS 1.0 with old cipher suites, and some network paths responded to this type of connection with high latency. After upgrading the SSL configuration to TLS 1.3 and enabling OCSP Stapling, TTFB dropped to 0.4 seconds. Without changing a single line of code.

Many people repeat this mistake: they assume high TTFB means bad code. But sometimes it's just a misconfiguration in the web server or SSL.

Frequently Asked Questions

What is a good TTFB for SEO?

Google hasn't announced an exact number, but experience shows that TTFB below 0.2 seconds is excellent, below 0.5 seconds is good, and above 0.8 seconds requires investigation. For Iranian users, considering network conditions, these numbers should be considered about 30% higher.

What's the difference between TTFB and full page load time?

TTFB only measures the time until the first byte arrives. Full load time includes downloading all resources (CSS, JavaScript, images) and the final rendering of the page. A site can have low TTFB and high load time, or vice versa.

Does a CDN reduce TTFB?

Yes, if the problem is the network path. A CDN reduces network round-trip time by placing content closer to the user. But if the problem is slow processing on the origin server, a CDN only hides the issue, and TTFB from the origin remains high.

Why is TTFB different from inside Iran compared to outside?

Due to international internet routes and the lack of direct connectivity with many foreign data centers. This difference can sometimes be up to 5 times. If your users are in Iran, run the test from inside Iran and make decisions based on that.