The Wp-Favicons plugin, which iconizes your blog-links, makes use of request caching. We need this for 2 reasons:
1. so that when you delete your favicon cache and want to regenerate your favicons, it will not go out and do thousands of requests again (assuming you have thousands of links on your weblog)
2. to validate your links and produce those cool little round icons indicating green, yellow, red, black or white links. Very handy to bring your 404 links etc… back to 0 in a short time and to provide your visitors some information about the links they click.
For me: I really wanted to have this. I even want to have the tool clean my links automatically in some way, which will appear in the next version.
BUT……………. this of course has impact on the storage on your server or shared hosting account.
1. To show icons to your users, we have to store them on disk since embedded bas64 encoded icons are not supported by all browsers. This means, that for e.g. 10.000 outgoing links it will store 1.000 icons, which are small but each take a few Kb (assuming you link multiple times to the same websites) (since it will store an icon only if it is unique in terms of uri where it came from). But… whatever a CDN coupling might be in a next release.
2. To have an index of the icons on your disk we use a metadata cache, which is a database cache so this is then 10.000 records for 10.000 outgoing links.
3. To cache all your outgoing requests we store each request in the database and ergo duplicate the icon or the webpages we scanned in the request. THIS is a biggie.
On my system my original database export was about 120 Mb (for my personal multisite environment). When I installed the plugin the export became 825 MB. So this single plugin makes your database about 7 times as large. GRIN.
But yes, this plugin has high demands. If you have the disk space (so let’s say 7 time your current database), then it is no problem. If you are on a database disk space limited server then you might have a problem and better not use it.
For me, I really really want to have this one. It’s a heavy one, but one that is worth it.
But… for the next release I will try to lower the database size of the request cache, this will probably will mean some lost functionality but let’s see how far we get.