Extreme slow download of new content after a new deploy

Since yesterday afternoon we have been experiencing extremely low download speeds of up to several minutes after a new deploy. Everything was working nice before.

The problem is not TTFB, it’s download speed. Once all the contents have been cached, the App works normally.

We are accessing from Spain, with users spread across the country who experience the same, but it does not seem like a problem with the Internet. We are also not behind any proxy.

https://testmysite.io/5e7b46dac0fd560f71f16c89/kpaces.com gives 99/100, so it may be a network problem.

Our app is in production (https://kpaces.com), so we can’t do too much testing. The problem could have already been solved, but we have no way of knowing without putting our users’ access at risk.

We have not encountered any similar cases in the support forum.

Could it be related to changes in redirect rules?

Our _redirects file is this:

/reset  /clear.html     301
/clean  /clear.html     301
/fix    /clear.html     301
/clear  /clear.html     301

And our netlify.toml this:

[[headers]]
for = "*"
Cache-Control = "public, max-age=604800"
[headers.values]
X-Frame-Options = "DENY"
X-Xss-Protection = "1; mode=block"
X-Content-Type-Options = "nosniff"
Referrer-Policy = "strict-origin-when-cross-origin"
Feature-Policy = "fullscreen 'self'"
[[headers]]
for = "/index.html"
[headers.values]
Cache-Control = "no-cache"
[[headers]]
for = "/img/*"
[headers.values]
Cache-Control = "public, max-age=31536000"
[[headers]]
for = "/clear.html"
[headers.values]
Cache-Control = "no-cache"
Clear-Site-Data = "*"
[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

Thank you very much.

Do you really need two dozen prefetch instructions? It appears that you are calling a lot of JavaScript before you call the JavaScript that actually builds your page.

We have not adjusted webpack configuration manually. But that has not cause problemas before now.

Do you think it may be causing that problem?

I haven’t run a timing on it, but if those requests are blocking the execution of your “main” script until after they finish running, it could be the reason for some of the delay (in addition to all the HTTP requests being made, of course).

I was wrong, we were not using the default vue-cli configuration for splitChunks. I will try again with the default configuration.

Thanks!

I have change the chunk splitting strategy and it seems to be working much better now.

Thanks a lot!

1 Like

great! thanks for letting us know.

Now that I am not seeing so slow download, I am seeing too high TTFB, take a look:

And HAR capture: https://www.dropbox.com/s/fpx5xxbshsf74n6/kpaces.com.har?dl=1

Any clues?

I haven’t had time to look deeply, but at a guess that site is has too many assets that are all trying to be loaded simultaneously. I’d try to keep your pageloads with well under a hundred assets apiece!

I have reduced most of the assets by using an external CDN, but I am still seeing a very long TTFB.

This is my Internet speed and ping latency (https://www.speedtest.net/result/9195074734.png).

Obviously, it may be traffic congestion. I have made a ping test from Spain to a server in Frankfurt (https://www.speedtest.net/result/9195159123.png).

It looks to me like only one asset is being downloaded at a time, although HTTP/2 is enabled and is the protocol that Chrome reports to be using.

Something has just changed!

This is what I supposed it to be.

Have you changed anything? Because I have not.

hi @ManuelLlorens - we have not changed anything on our end to my knowledge. Glad to see you have better download speeds though!