Typically one would refer to an in-between mini release as a patch. The line between a patch and a full software release however is not a settled matter by any stretch of the imagination. It is sometimes hard to make that determination.
How much development work went into the patch?
It is not always about how much development work went into the patch. A patch might comprise less than an hour of easy development but the impacts these changes make can be monumental.
How much risk am I introducing?
Above all else a patch must be stable. Stability of a patch is directly correlated with the number of components, features and deployment complexity that are impacted by the patch changes. There are a number of different risk scoring systems to choose from but they all tend to revolve around the number of impacts and the importance of these features to the client.
High risk is okay as long as it is met with an equally high amount of quality assurance and testing effort.
Does your system have repeatable unit tests covering components or functionality that might be impacted by caching?
Does there exist any kind of automated UI or front end testing (Eg. Selenium )
Do you have load testing scripts that can verify the cache holds up to production level + demands?
These are all a minimum requirement in my mind just to even consider something like caching being introduced into software in the form of a patch.
Caches are no small thing. Small mistakes can have profound show stopping issues so you must be sure that you get it right.
I can't very well tell future employers that I implemented caching and saw an increase in performance without actually deploying it and capturing the improvement (through google analytics or Page Speed or some other method), or can I?
You can and you should. It is important that you have a seperate test environment for your web site that is self contained, has quality data, and attempts to mimic the production environment in as much a way as possible. How can this be done?
Seperate public hosting for your test environment, or unutilized or under utilized in house server that can be used to host your web application.
Database can be established with the same exact schema and a snapshot of real production data (De-identified of course if it contains sensitive user information).
Now with automated UI testing tools as well as load testing tools against your test environment, you should be able to mimic the 50k visitor load against a test environment that is a copy of the production. This will help flesh out any hidden problems that you would otherwise unfortunately discover in production post deployment.