Consistent 6+ second TTFB on small index.html file

I am seeing also 6+ seconds TTFB.

Is it possible it has something to do with redirects?

On why-bitcoin.rocks I have no redirect and the site loads fast.
On dalliard.ch I have a redirect from the homepage to the default /de/ and the site takes the 6+ seconds to load.

Maybe that helps.

Edit: I can confirm my thesis, I just removed the redirect from / to /en/ on dalliard.ch and it now loads instantly. It’s build with Hugo and in the config.toml file I had defaultContentLanguageInSubdir = true. With false it seems I got rid of the 6s delay. Don’t know why.

Hi @fool, I know you guys are working on this, but can you maybe ping the investigator and see if they have ETA yet? It would help in our planning if any information along those lines is available

In my case, the problems started when I added redirects, so I also think that is related with redirects.

In particular, this redirect is not working well:

[[redirects]]
from = “/*”
to = “/index.html”
status = 200

I had to change to this in order to avoid the 6+ seconds of TTFB:

[[redirects]]
from = “/view/*”
to = “/index.html”
status = 200

[[redirects]]
from = “/test/*”
to = “/index.html”
status = 200

1 Like

Appearances may indicate that, @ignaciocabeza, but it is not necessarily limited to that.

@TORQ I do not have an ETA. We have spent 2 person weeks on debugging and attempting to fix and the fixes are still in active work; we will post here when we can.

I do not mean to dismiss your concerns or imply that it is not important to us, but across our service, this represents <.001% of our responses to normal browsers (rather than curl and pingdom), so even if you see it often - your visitors probably do not!

1 Like

I haven’t seen it at all when spot testing today, it seems like something has been fixed?

this represents <.001% of our responses to normal browsers (rather than curl and pingdom), so even if you see it often - your visitors probably do not!

Also, I understand how this might have been a low-priority issue for you guys overall due to that number, but for us it was on the order of ~50% of requests. Our visitors were definitely seeing it, including during some embarrassingly slow live demos by our sales staff.

It was never low priority for us, we just had trouble isolating it and the fixes we attempted in testing did not turn out to be stable.

Unfortunately I cannot claim that anything has changed.

1 Like

Sounds good, thanks for the update anyways. I’ll keep my eye on it and keep testing periodically from here, it’s still working great so far. Maybe our site just got randomly cycled off of a bad node or something.

if there were bad nodes or site config that triggered the situation, we would have found that on day 1 and removed the nodes and advised you about config changes. It’s something much deeper down than that by my understanding.

We’ve noticed this recently on a project of ours too, where we have our apex domain pointing to the netlify load balancer and a CNAME on the www.domain.com pointed to our netlify domain.

The direct netlify loads instantly but our root/apex is consistently reaching above 6 seconds (in browser, and fairly consistently at 6 seconds specifically which is odd).

Hi @fool,

I’m not quite sure whether this thread is still ongoing?

In any case, I’m trying to track down why we’re experiencing a TTFB of around 6 seconds.

An example request is x-nf-request-id: 8c2ed481-19bd-4b49-beab-3239ccf281d8-698893

Any help appreciated.

I just deployed a couple of standard Hugo sites to Netlify and am having the exact same problem. Every page loads fast except for the main index page and it takes 6+ seconds for that page to load almost every time.

More specifically, example.com/ takes 6 seconds example.com/index.html is served instantly.

hi all, we are absolutely still working on this, and I am adding your posts to the issue as we go along. Thank you for your patience.
We will update this thread as soon as we have some news to share.

I’ve just deployed a website using Hugo and I’m experiencing the same 6 seconds TTFB in two cases. An image on the homepage and a specific page.

The website is https://www.thegamingpub.com/ and on the home is where a logo image is being loaded and taking a long time. This is the image https://www.thegamingpub.com/images/logo.png

The other page is https://www.thegamingpub.com/past-issues/ here is the document that is the problem it seems. The funny thing is that if you access https://www.thegamingpub.com/past-issues/001/ everything loads fine.

Example requests:
Image: x-nf-request-id:5b068099-657f-4518-950d-13857d4c06b0-2554506
HTML Page: x-nf-request-id:5b068099-657f-4518-950d-13857d4c06b0-25594800

I can send the HAR files if necessary. I’ve already sent by email to support, but since I’m on the free plan the support channel is the forum, so, if you guys need the HAR files just let me know how to send it to you.

Here is a screenshot also:

I know you said there is some ongoing investigation into this issue, are you able to provide some kind of indication of how long this might take? For example, if this is likely to take a long time, it might be better to temporarily move a site away to a different CDN until this issue is resolved. Or is this an issue that is only affecting a subset of all deployments on Netlify?

Hey @0x6e6562 - thank you for providing that additional information. We have a pretty clear understanding of what is causing the issue, and unfortunately it is a fix that requires a bunch of additional work to ensure that our ~750 K customers don’t experience any instability as we make some changes. I understand that the performance impact is frustrating, but, we want to make sure we don’t make the problem worse by rolling out changes that haven’t been tested at scale.

We are actively working on this, but I am unable to provide a timeline. :grimacing: I wish i could. We will update here are soon as there are changes, however.

1 Like

Hey @perry - Many thanks for the heads up - I appreciate that you need to prioritize the overall stability of the platform and that it’s not that this issue is falling by the wayside, it’s just that the fix is tricky and needs to be applied in a controlled way.

Thank you for the update.

2 Likes

most definitely. we will respond here as soon as we have progress to share.

2 Likes

Hi everyone, we have some GREAT news :tada:

We have tested & rolled out a fix for these issues at scale.

More information here:

Please feel free to discuss on that thread, I will close this one (and others) so to contain the conversation a bit more. Thank you all for your patience :pray:

1 Like