Background

Affiliate traffic is dependent on SEO. Google considers site performance a major ranking factor. So we make sure our affiliate sites load quickly.  We provide hosting performance and Amazon audits. This is something we are familiar with. Well wasn’t I embarrassed when I reviewed our customer-facing site Rapisite.com. It turns out, I was the shoeless cobbler. The site was taking 4-5 seconds to load. Upon closer inspection, I found we had a 2600ms (2.6 seconds) Time to First Byte (TTFB). So we were starting above my target site loading time! This became my weekend priority.

What is TTFB

So what is TTFB? When someone puts the url to your homepage into their browser, a number of things must happen before you even START to get data. This is the TTFB. WordPress is called, plugins are loaded, the database needs to assemble content etc. TTFB is the time it takes from a request, for your url till you start sending the first response header. A couple of years ago, Moz did research to see if page speed correlated with Google rankings. They found no correlation with page speed but some with TTFB. It is hard to draw a conclusion from one small study and correlation does not equal causation. So I view TTFB as a hint for where to look for page loading issues.

I could have emailed one of the engineers but I wanted to see how far a semi-technical, affiliate site owner could get. I wanted to understand the parts that would affect site speed for myself. Using Pingdom as my measuring tool I set out to fix my site. Much of this is covered in our detailed guide to Building Affiliate WordPress sites. I will be adding some more details to that guide from this case study.

DIY Website Performance Tuning

Steps to Improve Performance

Here are the steps I went through:

      • Backup. That goes without saying.
      • Checked that the site was in Cloudflare CDN – it was.
      • I checked every plugin that was active. Did I need it? Things like maintenance mode and other utility plugins do not need to be active all the time. You can activate them when you need to use them. I was able to deactivate 5 plugins. The resources from the deactivated plugins would now not be loaded when the site was visited.
      • I went to the homepage and opened the console in developer tools. In Chrome, this is more tool -> developer tools from the inverted ellipse menu in the top right corner. In developer tools, I found a few error messages. The red items are errors. I had a couple of 404s to files being loaded from the header.php or other PHP files. These were easily dealt with by copying the files from the parent theme to the child.
      • I checked all the size of the homepage graphics. It was bloated with some large images. These were being called from a directory that had not been “smushed” and for some reason, the designer used very large .png files for some of the photographic images. I opened all the images in Photoshop and saved them as jpeg. I compressed at the medium setting to maintain high-quality. This reduced the overall page size by ~20%. If they were background images I would have reduced theme more aggressively.
      • A recheck after cleaning up the site showed the page load speed had gone to 3.5 seconds with the TTFB still a very high 1850ms. 3.5 seconds is not horrible, but I wanted better. I knew this was not a typical response for my server so I was hopeful I could get below 1.5 seconds by finding the long TTFB  cause.

A quick way to see all of your php settings is to create a filename.php file in your public_html directory that has the following in it:
<!--?php
phpinfo();
?--
>
Then yourdomain.com/filename.php to call it.

    • Now I needed to dig a bit deeper. I wanted to now check the server and WordPress optimization:
      • PHP version – Run PHP 7.  No reason to still be using 5.x (there was no V6.x). You can check with multi-phpini on your C- panel or whm lets you check as well. Check them both. Check with your hosting company.
      • Apache settings – I fired up a chat window to Liquid Web support. They are the best. I told the agent my concerns. We walked through checking error logs, Apache config issues. Php.ini settings. .htaccess settings. I found a plugin I no longer use had “optimized” my .htaccess file. I won’t name names. I removed their changes and left my redirects and the standard WordPress items. php.ini was fine. There was nothing of interest in any error logs.
      • Cache Settings -On the WordPress backend I use the free W3 Total Cache. I enabled Page Cache, Object Cache, Browser Cache, and Database Cache.
      • Minify – When you minify an object you are removing all the spaces. Spaces are useful to let humans read text. They are overhead for computers. I use the free Optimize plugin to minimize CSS Javascript, and HTML.
WordPress Site Performance Improvement

Results

The good, no great news, the load time was now < 1 second and the TTFB was 220ms. Rapisite is now a very well performing site. This was hardly a controlled environment. It was more of a best practices baseline project after a number of changes were made. It does show you what can happen over time with extra plugins and other bloat.  I am sure that a network engineer can squeeze another 10-25% of performance gain out of it. But for customer experience and SEO these numbers are great.