Consistent 6+ second TTFB on small index.html file

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.

https://torq.tech/
https://torq-dot-tech.netlify.com/

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

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

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.

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

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:

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.