We’ve recently changed a way we configure the databases that our sites depend on, the back-end databases for WordPress. This change was oriented towards improving the speed that visitors to the sites experience. An unanticipated site-result was that the administrative interface performance improved even more. This speed up results in less time required for doing things like authoring new pages and posts, uploading images and checking on lead form responses. It takes us less time to administer the sites and this translates into lower costs for our clients.
WordPress is an awesome CMS in terms of what it brings to the table: it can be re-dressed and have new functionality added quickly. Using it as an administrator or author is as easy a using a word processor. However, these benefits come at a cost. There are more moving parts in a WordPress instance, different layers that depend on each other to yield the expected visitor experience.
For example, pages must be served through a dynamic code interpreter where the output isn’t static but instead can vary per-visitor. There’s a need for a database and to have the connection between the database and the web server to be always on and speedy. The result is a site that is “slower” than a site using only static HTML files.
The speed of the database becomes a big issue when dozens of database calls are required for a single page view.
WordPress databases have been classically created by default to use a simple, albeit crude type of database engine: MYISAM. This OEM engine is more of a lowest common denominator in database types, chosen to maximize compatibility rather than to maximize performance.
Our recent tests have shown that table conversion to a better database engine available on our servers, InnoDB, yielded up to 200% speed improvements for some sites’ front ends (1/3 the response time for some resources). But some sites did not have noticeable front end speed improvements.
Given Google’s affinity for speedy sites, this should have a positive impact on SEO.