Fix the Performance of a Slow WordPress Site

A few weeks ago Ndevr began a new relationship with a Denver based client, 303 Magazine. Typically clients come to us with either a redesign, re-platform, or HELP! type project in mind. They were in the latter category, with hopes to do a redesign in the future after the performance issues were resolved. Shortly after our initial conversations we took over support and maintenance of the self-hosted (AWS) site and put plans in place to fix the performance issues and migrate them to Pantheon.

This post will be the beginning of a series over the next few weeks as we continue to improve existing site functionality even beyond just performance improvements. We will start with stabilizing the site.

Gathering Performance Metrics

Prior to even beginning our engagement we had their team install New Relic on the AWS servers to begin collecting metrics, which we could use as a baseline later. We could tell nearly immediately the issues were within the theme, and gaining access to the code and content confirmed this. If you’ve never used a tool like New Relic, it essentially slices up your application among areas like database, application code, external requests and others. Here are two of the graphs we saw:

transaction times for 303 magazine performance from New Relic

Metrics from New Relic for 303 Magazine Database Performance

Gaining Access and More Metrics

Now the fun begins, we get the keys and of course the responsibility to make some adjustments. Looking back through New Relic we could see an extremely large amounts of queries per page load as in over 1,000. I’ve been building Drupal sites for a while, and that number even shocked me! So our next step was to get the site running in a local environment to ensure our changes could be validated before we made any on production. Did I mention we only had a production server to work with, which is why our next post you’ll see our steps to migrate to Pantheon.

We identified one of the main culprits to the database queries was a call to get_pages, which for basic sites this wouldn’t be an issue, but this site has over 1,000 ‘pages’ and over 100,000 posts. Later in the code it loops through the $pages and does a query for each page (hence the 1,000+ queries/page). The happy graphs after looked like this:

FREE PERFORMANCE CHECKLIST Your site performance checklist to help you assess your website health   

303 Magazine New Relic Database Graph After Performance Improvements

303 Magazine Newrelic Transactions After Performance Fix

303 Magazine Database Improvements

Still Not as Performant as We Would Like

This was a huge improvement, and amazing things happen when your site becomes faster (and stable)… if you build(or fix) it they will come. Traffic continued to increase after our fix and then of course other issues were also identified. The theme’s use of a mega menu with “latest” and “random” functionality likely worked great for sites with hundreds of posts, our post table had over 100,000 entries though. Ndevr added some transient cache calls around the menus to alleviate the unnecessary calls on every page load. This change brought database queries from 2-300/page down to around 70.

Next up we move the site over to the managed host Pantheon. Unfortunately Pantheon’s pricing for moving a site with over 170G of files isn’t going to work, so the next post will go through how we reduced 303’s footprint to around 20G.

Newsletter Signup

Share