This presentation was originally given at WordCamp Slovakia 2013 in Slovak Technical University on 20 April.
Story of WordPress is similar to other successful Content Management Systems. Increase of functionality, frameworks, template and other support functions.
With WordPress development comes a huge increase in source code size. In 5 years the source code is 4 times bigger. Source code size also goes hand in hand with bigger memory consumption, which also increased about 4 times.
It doesn’t end with source code and memory consumption. There’s more data to be stored in Database tables. Bigger community that creates plugins, themes and theme frameworks.
To optimize WordPress for speed, one has to understand at least basic inner workings of HTTP request.
Choosing a correct web server is also very important. Apache with default configuration proves to be unusable. Commercial LiteSpeed offers professional help with setup from developers. NginX on the other hand is one of the event-based alternatives to these process-based web servers like Apache and LiteSpeed. But every web server needs to be tweaked to perform optimally for a website. There is no optimal universal configuration.
Most of WordPress websites contain many images, JS, CSS, which means that the web server will be serving many flat files. With caching enabled, requests that need to be processed with PHP will seldom come.
One of the most important speed optimizations is caching of WordPress pages. There are multiple solutions available.
HTTP Accelerators like Varnish sit in front of web server and cache output for specific requests. Next time that the same request comes, Varnish will send to the browser the stored output so the request will never reach the web server. Saving web server the time needed to process the request.
Other option are direct WordPress caching plugins like W3 Total Cache, WP Super Cache and Hyper Cache. Every one has it’s advantages and disadvantages. W3 Total Cache offers many features, but is too complex. With new WP versions launching all the time you find W3 Total Cache breaking many times. WP Super Cache support was discontinued after the developer just wasn’t able to keep up with WordPress. Hyper Cache is the simple one, but very reliable. Our tests even showed that even in PHP mode it outperforms WP Super Cache running in htaccess mode. Hyper Cache KISS principle pays off.
Still, even caching by HTTP Accelerator and WP caching plugin still requires to refresh the content from time to time. On the other hand some content on the webpage doesn’t need refreshing for a long time. Here you can start to cache just some parts of the page, like menus and sidebars that have less dynamic content than the rest of the page. CDN should help to better distribute the static data, but has it’s own cumber-stones. Using APC or some other PHP Accelerator also improves the speed of request processing. Using external services, may create unnecessary HTTP requests which may slow the loading times on client side. Good example is Gravatar Cache plugin that stores gravatars, so the browser doesn’t have to make a request for every comment with gravatar.
Speeding up WordPress doesn’t end with just putting more tools to it. Huge part is optimization of plugins and theme. There are many plugins available to download for free or buy. They may contain nasty pieces of code that may break your site performance.
Every plugin developer should study WP API, so he’ll not abuse it, go against it. KISS principle proves to be very useful when designing fast plugins. Every plugin interacts somehow with WP, cross interactions between different plugins are not uncommon. These may have negative impact on performance. It’s good practice to use native WP functions, since they are coherent with each other. Not abusing other resources like Database is also important.
Every theme wants to be unique, so testing and optimizing it is also very important. Using database profiler to reduce number of queries or optimize the ineffective ones. Reducing number of CSS and JS files. Making sure ineffective WP functions get called will only the needed content. These all help to reduce the load time of the web page.
Database profiler may show you problems you don’t notice just by looking on the site.
Choosing correct database engine is also important. The decision is highly website to website dependent.
- InnoDB pros:
- Better data integrity, support for transactions
- Quicker insert and update of data
- InnoDB cons:
- Tables don’t store rows count
- Memory requirements
- No full text indexation
- MyISAM pros:
- Simple engine and overall quickness
- Has full text indexation
- Quicker for select
- MyISAM cons:
- Bad data integrity, problems with database crash
- Row data stored in whole
WordPress Database structure is not entirely optimal. Posts table tend to store to much data that doesn’t need to be there (menus, revisions, custom posts). Comments table stores spam for instance.
Magical word EXPLAIN in MySQL may help to find flaws in bad database design. Choosing correct indexes is very important for fast selects.
Download this presentation here.