Consistent 6+ second TTFB on small index.html file

Support
1

I’m really confused what’s going on. My site has bimodal performance, it either loads in ~100ms, or it has a >6 second TTFB.

I’ve tried redeploying numerous times, and reproduced the issue in a different Netlify site ID as well, although not consistently.

I can provide a HAR if it helps. x-nf-request-id 77d8da39-b103-4836-b5f1-7a59c8ce48e5-3382205

For example, time wget https://5e1c73420f92978cbf1a5f68--torq-dot-tech.netlify.com

will often give me results like 0.01s user 0.00s system 0% cpu 6.319 total

3

Hi, @TORQ, and thank you for reporting this, which I believe is the same issue reported here:

It is important to note, this only affects uncompressed HTTP requests which many command-line tools (wget, curl, etc) use by default. As people’s web browsers will always request compressed versions of assets, this won’t affect real visitors, only certain “bots”, scripts, and/or automated monitors.

Please feel free to test this with compression enabled and I don’t think you will see any delays. For example, without compression:

$ time wget -q https://5e1c73420f92978cbf1a5f68--torq-dot-tech.netlify.com

real	0m6.389s
user	0m0.018s
sys 	0m0.010s

And with compression:

$ time wget -q --header='Accept-Encoding: gzip' https://5e1c73420f92978cbf1a5f68--torq-dot-tech.netlify.com

real	0m0.148s
user	0m0.020s
sys 	0m0.010s

We have this topic cross-linked to the open issue and we’ll follow-up here with an update if/when the issue with uncompressed requests is resolved. Be assured though, your site visitors will be unaffected in the meantime.

If there are any questions, we’re happy to answer.

1 Like
4

Hi @Luke, thanks for the detailed look at this!

Unfortunately, that doesn’t seem to help, at least when it comes to using our live domain. It does seem to help with the netlify subdomain.

☁  [master] ⚡  time wget -q --header='Accept-Encoding: gzip' https://torq.tech 
                                         
wget -q --header='Accept-Encoding: gzip' https://torq.tech  0.00s user 0.01s system 0% cpu 6.517 total

We have also noticed this in our browsers, and I’ve repro’d it on my mobile phone, which really has no chance of any extension etc. interfering with the test since it’s just stock Chrome.

I sent a HAR file via email that also recorded the behavior, and analyzing it now, it looks like accept-encoding gzip, deflate, br is properly set on the request.

5

Thanks for submitting a helpdesk case with the HAR file - our team will take a look at it first thing tomorrow.

7

Any update on this? Just put together a new site with 11ty and seeing the same problem on just the home page, no domain configured yet. Every other page is very fast :thinking:

8

No updates as yet. I was just told by our CTO that the status remains “we are actively investigating” and by that I mean there is a staff member who is working only on this issue full time right now.

3 Likes
9

Really appreciate the updates on this @fool. It’s not an issue at all really right now as putting Cloudflare over it with my custom domain has improved the speed dramatically. It’s still good to know as it may affect future projects :+1:

10

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.

11

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

12

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
13

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
14

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.

15

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
16

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.

17

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.

18

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

20

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.

21

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.

22

More specifically, example.com/ takes 6 seconds Example Domain is served instantly.

23

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.