Unfortunately we are on a managed server and have to wait until the hoster adds that mod.
Is anything known about how this 1.0 release will affect server cpu? Betaversions were said to consume 2-3 times more server cpu.
You basically don't need this if a web application is well designed and well written (with good performance in mind). If you don't see much (or any gain) from using it, you probably are already well optimized
Some tips to get good page speed scores:
Use CSS sprites whenever/wherever you can. Always (unless, it's impossible for some reason). Reducing the number of requests on a page will give you the highest gain. Yes, it can be quite some work to convert to sprites, so don't be lazy, it pays off as your pages will not only load faster but also use less bandwidth.
Review your server configuration and implement proper expiration times for static content (scripts, images, style sheets) so that browsers will cache them. Google's pagespeed carefully looks at these things. If you can, serve static content through an extra, lightweight web server (nginx is excellent for this).
Load scripts asynchronously when possible. That's even better than loading them at the bottom of the page.
For PHP, use a opcode cache, preferably XCache (it's faster than APC), but APC will do the job just equally well.
Optimize MySQL. A query cache can help tremendously, but care must be taken to not "overoptimize" it - if a query cache uses too much memory, it can quickly negate the performance effect into a loss
If query_cache_size is 0, you should also set query_cache_type variable to 0. In this case, the server does not acquire the query cache mutex at all, which means that the query cache cannot be enabled at runtime and there is reduced overhead in query execution.
Well, not everyone is on 5.5 and the suggestion is valid for cases where a query cache would *not* help at all. In that case, you can speed up MySQL a tiny bit more by completely disabling the query cache at startup time.
That doesn't mean a query cache is totally useless. It can still help, but it depends on the application and server environment. For example, if you have only one CPU (core) available, the locking is not going to hurt a lot, because your threads will never execute concurrently.
The real pain with the query cache comes from query_cache_wlock_invalidate=ON because this will result in much more aggressive locking by the cache. The setting is, however, only needed if you *have* to prevent clients from getting results from a table that is currently *write* locked. If the setting is ON, the query cache is invalidated as soon as a table gets write locked (obviously something that can significantly reduce the efficiency of the cache). If the setting is OFF, that doesn't happen and a client could still get a result from a write locked table (if such a result can be found in the query cache). This is something that can bite you if your application must ensure data consistency at all costs - something that is generally not needed for a blog or forum.
Two completely different pair of shoes, but if an application cleverly uses its own caching (memchached/xcache/apc/whatever) to cache query results, it can help a lot, yes. Fetching a serialized query result from from memcached is almost always much faster than fetching it from the db even if the query was cached by the database server.