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.
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:
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.
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.
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.