Support Forums

"Slow" TTFBs over 500ms on requests?


I’ve recently created a free Netlify account to test out the service with a couple of old static sites I host for friends. I also run an web agency, so trialling the platform for potential paying clients to be using.

I uploaded my 2 basic sites to Netlify and every worked smoothly. There isn’t any build process for these, as these sites are just static files to begin with anyway.

DNS is with Cloudflare, but I disabled the proxy feature and it passes straight through to Netlify’s CNAMEs on both www and the root domains.

I was expecting pages to be loading with lightning fast TTFBs of well under 50ms, given that they are literally just static HTML with no dynamic components.

But instead I’m seeing TTFB’s well above this - 300-600ms.

It’s not hugely slow but considering I’ve got servers that are achieving < 50ms response times running dynamic Wordpress, this seems off to me.

Is my expectation too high, or is there something potentially wrong?

An example instance name is beautytherapyherts.netlify.app.

I’m measuring the TTFB using Chrome Dev tools, with cache and javascript disabled. I’ve also measured with GTmetrix. Similar results across both.


1 Like

Experiencing the same on my side.

Might be that they still have performance issues:

hi there, @nesvarbu, i actually responded to your other thread already, but the advice here is the same - can you both please tell us which sites this is regarding, and try to capture a HAR file so we can take a closer look?


many thanks.

oh, and thanks for sharing the link to our status page - that is, in fact, the single source of truth on any service concerns, so it’s worth checking if you are not sure if we’re having problems :white_check_mark:

Hi Perry

An example instance name is https://beautytherapyherts.netlify.app

It also affects https://stefanracing.netlify.app

You can get the HAR file from the Waterfall tab on the below URLs (GTmetrix reports on both sites).

These ones weren’t quite over 500ms, but still way slower than expected for static file serving. Like I mentioned, I’ve got Wordpress sites that achieve under 50ms TTFB. I also have standard hosting servers returning static assets often less than 20ms (TTFB).



hey matt, thanks for creating this~ we haven’t forgotten, we will take a look!

Any news on this? Still seems to be a problem from my end.

hi there, thanks for checking in. We are still investigating what exactly is causing the issue, and we hope to have more information for you soon. We won’t forget, promise!

Thanks for your patience while I took a look, Matthew. As far as I can tell, over the past 30 days, we’ve served about 78 total requests for those two sites together, at an average response time just under 170ms (thats from our server receiving the request, to sending the last byte). No single request took us more than 1s to serve. That feels pretty good to me, especially consider that our CDN caches opportunistically, so for sites like yours that are rarely used, we’ll always have to fetch the content from our backing store in the US to populate the cache on the CDN node you are talking with during the request cycle.

We will not be as fast as some hosting solutions, particularly if you rarely request assets so they are rarely in cache. Busier sites do better on our CDN for getting response time down under 100ms.

Thanks for the response.

Yes, those sites are low traffic. I was just testing it out with a couple of tiny little sites I look after. Does seem as though the caching policy is likely to be the culprit. How long does the cache last on the edge before it has to be fetched again from your backing store origin?

Depends on a lot of things; there is no explicit expiry time. As a general algorithm, it’s the case that smaller, more frequently requested assets stay in cache longer. Larger ones are evicted sooner (or not cached at all, north of 10MByte). I wouldn’t expect an asset requested only once to still be there a day later, but it might not even be there 10 minutes later since you are sharing cache space with millions of other sites on our non-enterprise ADN. On the enterprise ADN things look different since there are only thousands, not millions, of sites, so cache contention is MUCH lower.

Hi… I am facing this same issue. My website is taking extra 600 to 700ms because of Netlify’s “Waiting time”. I have compared to google CDN solutions and all requests work under 10ms. We could deliver our site to the customer in under 500ms total (css, fonts, images, js).

There is an urge to implement faster websites. Google is prioritizing WebVitals which are mostly about loading speeds. Is it so hard to tend to this need? What is holding Netlify back?

hey @gabrielfengel ,

there are actually a couple of reasons why some sites can report back a slow TTFB - incorrect proxy settings, for example, are a current culprit.

Can you tell us a bit more info please? such as which site this is regarding and whether or not you are proxying to netlify as described here?


Hi @perry

Our website is not proxying. Our domain www.seguroviagem.srv.br is registered at Brazilian’s registro.br that reference directly netlify’s dns and from there direct to netlify.app link.

We’ve already tweaked all we could figure out on pagespeed and gtmetrix. Can you help us?

hi there, thanks for those details. we haven’t forgotten about you - let me try and get some more :eyes: on this.

Hi, @gabrielfengel. We have sent you an email to the email address associated with your Netlify account, and we’ll communicate with you through that email to continue resolving this issue.

Also, please let us know with a reply here if you don’t receive a message from us.

Hi @luke I’ve responded your e-mail. We still have inconsistency on TTFB

Hi there, @gabrielfengel :wave:

Thanks for following up. I want to assure you that we have your helpdesk ticket and a Support Engineer will respond to it as soon as we are able to. Stay tuned!

Hello @hillary! I have not received any response from my e-mails. Could you confirm that you received?

Hello there, @gabrielfengel :wave:

Thanks so much for following up! I assure you we have received your email and that our Support Engineers are aware of your questions. We will respond as soon as we are able to.