In the short term, yes, it’s okay.

Knowing that over the long term, you’re going to get burned. So no, it’s really not okay.

Yes | No really depends upon your shop; the amount of backlog that is present; and just how critical this particular function is.

Caching to mask performance issues is a crutch, and is a form of technical debt. The real problem comes about when you have to start making changes or updates within that area. The cache represents the first layer of band-aids to this problem. Future changes will result in more and more band-aids until you fix the root of the problem.

If it can be reasonably easily fixed within the constraints of your environment, then it should be fixed. Especially so if it’s a volatile area.

If you’re considering taking shortcuts knowing that you can use the crutch of caching, then you’ve already headed down the wrong path.

As always, it depends. Caching can improve performance anywhere between “whopping” and “not at all”, or even reduce performance.

If your resource it read often but seldom changed, caching is usually a good idea, especially when generating it is non-trivial. If, however, it changes every few requests, there is no point caching it.

Also, it can be beneficial to use several layers of caching – e.g., a response cache at the HTTP level that serves identical responses to identical requests, a memory cache holding readily-processed data sets, another cache that holds chunks of raw data for further processing, and of course the caching that comes with your databases and filesystems. The reason why you want to cache at several levels is that there are different points at which you can match identical conditions with identical results, and you want to cache at each of these whenever it makes sense.

Another factor you need to keep in mind is that most data does not have to be available in real-time. It is often acceptable to present data that is, say, an hour old or so, even when newer data exists. If this is the case, you can generate your resource in a separate process, serving the previous version until the new one is done, then doing a fast atomic replace (e.g. by renaming a file or through an atomic database operation). This way, you always get maximum performance at all times, while you can still afford to take some time generating the resource. And, better yet, the generator can run on a different machine if necessary, so as not to bog down the web server itself. Of course it doesn’t hurt to add a layer of caching on top of that; after all, serving from RAM is still an order of magnitude faster than serving from disk.

It would be grossly inaccurate to tell you that it is or it isn’t okay because it is ultimately a tradeoff between implementation time and how well you wish your program to perform. I don’t think it’s fair to say that program performance always has priority over performance, because ultimately the software industry is a business like any other and some tradeoffs are acceptable.

However, I think the only time when it’s okay to ignore poor performance for a resource that will be cached is if you plan on preloading a lot of resources you will use at the startup of the program and your cache isn’t weak (you don’t throw out old data in favor for new data). Users tend to have little patience for waiting times, but they also tend to be more tolerable if they expect to have to wait, such as moments when you’re opening a program or you’re creating a report. You can take advantage of this and load once and placing this resource in cache. Just don’t combine poor performance with lazy loading, since that will create unexpected delays when the user won’t expect it.

And, of course, do be sure to get around to fixing that performance problem eventually.