Your questions come down to, basically, "Do I have a problem" and you go on to say at the moment no but not sure about the future.
The site performance is quite OK but I'm not sure what the 256 MB key buffer indicates and if that is tannable in the long run or not.
I don't think anyone can suggest that there is or is not a problem here based on the fact that performance is currently ok but you are worried about long-term performance concerns. Without knowing what sort of growth you are expecting nobody can give more than a guess.
So I am going to go a different approach and suggest that you need to start with a framework for determining whether you need to start thinking about optimizing/upgrading. This seems the best way at this current point.
Your database looks like it fits in RAM. Is it growing? How fast? How big is it? When will it exceed 250M in size? When will it exceed your server's RAM?
How many concurrent connections do you typically have? How fast is this growing?
Once you have this sort of data (and you really need to start with hard numbers here!) then it should be pretty straight-forward to determine whether you need to be thinking about capacity or performance tuning. However as long as performance is good right now, then you have time to gather data, evaluate, and plan.
UPDATE BASED ON FEEDBACK
So the db doesn't fit in RAM. It is apparently a virtualized server with only 512MB of RAM. I don't think you need a larger system yet but it is worth keeping your eyes on the performance numbers.
The cache is going to be the MySQL page cache. This is used to store frequently used parts of the database in memory. Note that ALL of your select and update queries are currently hitting the cache. Your inserts are not as expected. This means you have enough ram reserved for the MySQL page cache to hold everything being queried in RAM. While I had assumed it was the full db, actually unqueried portions of the db would not need to fit in RAM for these numbers.
You have a few options. You could decide to get more RAM (and run tuner programs as @RolandoMySQLDBA suggests) when your cache utilization hits 90% or so. You could upgrade things now with the idea you may likely need it. Or you could be more conservative and wait for some read queries not to hit the cache on a consistent basis. It depends on what you see as necessary performance.
Actually... no.
The query cache in MySQL, as I discussed at length in another answer, is an optimization that does only one thing: it returns the exact same result set in response to the exact same query, if the previous result was cached and has not been removed from the cache due to invalidation (by changes to the data in the underlying tables) or pruning to make room for more recent queries.
The query cache is checked before the query reaches the parser, whenever a query comes in starting with the characters "SEL" (case-insensitive).
If the query, byte-for-byte, is not identical to one already cached, the query will not be served from the cache. If anything changes, even a single space in the query, then that's a different query according to the query cache.
If a query with LIMIT X,Y or the equivalentLIMIT ... OFFSET ... is cached, then only the actual rows returned are stored in the query cache, and only the identical query with the same limit and offset will fetch those same rows from the cache again.
Best Answer
This is the best documentation available for the query cache:
sql_cache.cc
I am not kidding, the header of that file contains the most detailed overview I have ever found. Next thing is the own code, which is on the very same link.
There is a query cache chapter on this book, and this other book, but only 4-5 paragraphs, in the context of its relation with the handlers interface.
Apart from that, you should read the general internals code guide.