Home
Support Forums

(Very) slow loading of some js: TTBF / download / revalidation

I’ve multiple setups on AWS, cloudflare and Netlify (same repo) and have also recently moved in a bunch of sites to Netlify pro plan. The same setup is really fast on CF pages (<1s load), but I’ve been noticing lots of issues on Netlify (~4s load) which is completely degrading the user experience.

  1. (Very) slow response times for some resources across various sites. Normal resources take between 200 and 800ms, while problem resources take between 1.5 seconds and 30+s.

Various request IDs:

  • x-nf-request-id: 01FGS0516X9ET3N54ZJ3H2B355
  • x-nf-request-id: 01FGEPECPK4ZX3FJGNTJXVJKXB
  • x-nf-request-id: 01FG8XNS2GT78ST6C4V2AV718C
  • x-nf-request-id: 01FG7BW6ECBQK5HPJ5JJVR37ME
  • x-nf-request-id: 01FFATXCGN5W5646Y40CQ86CK3
  • x-nf-request-id: 01FF7ZSVDACX3VM7MKMW5YRWH0
  • x-nf-request-id: 01FGS09E71K5WM89SD7MSC0BW6
  1. Even if there is an occasional hit on some resources for 1st time load, why is it taking multiple seconds for revalidation. I can reload the same site after 1 min, and again it will take 4s for revalidation. Thats nuts.

  1. Cache control setting of max-age=0 - this makes no sense at all on static resources. Why needlessly force the browser to check on these on every load?

  2. Some sites have a initial js bundle loading from cloudfront (with max-age set as expected: max-age=31556926), most of my sites don’t. And after the first bundle, all the rest come from Netlify. So is there a CDN even being used?

In most cases, we say 400 to 800 ms could be considered normal for assets on Netlify, but 1.5 or 30+ seconds? That’s a lot! I have personally never seen this happen and would love to dig deeper on this. Do you have the URLs that give such an error? I checked the request IDs that you sent, but a lot of those IDs return no matches in our logs - this would happen if the request failed prematurely. Did something like that happen?

I could see values in 150 to 600ms as TTFB for your websites.

I would like to explain here how our CDN works and how the fingerprinting of assets is a bad practice. Netlify relies on file names and their hash to determine the cache. When you fingerprint an asset, it doesn’t just invalidate that file, but all the others that reference to that file because the other files now need to include a new name. So for each of the CDN node, this new file now has to be requested from the origin server and then it’s saved to the CDN cache. Thus, we always advise against fingerprinting.

The reasoning for this is explained here: Better Living Through Caching | Netlify

Cloudfront !== CDN. Cloudfront is where we store the assets optimised by post processing. With or without Cloudfront, Netlify is using a CDN as long as the DNS is correctly setup.