Two years ago when we completed our third pivot of this site we thought 900 ms for a primary landing page was fast. Since we serve content with a large number of images, inside pages were an issue. But we accepted and acknowledged that given our content rich focus our best shot at page speed was breaking 10 seconds the first time a page was loaded on a user browser. After all if you were going to spend the next 30 minutes deciphering the secrets of quantitative finance on our site, how could another 10 seconds hurt?
This weekend we brought the primary landing page down to 185 ms. The inside store pages that serve our computational finance shopping catalog to under 600 ms. The really content heavy inside pages ranging between 1.25 – 4 seconds. It is only when you see the site load on a nexus 5, an iphone or an iPad that you realize what a beautiful thing site speed is. Here is the story of how we got here.
Some History.
It took a while (4 years) for us to figure out that the only way to beat the competition in our game is speed. What was considered acceptable in 2012, is no longer current in October 2014. While content is king, without speed it is just as bad as being served across dimensions with a badly tuned teleportation device.
For us a site revamp was long overdue and so was a server rebuild. We picked up a lot of clutter (some by design, some by accident, some as pharma hack spam) as we played around with tools and it was time for a clean up before the fall traffic surge hit us.
This September we finally sat down and set our selves a few juicy targets.
- Break 200 ms on our primary landing page (FinanceTrainingCourse.com). Done see above.
- Break 4 seconds on average on inside pages with an average page size of 2Mb. (Financial Risk management case studies). Done see below.
3. We run an ECWID based shopping store and cart. Break 2 seconds on the inside pages within the store. (Financial Training Store). Done
Fortunately for us the world has taken a great leap forward when it comes to disclosing speed hacks for your word press sites. A few days of bedtime browsing showed that a true speed hack needed multiple areas of focus. In order of importance, for WordPress page speed optimization, these areas were:
- WordPress page speed optimization fixes.
- MySQL database optimization.
- WordPress wp-config hacks.
- Apache tuning and optimization.
1. WordPress speed fixes
Of the four WordPress page speed optimization is the most well documented and easiest to implement. Tools like Yahoo’s YSlow, Google’s Page Speed Insights and Pingdom are a great starting point that cut out the work you have to do to speed up your WordPress implementation.
Most of the work can be handed off to off the shelf plug-ins and CDN’s such as Cloudflare or MaxCDN. Beyond using a CDN, the biggest uptick in speed comes from a collection of rules that include using gzip compression, minify, browser caching, reducing DNS lookups and http requests.
The second big win within WordPress page speed optimization is the theme. If your target audience uses smartphones and tablets to access your content you need a responsive theme. There is no other choice. If you don’t have it up and running, bite the bullet and switch. It is well worth it.
2. MySQL database optimization.
The best thing that happened to us was finding Prelovac’s WordPress optimization bible. It became a perfect starting point and a few well placed keyword searches led to some interesting counter opinions.
The MySQL database optimization requires a few fixes. In the sequence we used, they were:
Turning off post revisions. Over four years, the twelve hundred plus posts we wrote generated ten thousand plus rows in wp_posts table and another forty seven thousand rows in wp_postmeta table. Together the bloat generated by revisions took our MySQL database size to over 100Mb.
A clean up of post revisions brought the wp_posts row count down to 3,000 and wp_postmeta rowcount down to 37,000. The smaller leaner database was a significantly more manageable 30 MB. One word of advice, don’t run the a,b,c delete query. There is more to cleaning up revisions data.
Using Table Optimization. Using PhpMyAdmin you can easily optimize and maintain MySQL tables to reduce table overheads that add up with usage and age.
Tweaking Query Cache and Tuning parameters. While you can directly update my.cnf configuration, phpMyAdmin gives you multiple tools to test and update your MySQL db parameters on the fly.
The most significant impact comes with system variables that control query cache. Query cache limit, query cache size, query cache min res unit.
The challenge is that you can’t just run with the set suggested on a post on the web. Optimization requires some trial and error and fair bit of monitoring based on the profile of the site you run. To find the best fit you have to run experiments for 24-48 hours and see how the cache degrades.
James Hayden has a great piece that explains why tweaking your cache parameters is a must and is not a one time job. If you run your own servers, tools like mysqltuner provide additional tuning information once you have had a chance to run the service for a few days. And it is always a good idea to go look at system variables or run the DB adviser to see if there is anything that is in need of a quick fix.
3. Wp-config hacks.
There are three that matter in terms of speed. The first is increasing PHP Memory. The second is turning post revisions off or limiting them to a reasonable 3. The third is turning WP internal object cache on. See WordPress configuration tricks for more details.
4. Apache tuning and optimization.
By the time you get down to Apache tuning, bulk of the optimization work is already done. Theme Foundry has great posts on the minimal settings you need to change to tune Apache for WordPress.
And that is it. That is all that it took us to meet all of our page speed goals listed above. Once the R&D and testing was done, the exercise took a weekend to deploy and test on a backup server and then took just under an hour to roll out on our production environment.
Was it worth it? Here is what I would suggest. One interesting test of whether your site speed experiment was successful is to keep an eye on Googlebot crawl statistics on your google webmaster page. Since we rolled out the changes, interesting things have been happening to those graphs. It is too soon to pass a verdict but let’s see what the next few weeks bring.
For now, we are just happy that our pages load amazingly fast on smartphones and tablet on 3G and LTE networks. That is rewarding enough.
Give site speed a spin and witness it for yourself.