It’s an angular application and its vendor.js needs 5-7 seconds to load
Hmm. I’m seeing a complete page load time of just over two seconds, with the vendor.js file taking something like 60 milliseconds.
Check out my HAR-File:
I consistently get long loadtimes with that specific file (vendor.js)
Hi, @benjaminM, we are tracking an issue where uncached content is slow to load from certain CDN nodes. The size of the content (745495 bytes for
x-nf-request-id: 5fe903ef-840b-4596-a3b1-44121e87c3c0-22250492) make it much more likely to be removed from the cache.
I don’t have a solution for this issue at this time. If/when the issue is known to be resolved, we’ll post an update here to let you know about it.
If there are other questions about this, please let us know.
Hi, I am having a similar issue. My website loads some galleries with ~100kB images, each image is taking around 10 seconds to be fetched.
I configured HTTPS last month and it is when I started noticing that it was loading very slow.
@icruces The problem seems to be that you’re loading all of your images at the same time. Instead of loading ~ 100kb your site is fetching 5MB of resources simultaneously. If I open a single image in a new tab it loads almost instantly.
I’m afraid the behavior you’re experiencing is a problem with your code. Have you considered lazy loading your images when clicking to a new slide? The plugin you’re using provides documentation on optimizing your gallery.
The problem only occurs with the initial load and the file is then cached by the browser.
Looking forward to a solution. Thank you for your reply and help
@tomrutgers I understand what you mean but I don’t think 30 ~100kb images should be that overkill. I have been testing with smaller galleries, getting similar bad performance.
I am getting TTFB of ~2 seconds and download time of 10 seconds for every image.
I have deployed the same website with GitHub pages, also using HTTPS with HTTP 2 protocol and the difference is massive. The same gallery takes less than 1 second to be fully loaded.
Hi, @icruces, the issue is happening because all global traffic for this domain is being sent to a single IP address near San Francisco. This site isn’t using Netlify’s CDN.
We recommend making the
www subdomain primary when not using Netlify DNS. This site is using external DNS and it is already has
www set as primary so that part is correct.
The external DNS instructions recommend the following DNS records:
www.franciscocruces.com. 300 IN CNAME veterinarian-lion-52516.netlify.app. franciscocruces.com. 300 IN A 220.127.116.11
However, this is what the DNS records are instead:
www.franciscocruces.com. 299 IN CNAME franciscocruces.com. franciscocruces.com. 299 IN A 18.104.22.168
If a CNAME for the
netlify.app subdomain is used, this will be translated into the closest IP address for Netlify CDN node based on the geographic locations of the requesting IP address.
When the CNAME points to the apex domain all traffic goes to one system. In this case (the requests in the HAR file), the source IP address in Europe and the request is going all the way to San Francisco instead of using a CDN node nearer (for example, a Frankfurt CDN node).
Would you please update the DNS settings for this domain to match the recommendation on the external DNS instructions?
If this doesn’t resolve the issue and/or if there are other questions, please let us know.
Thanks for your reply, I will fix the configuration.
Hi @luke, I have changed the DNS configuration and now it uses Netlify DNS. It is much faster now but still much slower than in GitHub. Each image takes 2-3 seconds to be fetched in parallel vs ~200ms in GitHub.
There’s a lot which could be at play here: are these times still the case after the first time you load the site? If not, it’s cached in your local CDN and that’s a more realistic time.
At that point, you’ll need to consider perhaps how close a GitHub node is to you versus your nearest Netlify node (and there’s not much which I can do about that)!
@luke I still experience this issue. Long load time 5-7 seconds for a small file.
Is this issue still open?
There’s lots (I mean lots) of talk surrounding this bug. Unfortunately, the news today isn’t good news however a fix for this is part of a larger set of works. I don’t have an ETA for this however, rest assured, the team are aware!
@Pie Thank you very much for your reply! Is there any open ticket or post where I can track the process on this issue?
Nothing public facing, I’m afraid However, this very topic has been linked to the issue so we’ll feed back when we can!