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
And with compression:
$ time wget -q --header='Accept-Encoding: gzip' https://5e1c73420f92978cbf1a5f68--torq-dot-tech.netlify.com
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.
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
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.
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!
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.
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.
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.