I am not familiar at all with the internals of the long callbacks, so please take my answer with a grain of salt and I hope you’ll get a more educated answer soon…
The way I understand both cache_by and cache_args_to_skip is the following: when you are caching a function, you need to create a key that you’ll use later to retrieve the return values previously stored. cache_by would be the “global” part of this key, which is independent of the parameters fed to the function, while the function arguments are the other (obviously dependent) part. In a simple example, if f(x) is a function you are caching, you want to create a new “global” key if you modify it (like f(x) = x to f(x) = 2*x), since all results stored in the previous cache are impacted by the changes. The other part of the key is x or whatever arguments your function has that lead to different return values.
In the example that you mentioned cache_by returns a random value that is generated every time the app starts. So your cache will be valid just in the same run (for simplicity, I am considering that expire is not set). If you return instead a fixed string, then the cache will never change, regardless of how many times you start and stop. So the caching key must be chosen depending on the details of your callback and your application, a balance between recalculating the function as less as possible and returning updated values. Some use-cases are discussed in the documentation.
cache_args_to_skip is related to which function parameters you want to use in the cache key, not how many outputs you are caching. The n_clicks example is great, because a button is very often used to trigger the callback, but the click count is not used for anything. If this argument is not added to the cache_args_to_skip, then the cache would create an entry to each value of n_clicks even if the function returns a value independent of it, which is not efficient.
Sorry for the long explanation. Hope that this helps!
