Look at request inspectors, log files, etc. Network behavior is easy to observe.
If you're an enterprise, typically, your employees have great connectivity to your corporate resources, so you're not going to get much out of prefilling the browser cache for them through desktop management software.
Make sure as much of your corporate intranet stuff as is reasonable counts as same domain for purposes of cache sharing, and standardize on a single version of your frontend libraries, etc, and you might actually get cache hits naturally. Standardizing frontend libraries is hard, but if shaving the couple of ms here and there is important, I'm sure you can find a way.
Now, maybe you've got a lot of work from home with terrible networks; that's pretty common today, or maybe you're work from the field and have had terrible networks forever. In that case, it might make sense to do something like wrap your web pages in electron where all the html/css/js is included and you only need to fetch data and you've got full control over the caching. Nobody on HN likes electron, but it would solve your enterprise problem. You might consider actually making an application, but that's unfashionable these days.
Of course, there's also the possibility of drastically slimming your pages down, etc, but that's a lot of work, so nobody wants to do that either.
Correct but do you know of any way to look at the cache hit ratio, stuff that didnt fit into the browser cache and other stats? I understand you can do it on a page level but I want to accumulate all of sessions and look at it aggregate and yet to find a easy way to see under the hood
>Make sure as much of your corporate intranet stuff as is reasonable counts as >same domain for purposes of cache sharing, and standardize on a single version of >your frontend libraries, etc, and you might actually get cache hits naturally. >Standardizing frontend libraries is hard, but if shaving the couple of ms here >and there is important, I'm sure you can find a way.
Correct but there is no guarantee its in the cache whereas my effort is to publish my app's shell/versions of frameowrks before I enroll users to my app
>Now, maybe you've got a lot of work from home with terrible networks; that's >pretty common today, or maybe you're work from the field and have had terrible >networks forever. In that case, it might make sense to do something like wrap >your web pages in electron where all the html/css/js is included and you only >need to fetch data and you've got full control over the caching. Nobody on HN >likes electron, but it would solve your enterprise problem. You might consider >actually making an application, but that's unfashionable these days.
Now, this is new, I need go learn this electron thing
To get the stats you want, you'd probably need to write a plugin using one of the hooks that lets you see all the requests (which are being phased out, but such is life).
Depending on your flows, you might be able to use <link rel="prefetch"> on a corporate home page to try to get things loaded, before users get to your app, although no guarantees of course.
Hmmm. So there lies the rub that we dont know as of now (will try to write an extension as you said)
Browsers expose this information.
Firefox, for example has `about:cache`
> as my enterprise I want to push objects to my employee's cache using an API
I've never heard of this being a thing. Why would you do this, and for what kind of sites?
Allowing an API to push objects into a browser cache en-masse sounds like a great security vulnerability.
Combine it with some basic packet capturing of new TLS connections and I could push arbitrary JS that did event capturing on all the sites that employees visited.
May I ask whats the equivalent for it in Chrome as majority of users are on Chrome for me.
>> as my enterprise I want to push objects to my employee's cache using an API
Well, theoretically you can do it using Service Workers today (https://developers.google.com/web/ilt/pwa/caching-files-with...) but I want to do it in a automated way so that I minimize the thundering herd when everyone comes tomorrow on Monday morning apart from enabling an offline experience (users in some countries have crappy connections so asynchronously pushing it is a way to solve it)
>Combine it with some basic packet capturing of new TLS connections and I could push arbitrary JS that did event capturing on all the sites that employees visited.
Hmm..I need more on this but the idea is they are SRI checked and come from a supply source thats trusted (but I get your drift on solar winds kind of lateral attack), but if I am right then what you say can even be done with the service worker API I mentioned above
I think for Chrome it's under devtools: https://developer.chrome.com/docs/devtools/storage/cache/
> what you say can even be done with the service worker API I mentioned above
Well no, because service worker API is going to be subject to the same security policies as any other site.
If I understand what it is you're asking for, you want the Web-equivalent of doing something like doing overnight pushes of software updates to the enterprise.
I don't know your environment, but you might be better off solving this by pushing large cachable things to edge caches closer to your users.
If they're on the public internet, then caching resources out of a public CDN might do the trick.
If they're on private networks in offices, then perhaps deploying something to those offices to serve local cache might work.
You don't necessarily need networking magic to make this happen - a service that can locate your users, and then issue HTTP redirects to a local cache server could possibly do it.
eg: call https://cache-main.example.com/some/resource.js, the server does a geo lookup on my IP, and issues a 301 to https://cache-some-remote-location.example.com/some/resource...
Trying to automate things like updating a user's cache directly in their browser seems like a major pain. How do you handle them not being logged in/sleeping/having multiple browser profiles/etc etc etc.
Even if users are perceiving the website is slow, it's probably not due to waiting for content that could be cached. It is more often due to slow database queries or the HTML, which is dynamic, taking long to load.
This information stored should obviously not be time sensitive. But if you're running a client for social networks or such, it's perfectly a good idea to cache the last 10 posts seen for example, so that when the user loads the page, he instantly has something to look at while the browser is fetching the fresh content.
Local storage was designed for this I believe: a longer-life cache for unimportant data.
One key consideration is security: do not cache things on the browser that may be private or sensitive information, unless encrypted, but even then the argument could be made to not do it at all. That said, storing your application graphics and most of the UI bits in local storage can certainly improve the user experience greatly.
Does this extend to other thick client apps like SAP or even ftp just for thinking's sake?
>This information stored should obviously not be time sensitive. But if you're >running a client for social networks or such, it's perfectly a good idea to cache >the last 10 posts seen for example, so that when the user loads the page, he >instantly has something to look at while the browser is fetching the fresh >content.
Correct but now this is why I say an API because each app can have its own way of caching the last few items (http objects, files, posts whatever might be tagged)
>One key consideration is security: do not cache things on the browser that may be >private or sensitive information, unless encrypted, but even then the argument >could be made to not do it at all. That said, storing your application graphics >and most of the UI bits in local storage can certainly improve the user >experience greatly.
Is it because of the browser? Say I remove it out of the browser and place it somewhere else, encrypt it store it and wont display until I verify the end user with SSO etc, would that take away this concerns. Depends on the user(most UI bits I agree need be cached and harmless either way) for what bits might be cacheable
Use a CDN accelerator like Cloudflare to improve load time since server side caching and client to server distance can impact performance.
Caching is solved fairly well by browsers, its usually server misconfiguration or lack of that is the problem.
I think http://www.squid-cache.org/ has options to ignore some of the browsers cache headers and return cached content anyway. But HTTPS caching requires that you let the traffic be intercepted and install custom CA certs so the proxy can be a MITM caching proxy.
------------
[0] https://antipaucity.com/2018/07/18/a-fairly-comprehensive-sq...