Slow connection after new deploy on first load for every user

Every time we deploy our app, the first time it is loaded, it is quite slow. The problem is, this doesn’t just occur for the first person loading the page for the first time, but for every person who loads a new deploy for the first time (switching to another browser seems to recreate the issue).

It is not unbearably slow, but still way slower then I would except from a setup like Netlify is using. And since its happening for every user on the first load, that would mean almost all our page loads would be slow.

URL: https://df-landing-pages.netlify.app/

HAR 1st try (300ms TTFB for the JS file), x-nf-request-id: 1e2831b5-1cab-4abc-af6b-5df9b3fcd852-2549734
HAR 2nd try (30ms TTFB for the JS file), x-nf-request-id: 1e2831b5-1cab-4abc-af6b-5df9b3fcd852-2584604

@essenmitsosse I see a pretty high score with GTMetrix. Is it possible it is a local issue?

Hiya @essenmitsosse.

This is pretty much expected - we cache opportunistically - at the moment the asset is requested for the first time on the CDN node the browser is talking to - and the 300ms is almost certainly that time: “sending content from our backing store to the node”. 30ms sounds like you are well connected && located near one of our data centers. Someone in New Zealand for instance would not see times that fast since the request has to travel a long ways from browser to server (to our PoP in australia, most likely.)

If you’re changing that file’s contents with every deploy, there’s no getting around it, but if you are changing only the filename, that’s something you CAN fix! Check out this article about the benefits of not changing filenames while contents don’t change:

Hey @tool,

thanks for the quick reply. We reexamined the issue. It had nothing to do with people loading the site for the first time. Its seems more like the cache is cleared within minutes and then the next visitor experiences a cache miss again. But what that would mean is, that if our site has no heavy traffic and only a visitor every few minutes, everybody would get a cache miss.

On your plans and pricing page you claim 80% cache hit rate. But it seems for us that would be way lower. I just reloaded the same page a few times, with a few minutes inbetween and it looks more like 0-40% cache hit depending on traffic.

x-nf-request-id: 63c9687f-46b5-4ca8-92e3-632d5e51a414-1307693 309ms
x-nf-request-id: 63c9687f-46b5-4ca8-92e3-632d5e51a414-1320655 34ms
x-nf-request-id: ee74555f-4658-4a00-92d7-e089917f3dc3-1936277 343ms
x-nf-request-id: ee74555f-4658-4a00-92d7-e089917f3dc3-1952076 78ms
x-nf-request-id: 264bca39-2154-4340-9876-af9bfeb5618f-336243 329ms
x-nf-request-id: 7ec39765-eb4a-401d-837e-9b7fdcce0304-647742 328ms
x-nf-request-id: 7ec39765-eb4a-401d-837e-9b7fdcce0304-658119 68ms

So for most visitors it would look like it wasn’t cached at all.

@fool could you confirm if this is expected behaviour or if there is something wrong with our setup/site?

hey @essenmitsosse - sorry to be slow to reply, fool is out on PTO this week which is why we don’t have an answer for you yet.

I’ll try and get someone else to take a look at this, and see if we can get some more information for you.

Our site is probably a lot better cached than yours - cache is first-in, first-out, and is per-node, as I mentioned. So if your site isn’t constantly in use everywhere, you may find the resource not in cache on that node.

Since all of those request ID’s which I checked were for a staging branch subdomain that I doubt your production clients use - this is a far BETTER cache hit ratio than I’d expect for that content! We cache by URL, not by asset, so “https://staging--yoursite.netlify.app/file.png” will NOT be satisfied by existing cache of “https://yoursite.com/file.png” or even “https://yoursite.netlify.app/file.png”.

Our site is in pretty constant use so generally stays cached better.

This may not always be the situation for everyone - there’s lots of things that could cause a 300ms variance in network timing OUTSIDE of both of our networks - but I did a quick spot check and in the above cases, the slower ones were all cache misses.