"Slow" TTFBs over 500ms on requests?

Hi

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.

Matt

1 Like

Experiencing the same on my side.

Might be that they still have performance issues:
https://www.netlifystatus.com/

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?

https://toolbox.googleapps.com/apps/har_analyzer/

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).

Thanks

Matt

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.