@fool I am having the same issues. A HAR file can be found here:
That har file seems corrupted, @rshea - can’t load it (it is cut off somewhere in the middle). could you try gathering another one for us?
My bad – @fool try this one? https://drive.google.com/file/d/1l4_4ieKXIyf-spOhUsa0RgP0rj9MSNrU/view?usp=sharing
Thanks. I can definitely see what you’re talking about in there, this request taking 12 seconds seems like a big bummer:
…but on our side in our internal logs, we show we sent it in 6ms (the “x-nf-request-id” HTTP response header is a unique value that we can correlate to a specific request in our logs, and so I looked it up).
Was your internet generally working well at the time?
On my side I didn’t get any news from my last twitter attempt to solve this problem.
On our side, it turns out that putting CloudFlare on top of Netlify does significantly increase the TTFB performances. It is the exact same deployment, with a single toggle switched on CF side to enable the proxy.
Swyx should have given you both DNS domains (with/without cloudflare proxy) and told me you were studying the problem (fool+gerald), but no news for 1 month.
I feel like I gave you everything I can on my side, and can’t do anything more, except maybe paying 500€/month to solve this problem. CloudFlare is actually a way cheaper solution, and it’s what I end up recommending to my customers currently until this problem is solved. Despite Netlify saying CF on top of Netlify is useless, it turns out it’s not for me.
I was on a wireless connection, so I just ran this on a fiber 1gbps connection:
Still looks like the load time is happening.
@slorber Interesting – I might try this in the mean time despite using Netlify’s DNS with the hopes that Cloudflare doesn’t improve TTFB.
I also experience really slow download times for js files after a redeploy (4.5s for 300KB).
Hi there, thank you & other folks for your patience on this thread as we work to understand the underlying issues here. I know its frustrating to experience slow download times and we want to understand & do better.
We have been talking about this internally and are still looking into these issues, and hope to bring them up with relevant folks who work more closely with our infrastructure in the near future. We’ll update this thread here with any information - and if anything changes for any of you please do keep adding your thoughts here.
Not the quick-and-easy outcome we had all been hoping for - but we will keep looking into this.
I noticed that I got 6 seconds to load the HTML when I first created and deployed an app to Netlify. After ± 3 minutes it was lowered to 43ms. Must have been the CDN provisioning.
thanks for sharing. We are actively still working on this issue, and will update this thread as soon as we have news to share.
Hi, @leomrav, and welcome to our Netlify community site.
The geographic routing happens when the DNS query for the domain name occurs with Netlify DNS or when the CNAME lookup occurs for the
*.netlify.com subdomain when using third-party DNS.
The routing is controlled by the IP address making the DNS lookup. There is no (supported) way to force a Netlify site to use a specific CDN node.
A post was split to a new topic: Slow load time for Gatsby site
Any update on this ? I’m facing the same issue right after deploys across multiple sites. Some are React apps, created with CRA others are Gatsby site.
Hi, @florian-zsa, there is an open issue for uncompressed content often having a slow TTFB but all modern browsers request the compress version so this shouldn’t apply for that traffic.
We’ll need more information to see if this is the same issue which is affecting your site or. Would you be willing to send us a HAR file capture of the issue occurring?
If this isn’t possible, would you please send us the
x-nf-request-id header for a HTTP response which was slow?
There more information about this header here:
If that header isn’t available for any reason, please send the information it replaces (or as many of these details as possible). Those details are:
- the complete URL requested
- the IP address for the system making the request
- the IP address for the CDN node that responded
- the day of the request
- the time of the request
- the timezone the time is in
Obviously, if you send us the HAR file, all the other details above will be included automatically.
If there are any other questions, please include them at any time as well.
I’m seeing this issue with an SVG: f27819f9-a8d7-4a93-8ce2-de2b24eba2ce-5125898
Hi, @markdrzy, and welcome to our Netlify community site. I am seeing a slow load for that asset as well for that
I’m seeing 23 responses longer than 1 second in the last seven days for that asset. The remaining 46 responses for the same URL are all 200 ms or faster.
We’ve added this information to the troubleshooting of this issue and we’ll have another update here if/when the issue is known to be resolved.
Hello, is this issue in this thread only related to TTFB? Or also to content download times?
A few examples:
8.34 seconds to transfer 1.2mb:
4.56 seconds to transfer 780kb:
2.75 seconds to transfer 380kb:
TTFB is usually OK, between 200-300ms (not great). But I can’t really understand the transfer times being this high, as I’m loading other sites much more quickly. I’ve also tried on as many networks as I have access to with the same results. Is my problem related, or is this a different issue?
I am experiencing a similar issue. I have a local .json file, which I am accessing with fetch and using it to display some information. Problem is TTFB is >6 seconds but curiously this only happens on my custom domain name, while on the netlify generated url it is almost instant as it should be.
I’m not sure if it’s only on my end but you can try both https://jadezak.com/ghibli/ and https://kind-varahamihira-9ad643.netlify.com/ghibli/ and see how long it takes to populate the page with information.
id from the custom domain, TTFB 6.44s
id from the netlify domain, TTFB 9.52ms
Edit: seems to have resolved itself this morning.
Hi everyone, we have some great news
We have tested & rolled out a fix for these issues.
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