In terms of SEO, which is more important? Time to First Byte or page load speed?

I ask because with Cloudflare our TTFB is 25% faster than without, but the time to fully load the page and its resources is 5.5s instead of 4s.

  • 2
    What is "page load speed"? Is that the time to load just the HTML page? The time to fully load the page and its resources? The time to the "onload" event? Something else? Commented Nov 30, 2021 at 10:41
  • 1
    How do better metrics like "Largest Contentful Paint" (LCP) and "First Input Delay" FID compare with and without Cloudflare? web.dev/vitals Commented Nov 30, 2021 at 10:45

1 Answer 1


Only page load speed, not TTFB, is directly taken into account by Google's Core Web Vitals for ranking, and thus directly affects a page's SEO. A slow TTFB can certainly lead to slow page load speed which in turn lead to poor SEO, but page load speed is always the final metric you should measure in terms of SEO consequences. In other words, TTFB can be an actionable root metric, but it is important to SEO only to the extent to which it affects page load speed.

Though a fast TTFB is generally a sign of a well-optimized website, I would caution against overly relying on it for measuring page speed and the SEO impact thereof. According to CloudFlare, TTFB is "not a significant metric", and indeed some server settings that increase page load speed and thus improve user experience, such as gzip/brotli compression, can have a negative effect on TTFB. CloudFlare concludes that TTFB is "almost useless":

From the end user perspective TTFB is almost useless. In this (real) example it's actually negatively correlated with the download time: the worse the TTFB the better the download time.

Stop worrying about Time To First Byte (TTFB) - CloudFlare

If you're specifically optimizing for SEO over user experience, then I still recommend starting out by focusing on the more important metrics that are downstream from TTFB, such as Largest Contentful Paint and First Input Delay. Google uses Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift as part of its ranking algorithm. It doesn't seem that TTFB is important enough for them to mention, or used for ranking in a direct way. If you determine that your LCP and FID measures are being negatively affected by slow TTFB, then by all means take measures to improve your TTFB, but TTFB is not a metric that Google uses directly.

It could be that improving your TTFB improves your LCP/FID significantly, or the cause of your slow LCP/FID could be something other than a slow TTFB, like high page weight, slow script execution, or asset delivery waterfalls.

So the answer to your question in short is that while a slow TTFB can very much slow down page load speed, only the page load speed itself matters for ranking purposes, TTFB is not taken into direct account.

  • 3
    I'd take CloudFlare's TTFB advice with a grain of salt. I think of TTFB as the time it takes your server to "think" about the request and formulate a response. There are often big improvements in performance from performing fewer DB queries or adding server side caching that will drastically lower TTFB. Cloudflare is correct that isn't directly what users care about, and that it shouldn't be gamed by disabling compression, but they are wrong that you shouldn't care about whether your server is taking too long to think about each request. TTFB is often the most actionable performance metric. Commented Nov 30, 2021 at 16:55
  • 1
    uh... Would it be shocking for anyone to realize that TTFB is a very basic part of LCP/FID/any other top-level vanity metric you want to make up? If you're not a technical person, you would run to your FE devs screaming that LCP is low. They will debug it and then go to the backend team asking to improve TTFB. Also looks like CF tries to excuse their 10-second delay. I think they do it only on the first hit or something. You would notice otherwise. And users do care about TTFB a lot. It's literally the time they spend waiting. This answer is misleading.
    – BNazaruk
    Commented Nov 30, 2021 at 22:15
  • @BNazaruk I've edited my answer to soften the wording and make it less opinionated. There are lots of things besides TTFB that could cause a delayed LCP and FID, so I do think that debugging should generally start with the frontend. If slow backend response is found to be the culprit, then of course you go to the backend team. But in a lot of cases poor page load speeds are because the web page weighs way too much, or the JS waterfalls, or asset delivery is otherwise improperly optimized, and LCP/FID are going to catch those causes of bad SEO that TTFB will miss. Commented Dec 1, 2021 at 0:04
  • Your answer is still misleading. You keep misunderstanding that TTFB is like the first floor of a skyscraper. No matter height of which floor (from the ground) you're measuring, the first floor will inevitably be a part of it. Therefore, making sure it's optimal becomes the most important thing if you compare it to other floors that may not even be there. If all the rest are equal, then TTFB is the most important element. And it does not mean that others can be ignored. No. Others may have issues. No one argues about where the debugging should start. To find a TTFB issue, we have to debug FE.
    – BNazaruk
    Commented Dec 1, 2021 at 0:12
  • 1
    @BNazaruk I disagree that if all the rest are equal, TTFB is the most important element. I have seen just as many LCP/FID, and thus SEO issues that stem from page weight rather than TTFB. It doesn't matter much if you reduce TTFB from 1000ms to 200ms if your page has 50MB of images on it, which I have seen on multiple occasions. If TTFB is one floor of a skyscraper, the other floors are equally important. Commented Dec 1, 2021 at 0:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.