A fast loading site makes more money. That was the main motivation behind site owner Ann Drake contacting me to help her tweak On Sutton Place. Ann is big on Pinterest, where images are everything. She has also acquired several lucrative AdSense accounts.
Her site was running slow and it was costing her money.
The graphics for both Pinterest and ads presented their own challenges with performance. But image optimization was the least of the problems, and not where we started optimizing this site.
What follows is a full case study on the steps we took, and are still taking, to improve the performance and user experience with On Sutton Place.
Before and After
A lot of you will want to know just how much of a load time performance difference was made before you read through the full case study.
So I’ll save you some time and tell you right up front.
Before: 7.62s
After: 0.644s
Okay, now that I have your undivided attention, let me tell you what we did.
The First Step – A Full Site Audit
The process began with a deep Site Audit and Review which revealed the real culprits that were slowing down the site. Those issues are detailed in the section What the Site Audit Revealed, followed by the measures taken to fix them.
Performance Checks
After addressing the major issues with the site, I used a multitude of tools to check site performance between each phase of tweaks and fixes. They include:
Pingdom
GTMetrix
WebPageTest
Monitor.us
Google Webmaster Tools
Google AdSense
Google Analytics
Stats and analytics provided via the host
Four pages were tested throughout, including:
Home page
Blank page (devoid of content, but with all static areas active such as header, sidebar, and footer)
Typical blog post with images using initial optimization techniques
Typical blog post with images using new optimization techniques
What the Site Audit Revealed
I’ve broken the major issues into categories, to help you follow this process, but there is certainly overlap in how each element affected others. Every one of them was a performance hit.
Security
Weak login password
Default htaccess with no additional security to block directory searches
Robots.txt file with incorrect directives for bots
No brute force protection for rapid fire login hack attempts
Inadequate backup solution, with backups held locally
A second WordPress installation that was used for testing and not updated
Plugins
Social share plugin with known security issues
Four inactive plugins
One plugin that was showing as loaded twice in plugins folder
Redirection plugin settings not optimized, causing resource drain
Comments plugin that was resource drain and could be hard coded into theme
Google Fonts plugin that was resource drain and could be hard coded into theme
Load Time
Hosting was slow
Resources such as the CPU, memory, and bandwidth were being drained by bot hits
Database not optimized
Caching plugin that was not optimized properly
CDN that was not optimized properly for itself or in conjunction with the caching plugin
Images not properly optimized
SEO
SEO plugin that was not optimized properly
Authorship not fully optimized
Theme not HTML5 compliant to output schema markup
Pinterest verification tags not properly optimized site wide and causing conflict with SEO plugin
No custom 404 page
Repairs to the Foundation
The first order of business was to remedy the issues found in the site audit. Following are the steps we took for each section.
Security
Password – A super strong login password was created with the following criteria:
At least 12 characters with at least one of each of these – capital letter, number, special character.
(See Protect Your WordPress Website with a Strong Login for more.)
.htaccess – Installed two new .htaccess files to stop bots from running a directory listing of all files.
One was placed at the root of the hosting account.
One was placed in the root of the folder where the site files were located.
Be careful of generic .htaccess file creation help! There are multiple functions you can include in the .htaccess file, and not all of them work on all hosts. Some changes will result in the white screen of death for your site. Best to turn this job over to a qualified geek. If you do decide to poke around, be sure that you make a backup of your current .htaccess file first!
Robots.txt – Installed a properly coded file to tell well-behaved bots what to index and what to leave alone. Ill-behaved bots will ignore the directives and still try to index everything they can on the site. It is still worth setting up properly.
Brute Force Protection –Powerful botnets are systematically attacking host servers via every site on them, looking for any weakness to gain access. The easiest place to penetrate is through the front door, or login, of a site using rapid fire password breaking algorithms.
Botnet attacks happen every minute of every day on every server.
No host is immune to them.
There are two primary methods to protect your site from a brute force attack.
Lock out the hackers after 3 attempts. My favorite plugin for this is Login Lockdown. It’s light-weight and gets the job done.
Stop the bots from getting to the site in the first place. There are multiple ways to do this, including manually blocking whole countries and individual IP addresses. But, one of the easiest ways is to use the ramped up DDoS protection in CloudFlare. More on that in the Performance section.
Read more about the Global Brute Force Attacks on WordPress Sites that happened in April 2012.
Backup – Backups were not getting all files, and the backup files were being stored locally.
Your only real security blanket these days is a reliable backup solution. That includes ensuring all of the files of your site are backed up, not just the database. It also includes storing those files offsite, and an easy way to restore the files. If you’re trusting your site to a free backup plugin that only saves part of the files and stores them locally, then when the site or server is attacked, and the site’s all gone, there is no way to recover it.
Read How to Avoid the Heartache of Losing Your Site that tells the story of just how much it hurts when you don’t have a real backup solution.
BackupBuddy (aff link) is the plugin I use on my site and all of my client sites, because I know who they are going to call if something happens.
Amazon S3 is where I recommend folks store their backup files. It costs pennies a month, and the first year is free.
Get the Guide – How to Backup Your WordPress Site is a free, 11-page report I created with 14 backup solutions rated, and detailed. Plus, the info you need to properly configure your backups.
Abandoned Site – The other WordPress installation on the account was removed. It was once a testing site that had long been abandoned. Nothing about it had been kept up-to-date, leaving multiple security holes that a hacker could easily exploit. Gaining entrance through this one site put the whole account, and the potentially the shared host server, at risk.
Plugins
Plugins are both the pro and con of WordPress. While they can extend the functionality in dramatic and positive ways, they can also come with a high price in security, conflicts, and performance hits.
Social Follow and Share Plugins – One of the worst offenders is in the category of social share plugins. Choosing the right one makes all the difference.
Hard Coded Into Theme - On this particular site, the social follow plugins are hard coded into the site. We removed the Sexy Bookmarks plugin for social sharing, which has had so many security and sneaky practices in the last few years that I won’t touch it.
I’m currently investigating the best ways to add social sharing, and developing a new list of recommendations. My best recommendation is to hard code them into the theme avoids both the security issues with all plugins of this type that use JavaScript, and improves performance by pulling in the images and scripts locally, instead of from an external library.
Hard coding is not the only alternative. There are social share/follow plugins that do not use JavaScript. I’ll have a post with reviews on them soon.
Inactive Plugins – This is one of the biggest security risks. Plugins that are not updated, even if they are inactive, pose a security risk. The four inactive plugins on this site were deleted.
Make sure they are fully removed! Just because you deactivate and then delete a plugin via your WordPress admin page doesn’t mean they are fully removed. Many plugins leave their code in the wp-content > Plugins folder and/or leave tables in the database, or even in the core site files. The worst offenders are caching plugins, calendar or event plugins, and gallery plugins.
Duplicate Plugins – one plugin on this site had two sets of files in the Plugins folder. Special measures had to be taken to remove only one of them without affecting the other. It was the Genesis Simple Hooks plugin.
Reduce Plugins – There were two plugins on this site that provided functionality that would be better to hard code into the theme.
First was a comments plugin. Once it was removed, the special features it provided were hard coded into the site.
The second was for Google Fonts. And those were also hard coded into the theme.
Resource Hog Plugins – Some plugins are absolute resource hogs and cause a big performance hit on your site in both CPU and memory usage, plus calls to the database and other files.
A resource hog on this site was the Redirection plugin. It has a setting for turning off the log files. Having them on was causing the resource drain.
There are still two plugins on the site that are a drain on resources and we are actively testing alternatives on a non-production site.
Other offending plugins that I see commonly used are Broken Link Checker, Pricing Tables, YARPP, NextGen Gallery.
P3 (Plugin Performance Profiler) is one of the best ways to scan your site for plugin performance issues.
More on performance issues is covered in the next section.
Load Time
Slow load times is one of the main factors in visitors clicking away from your site, and that has a huge impact on the success of your business.
See this superb infographic on How Loading Time Affects Your Bottom Line from KissMetrics.
There are many factors that affect the load time of your site pages. Contributing factors from the theme and plugins were covered above. The other big contributors are covered here, and they are common to all sites.
Hosting – No matter how well you optimize your site, sluggish hosting can bring page delivery to its knees. We moved this site to my preferred vendor, A2 Hosting (aff link) because it has blazing fast SSD (Solid State Drives). That alone improved performance.
Excessive bot hits – were over taxing server resources such as the CPU, memory, and bandwidth. The majority of them were involved in a brute force attack mentioned previously in the security section. Most of the rest were comment spam.
CloudFlare DDoS feature was activated – CloudFlare is much more than a CDN. Since the massive botnet brute force attack in April 2012, CloudFlare has offered beefed up DDoS protection, even in the free version. Turning this setting on had a major impact in lowering resource drains on the server, which sped up site load time.
Database – For you to harness the full power of WordPress, it’s important to first understand what it is. The admin pages you see from your Dashboard are simply User Interfaces (UI) for adding and editing the content in a database. Every time a visitor to your site requests a page, they are actually sending a query to that database for the content.
Optimizing the database is one of the
best ways you can keep your site loading fast!
Things that gunk up a database include:
Comment spam
Too many post revisions
Trashed posts and pages
Unused tags
Orphaned tables from unused/deleted plugins
There are multiple ways to clean up and optimize a database, including several plugins. However, since this site had 2,200 spam comments and several orphaned tables from plugins that had not come out clean, I opted to manually clean the database. Note: you’ll want to leave that job to a qualified geek.
Backup your database before you do any database optimization.
Delete Comment Spam – In the revamped version of the WordPress Dashboard (since version 3.8), the number of spam comments on your site may be a little harder to see. They are now listed at the bottom of the At a Glance module.
The good news is, deleting spam comments en masse has become much easier. Go to your Comments admin page. At the top, you’ll see a new button to Empty Spam. Click it and they are all gone.
Stop Spam – There are several ways to combat comment spam. The first line of defense is to use the Akismet plugin. Then add a plugin to enhance what Akismet does. Two such plugins are G.A.S.P and Bad Behavior. (Use one or the other, not both.) I personally prefer G.A.S.P. and added to the site.
Lack of CAPTCHA – Bots not only hit blog comments and leave spam, they also hit the contact form. While it’s a nuisance to field all of that spam email, the bigger issue is the performance hit the site takes from all of that bot traffic.
The easiest way to combat the issue is to include a CAPTCHA field on the form. This client site uses Contact Form 7 so I added a CAPTCHA field. It’s very easy to do.
See the WordPress Advanced Video Tutorials for how to create and customize a super contact form with Contact Form 7.
Limit Post Revisions – WordPress has made major advances in how it auto saves the pages and posts you are creating so that you never lose all of your due to connection issues. While that’s great, all those revisions gunk up your database.
The easiest way to have your cake and eat it too is to let WordPress continue to make those frequent auto saves, but limit how many of them stay in the database before overwrite.
Hard Code Revisions – In an effort to further reduce plugin load, I hard coded this option into the core files, specifically wp-config.php. This is a job that you’ll want to hire a qualified geek to do.
Revision Control is the plugin I recommend if you don’t want to hard code the limit. After installation, go to Settings > Revisions, and set the Default Revision Status to 5 for both pages and posts.
Trashed Posts and Pages – You may not have a lot of this gunking up the database, but they do need to go, else they could cause another issue. When you delete a page or post out of the list, that’s exactly what happens. They come out of the list on the respective admin page. But, they don’t come out of the database. So, if you try to create a new page or post with the same title, it will have a -2 at the end.
Go to the Page or Post admin page, and look for the Trash link. Click it and you’ll see a list of all the ones still sitting in your database. Empty that trash by permanently deleting them. You’ll need to do this from both the Page and Post admin pages. They are two different lists.
Unused Tags – Some site owners created a bunch of tags they intended to use, but never did. Those create tables in the database. Be sure to delete any that are unassigned. You’ll find them under Posts > Tags.
Orphaned Tables – This is a big factor in a sluggish database. There are many ways to clean up tables that are no longer attached to anything or being used. But be careful.
The best way to remove orphaned tables is manually. That’s what I did on this site. It’s a job you’ll want to have a trained geek do. There are plugins that do it, but a few of them may delete tables you still need, and once gone, they’re gone.
Optimize the Whole Database – After all the cleaning was done, I optimized the entire database manually. There are also plugin options. Some are more aggressive than others.
WP-Cleanup is one of the safest and easiest to use plugins for optimizing the database. Be careful. There is another plugin with the same name, but without the hyphen. Be sure you get the right one.
Caching
A huge factor in site load time is making the data files smaller, for faster delivery. One way to do that is to cache the files. There are two different ways to cache. One is object cache, and the other is mirror caching.
Object caching is handled by local plugins like W3 Total Cache.
Mirror caching is handled by a CDN (Content Delivery Network) like CloudFlare.
Both types of caching have overlapping features, so it is very important that they are optimized to be used as a standalone option, or in conjunction with one another. I used both on this site and optimized them that way.
I’ll have another post with the exact settings I used, plus a full report on the performance effect of each.
Image Optimization
When images are the story – On Sutton Place has a BIG following on Pinterest, and images are an extremely important part of the site. Images that were not properly optimized were one of the biggest performance issues.
Ann takes her own pictures and uses several image processors to create the final version that is uploaded to the site. We had a live session together so I could see her process and make suggestions about how to better optimize the images prior to saving them.
Then, we checked into ways to further optimize them after uploading them to the site, including more compression techniques, progressive scans, lazy loading, and caching. We’ve made significant improvements and are still testing for even more ways to optimize the main images without losing quality. I’ll have the full report in another post.
Images in static areas – Images in the post aren’t the only ones being delivered on each page load. Images in static areas, such as the header, sidebar, and footer, are also part of the page. We’ve made significant improvements to those images as well, including deleting some that had little to no ROI factor, in favor of keeping all of the money-making images for ads.
SEO
Although the basic SEO on the site was mostly optimized, there were several areas for improvement, including with the theme and authorship.
Theme SEO – Since WordPress 3.6 and Google’s sudden change to prefer and promote semantic markup, themes that are not HTML5 compliant are not worth having.
For more, read my Microdata and Genesis Series.
The very first thing that needed to happen was getting the theme converted to output HTML5. We sent it back to the original designer for that.
SEO Plugin – Next, a plugin was being used for Pinterest verification that was causing a significant conflict with the WordPress SEO plugin. Fortunately, Genesis based themes have a super easy way to add Pinterest verification without at plugin.
Read Verify Your Website on Pinterest with Genesis
Once the offending plugin was removed, the settings in the WordPress SEO plugin could be properly optimized.
Authorship – To set up basic authorship, a triangle must be connected between the G+ personal profile, the site home page and the author’s About page or author archive page. In all, there are actually 14 possible connections that can be made to fully optimize authorship. All of them were set up on the site.
See the SEO and AuthorRank Video Course for more on how to properly configure and optimize the WordPress SEO plugin and authorship for your site.
Custom 404 page – Although it is not a huge ranking factor, a default 404 page is a real turn off to site visitors. Ann designed the content for her custom 404 page and the default template for that page was replaced in the theme.
Conclusion
It should be clearly evident just how many factors impact site performance. It’s important to get a whole picture of all areas of the site before making any changes, and then measuring each change for effectiveness.
Significant improvements were made each step of the way and we’re still tweaking.
The Google AdSense rating for this site was raised from 3 to 4, and we know exactly what is impacting the site that keeps it from going all the way to a 5, which is the top. And, it’s not just load time.
I’ll be updating this case study as more changes are made so you can follow the progress.
Site Audit and Review
We do it live and you see what I see.
Or go deeper with a full performance review too!
You're reading Improve Site Performance Case Study – On Sutton Place, originally posted on BlogAid - WordPress for Non-Geeks and copyrighted by MaAnna Stephenson.
Chat with MaAnna on Google+ | LinkedIn | Facebook