All dynamic web sites are built from server side programs accessing databases, and the more code, the more it is broken up – into separate files, the slower the access. Starting with the index.php, there are well over 2 dozen php programs that have to be accessed from the disk, and the fastest SCSI hard disks are still 1000 times slower than RAM.
One large file can be accessed a “hell of a lot faster” than having it broken up into dozens of fragments, that each have to be accessed separately. Conversely, a static, html page is just one file. Add a style sheet file and a few images, and it still comes up almost “before wordpress can even get started” – unless you use a cache.
“I use WordPress; many of my clients use WordPress; a lot of you reading this probably use WordPress as well. But in it’s simplicity of installation, and vast library of plugins, themes and other addons, it is quite simply a resource hog. [Even] A simple one-post blog would easily rack up the PHP memory usage and still [also] be quite slow in handling multiple visitors.”
http://kbeezie.com/view/caching-wordpress/
Caching will probably help your Google ranking as they are using speed as a metric when judging websites now. – wp-super-cache
Conclusion
Be it file-based caching, memcache, PHP accelerators, or other methods that tickle your fancy, caching is important for WordPress. Without it, not only does your server suffer under higher loads, but so do your visitors.
compare the best caching plugins for wordpress:
http://www.tutorial9.net/tutorials/web-tutorials/wordpress-caching-whats-the-best-caching-plugin/
Overall the best out of the box cache plugin configuration in my opinion is: Hyper Cache + DB Cache Reloaded. Despite the allure of W3 Total Cache’s professionalism and only slightly less admired performance, I prefer to retain some manual control over my blog. For those on a medium priced shared server or if you like the idea of installing and forgetting, the W3 Total Cache plugin will be your ideal choice.
A lot of people still use WP-Cache and WP Super Cache. They are still respectable WordPress caching plugins but consider trading up for Hyper Cache or W3 Total Cache. These newer caching plugins prove better performance and install/config much easier and cleaner. Also the development communities around these newer plugins are much more active and attentive to their users.
I hope I’ve helped you in choosing the best caching solution for your WordPress blog but this is only the beginning. There are so many more techniques to improve the performance of your blog. Caching is a great first step in preventing your blog from crashing during a flood of traffic.
Hyper Cache
Hyper Cache is a new caching plugin out in the community. It is geared towards the everyday blog or those hosted on low cost shared servers. Also available in many different languages.
Installing was a simple upload and activation. This plugin has a lot of great configurations and organized appropriately in a clean user interface.
Hands down the fastest caching plugin I’ve reviewed and surprising for how light weight it is. It may just be me but my blog just seemed to click on rather then load with this plugin enabled. Definitely for those hosted on a shared server or who are looking for as much caching performance from a plugin as possible. The development around this plugin looks very active too. A definite must have plugin especially if you plan on configuring your own additional performance tweaks such as minifying, db caching or compression.
“Hyper Cache is a new cache system for WordPress, specifically written for people which have their blogs on low resources hosting provider (cpu and mysql). It works even with hosting based on Microsoft IIS (just tuning the configuration). It has three invalidation method: all the cache, single post based and nothing but with control on home and archive pages invalidation.”
Includes mobile browser detection with two separate caches (wp-pda plugin compatible)
http://wordpress.org/extend/plugins/hyper-cache/
currently: Hyper Cache 2.8.0 — runs on WordPress Versions 2.5 + (through ver. 3.0.5 … 3.1.1)
Last Updated: 2011-4-5
W3 Total Cache
W3 Total Cache is the mother of all caching plugins. It is huge, well documented and packs in an impressive amount of performance configurations all into one plugin.
Installation was surprisingly easy. With all the options available I thought I was going to be here all day configuring this beast. After activating it automatically best guessed an optimal configuration. Great for those who just want to install and go.
If you’re looking for a plugin that does everything then this plugin is your golden ticket. From multiple methods of page caching, minifying, database caching, content delivery networks… this plugin does it all. They even have support request available and built right into the plugin.
Now to avoid sounding too much like a car salesman lets review the cons. First, it is huge. Even though disk space is becoming less and less of an issue there are some blog admins out there that either don’t have or want to spare the space. Second, it is fast but not the fastest caching plugin out there. Especially if you disable the minifying and compression built into the plugin. Then it runs on a more equal footing with the other plugins reviewed here.
[one of] “The fastest and most complete WordPress performance optimization plugin. Trusted by many popular sites like: mashable.com, smashingmagazine.com, makeuseof.com, kiss925.com, pearsonified.com, lockergnome.com, tutsplus.com, johnchow.com, ilovetypography.com, webdesignerdepot.com, css-tricks.com, yoast.com and others – W3 Total Cache improves the user experience of your site by improving your server performance, caching every aspect of your site, reducing the download times and providing transparent content delivery network (CDN) integration.”
http://wordpress.org/extend/plugins/w3-total-cache/
currently: Version 0.9.1.3 runs on WordPress Versions 2.8+ (through ver. 3.0.5 … 3.1.1)
Last Updated: 2010-12-2
different types – aspects – of caching
MySQL Query Cache
Since WordPress uses MySQL, almost every page load results in various MySQL queries for page and post content, categories, sidebars, and so on. It is very likely that this data didn’t change since the last visitor so we can cache the MySQL server.
PHP Compiler Cache
WordPress is a PHP application so every request results in a call from the webserver (like Apache) to the PHP interpreter. This program reads the script files and compiles them into opcode which can be executed. A PHP Compiler cache saves the script in the compiled state in the memory which allows the PHP engine to execute it directly without compiling again which makes the execution about three times faster. Two widely known PHP compiler caches are APC and eAccelerator.
WordPress Internal Caching
In case of a slow database server, it might be a good idea to store frequently used data in a serialized form on disk. For instance, store rarely changing data like categories and users in a special folder. Note that this cache is not recommended if the disk is slow or… To enable WordPress’s internal caching, uncomment or add this to your wp-config.php: define( ‘ENABLE_CACHE’, true ); and make sure that the wp-content/cache folder is writable!
Static Pages
If all the other caching methods are not enough or you can’t apply them, there is a last solution: Caching the complete generated pages. This can be done via excellent plugins like Hyper Cache, W3 Total Cache, WP-Cache, etc.. (see below) The plugin will cache the whole generated page on the disk and skip the complete WordPress execution on further requests. After a specified time or if you publish a new post, the cache will be cleared and generated once again. This method is the fastest available, but it will break some functionality like plugins which add dynamic content to your blog or count page impressions since they are executed only once. … Dynamic content created by javascripts are no problem since they run on the visitors pc, not the server.
What Not To Cache
There are a few elements to a blog that you should avoid caching. Such as ads, feeds or any dynamic content obtained using php or a server side system. The whole point of caching is to save time by avoiding server side processes. If you have any content that needs to change for each visitor then you should avoid caching that page or content.
Don’t worry about your Google Ads or BuySellAds. Those ads are delivered using javascript and caching won’t affect the delivery of those ads. Most javascript based systems will not be affected by caching since they are client side scripts; not server side scripts. Although it is always good practice to double check to ensure your dynamic content is not being cached.
off-loading content?
A server can only handle a certain number of requests at a given time, so trimming down the number of items or off-loading content to a second server can dramatically improve performance. For example, if you are going to have a post with several images embedded in it, consider uploading those to an image sharing site like Flickr and then embedding them in your page. That way, when visitors come to your site the images are being served up by Flickr’s giant servers which can easily withstand the load.
4 of 5 Ways to Speed Up Your Site
http://paulstamatiou.com/5-ways-to-speed-up-your-site
1) Reduce Overall Latency by Reducing HTTP Requests
Every HTTP request, or loading each item on your website, has an average round-trip latency of 0.2 seconds. So if your site is loading 20 items, regardless of whether they are stylesheets, images or scripts, that equates to 4 seconds in latency alone (on your average broadband connection). If you have a portion on your site with many images within it, such as your footer, you can reduce the number of HTTP requests with image maps. I discussed that in more depth at the end of this article. If you are using K2 [theme], you can get rid on one extra HTTP request by using one stylesheet, style.css, and no schemes (integrate what was in your scheme in the main stylesheet).
Don’t Rely on Other Sites!
If you have several components on your site loading from other websites, they are slowing you down. A bunch of HTTP requests from the same server is bad enough, but having HTTP requests from different servers has increased latency and can be critical to your site’s loading time if their server is down. For example, when the Yahoo! ads server was acting weird one day my site seemingly hesitated to load as it waited on the Yahoo! server before loading the rest of my content. Hence, I don’t run Yahoo! ads anymore. I don’t trust anyone else’s server and neither should you. The only thing on this site served on another is the FeedBurner counter.
2) Properly Save Your Images
One huge mistake people do is save their image in Photoshop the regular way. Photoshop has a “save for web” feature for a reason, use it. Photos can be compressed and consume less disk space (than bitmaps, the worst!) as .jpg’s but your digital camera saves them with very little or no compression. A camera’s 5 meg jpg image can be compressed by only a slight 15% (85% quailty) and only take up about 1 meg or less. And, at 85%, you cannot see any difference in the 1 meg and in the 5 meg copies. I blew up 2 to 200% on the computer and inspected them up close and could barely tell any difference.
3) Avoid JavaScript Where Possible
In addition to adding HTTP requests and size to the site, the execution of the JavaScript (depends on what it does) can slow your site. Things like Live Search, Live Comments, Live Archives are tied to large JS files that like to keep your readers’ browsers busy. The less the better.
4) Strip Extraneous PHP/MySQL Calls
This step is probably only worth pursuing once you have completely exhausted the other tips. The K2 theme my site is vaguely based upon originally comes with support for many plugins and features, many of which I don’t use. By going through each file and removing the PHP calls for plugins I’m not using or features I don’t need, I can take some of the load off of the server. When it comes time to hit the frontpage of Digg or Slashdot, your server will more than thank you. Some aspects of this can be exemplified by hardcoding items where feasible. Things in code that don’t change in your installation such as the name of your blog or your feed or stylesheet location, can be hardcoded. In K2 these items rely on a WordPress PHP tag such as bloginfo. It’s hard to explain what sorts of things you can strip from your website’s PHP framework, but be on the lookout for things you don’t use on your site. For example, in the K2 comments file there is a PHP if else that looks to see if live comments are enabled and utilize them if so. Since I don’t use live comments, I can completely remove the if part and write it so that regular comments are always used.
Also, using too many WordPress plugins can be a bad thing, especially if those plugins are dependent on many MySQL commands which generally take much, much longer to execute than PHP and can slow a whole page down.
Miscellaneous Thoughts
Even if you don’t call on a piece of CSS that has an image, it is still loaded – so you might want to rethink using that one CSS selector that hardly gets called. When it comes to using a pre-made theme for your CMS, it’s a good idea to go through the CSS and look for things that aren’t used. For example, with K2 there was a bit of CSS defined for styling sub-pages. I don’t have any sub-pages so I removed that piece of CSS.
If your site is maintained using a CMS of some sort, you likely have several plugins, if not dozens, running behind the scenes. Going along with the theme of things, you will want to deactivate any plugins that aren’t mission critical. They use server resources and add to the PHP processing load.