Site Speed Optimization Case Study

WordPress Site Speed Optimization Case Study –

site speed optimization case study use of cache plugins is one of the most preferred choice by most of the WordPress developers. They love to install, activate and configure these cache plugins to the best of their knowledge for optimizing their websites. Some developers use Quick Cache plugin, some use W3 Total Cache plugin, while some developers use any of the other cache plugins for speeding up their WordPress sites quite easily.

In this site speed optimization case study, we not only tried and tested many cache plugins, but also tweaked some of the core configuration files for optimizing our site for speed. Let us walk through a step by step guide to understand the complete wordpress site speed optimization process using our case study site.

Step 1 : Initial Diagnosis and Site Backup Before Beginning Site Speed Optimization

The initial diagnosis of our case study website gave us a clear hint that it was not an easy server and was going to give us a hard time. As usual, we had our own ways to reach to the bottom of this WordPress Server and got it running well after infusing all the required elements to speed it up.

The website was using W3 Total Cache plugin. We started our WordPress site speed optimization process by taking a backup of W3 Total Cache settings so that none of the original configuration settings are lost during our WordPress website speed optimization case study. Once the backup was taken, W3 Total Cache was disabled. We wanted to bypass it and tweak the configurations at a much deeper level.

“Make it a thumb rule to backup your settings before tweaking anything on your WordPress site or blog.”

Step 2 : Check Whether WordPress Server Allows Tweaking

No configuration changes could ever take place, unless and until the server allows us tweaking. We need to check the server to ensure that tweaking is allowed. Different servers have different settings, thus this step is more about understanding the server; what is allowed and what is not allowed.

php.ini file was tweaked with the following line

zlib.output_compression = on

One new file mark.php at was added to ensure that php.ini is working.

zlib.output_compression = off

It means the server is not allowing us to tweak or configure anything at all.

Step 3 : Prepare The Server for Speed Up Configuration Changes

Our next target was to prepare the server so that it allows tweaking. It must allow some changes in the configuration settings, so that we can enhance the server’s speed performance for the site. The following configuration changes were done by editing wp-config.php file.

define(‘WP_POST_REVISIONS’, 6);
define(‘WP_DEBUG’, false);
define(‘WP_MEMORY_LIMIT’, ‘128M’);
define(‘WP_MAX_MEMORY_LIMIT’, ‘256M’);

After the above mentioned configuration changes, the server was checked and we found that it was working great and allowed to make some changes in the server configuration.

Step 4 : WordPress Tips and Tricks For Optimizing Site Speed

WP-HTML-Compression utility was added, but was deactivated. The following lines were also removed from wp-config.php file

define(‘WP_MEMORY_LIMIT’, ‘128M’);
define(‘WP_MAX_MEMORY_LIMIT’, ‘256M’);

WordPress Gzip Compression utility was added, but was deactivated.

WP Super Cache plugin was installed and activated for further configurations and tweaking.

We configured and tweaked this cache plugin to check for any site speed optimization gains. Unluckily, it didn’t worked out and we noticed that the server was too slow, even after using the WP Super Cache plugin due to some server limitations. It required some deeper level configurations and tweaking. WP Super Cache plugin was deactivated and removed.

W3 Total Cache plugin was activated again because we wanted to configure and check the site performance gain by using this cache plugin.

Step 5 : Remove All the Unimportant Blocking Widgets

Each and every widget comes with an overhead expense. It eats up many resources on the server, thus all the widgets must be carefully chosen. Analysing the site, we found a Twitter widget form in the footer and realized that is was consuming lots of computing resources of the server. It was pulling the site speed down. The Twitter widget form was removed.

“Only use the plugins, which are actually required.”

Step 6 : Optimize the Site and Clean Database

Coding a site and optimizing a site are entirely two different things. Coding is all about making the things work, while optimizing is all about ensuring that everything is working in the most efficient ways. An optimized site must be clean. It means concatenating styles, scripts, minify, compress, adding expire headers and several other functions performed on the site. Cleaning the database is also important so that no loopholes are left behind in the database that may pull down the site on site speed optimization factors.

We used Autoptimize plugin for site speed optimization and checked the performance reports. It gave us positive results. We also gave the DB a fast clean up.

Step 7 : Optimize Images to Reduce Server Load

We checked the site for performance and got the following report at GTMetrix.

GT Metrix Site Speed Report

Analysing the report, we observed the following values:

Page Speed Grade : (81%) B
YSlow Grade : (85%) B

Page load time : 3.02s

Total page size : 452KB
Total number of requests : 44

We realised that the report displayed
red mark on Optimize Images.

The Optimize Images performance score was quite low at E (55), thus needed some tweaking
in order to fix it.

Many image optimization plugins are available for WordPress. We installed EWWW Image Optimizer to optimize the image for our case study site. Two operations were performed to optimize all the images on the case study site:

  1. Bulk option for optimizing all the content images.
  2. Optimize theme image option for optimizing the images used by theme.

Ewww Image Optimizer plugin turned out quite heavy on the server, but it worked well for image optimization. It is a good idea to run it occasionally for optimizing images on the websites or blogs to gain some site speed optimization results.

Step 8 : Check and Fix Robots.txt

Search engine visibility is entirely dependent on the robots.txt file, therefore a proper scanning and fixing of this file cannot be compromised at any cost. We found the following entries in the original robots.txt of our case study site.

User-agent: *
Allow: /

The file was edited with the following structure:

User-agent: *
Disallow: /wp-admin/
Disallow: /wp-includes/

In order to check the content of your robots.txt file, you can use an on-line robots.txt content checker tool at

We used the same tool and noticed that it passed our requirements.

Step 9 : Some More Tweaking for WordPress Site Speed Optimization

We checked our case study test site at to analyse it further. It helped us diagnose some other problems, so that it can be fixed in order to attain site speed optimization at its best.

  1. The report mentioned that our case study site didn’t supported gzip compression. We fixed the gzip compression by tweaking the server and checked the report again. It confirmed that the gzip compression was now working.
  2. We got on and set the limit as 5 by changing its previous value of 10. The existing value of 10 didn’t made any sense to us, so we made it 5.

The site was rechecked at and we noticed an overall improvement in the case study site test report results.

We checked our test case study site at and noted down our observations for further improvements.REDbot site speed optimization report for sweet beats

Step 10 : ZENDESK Tweaking

We moved ZENDESK from the theme file to

<!———- ZENDESK ASK TAB SCRIPT added 2013-07-09 Sam –>

<script type=”text/javascript” src=”//”></script>
<style type=”text/css” media=”screen, projection”>
@import url(//;
<script type=”text/javascript”>
if (typeof(Zenbox) !== “undefined”) {
dropboxID: “”,
url: “”,
tabTooltip: “Ask Us”,
tabImageURL: “”,
tabColor: “#183f5e”,
tabPosition: “Right”


The above mentioned configurations helped us achieve faster loading time for the home page.

Autoptimize plugin had to be disabled so that the buttons can function properly.
Checking the performance reports, we realized that the page load time was bad and needed some further tweaking and configuration changes. Next, we worked on Ask Us button.

Step 11 : Configuring and Testing Cache Plugins

Now, we wanted to use W3 Total Cache Plugin for cache operations.
We activated the cache plugin and configured it with the following settings:

Turned off Minify
Turned off Database Cache
Set Page cache: to Disk
Turned off Page cache

All the test reports were rechecked. In order to understand the test results better, W3 Total Cache was disabled and replaced with Quick Cache plugin. Some configuration changes were made and the test result reports analysed once again.

Now, the results were quite positive. It also displayed the responsiveness of the case study site.

Step 12 : Re Analyse the Reports for Further Improvement

Let us have a look at Pingdom Test Report

wordpress site speed test report pingdom sweet beats

Pingdom Test Report

Page size : 794.0kB
Load time : 2.69s
Requests : 49
Perf. grade : 83/100

Your website is faster than
57% of all tested websites

Let us have a look at Webpagetest Report

Web Page Test Site Speed Optimization case study ReportPageSpeed 1.12 Score: 65/100

A First Byte Time
A Keep-alive Enabled
F Compress Transfer
B Compress Images
F Progressive JPEGs
A Cache static content
X Effective use of CDN

Let us have a look at GTmetrix Test Report

Site speed optimization case study test on sweet beats

GTmetrix Test Report

Page Speed Grade:(67%) D
YSlow Grade: (82%) B

Page load time: 3.15s

Total page size: 719KB
Total number of requests: 44

The test results for our case study site were also checked at to gain detailed insights for site speed optimization performance.

Step 13 : Some More Site Speed Optimization Tweaks Needed

Bulk WP was used for optimizing images, but didn’t fetched any improvement because all the images were already optimized. Since, there was no further scope left for image optimization with WP, it was removed and we tested the server once again.

We also removed Zendesk Contact Form from the home page. The website speed optimization test reports turned out better than before.

We successfully accomplished our mission of speeding this case study site, even when it was hosted on one of the hardest to crack servers.

A Comparative Study to Analyse Site Speed Optimization Results

GTmetrix site speed optimization case study reportCase study test result report at GTmetrix.

Report Highlight: Optimize images B (85)

Now, images are fully optimized, so we removed EWWW Image Optimizer.
Our case study site test result reports are looking good and the server is also responding well.

Site Speed Optimization Case study Test Report at GTmetrix.

GTmetrix final site speed optimization case study report

Factor Before Optimization After Optimization Result Gain
Page Speed Grade 61% (D) 66% (D) Improved 8%
YSlow Grade 66% (D) 83% (B) Improved 26%
Page load time 4.15 s 2.81 s Improved 32%
Total page size 770 kB 697 kB Improved 10%
Total number of requests 77 38 Improved 51%

Now, we can see an overall improvement as compared to the previous values.

It is important to note that all the servers can’t be maximized for site speed performance, but it can be optimized to attain better performance than before. Every server has its own limitations and it might not be possible to bypass all the limitations under all the given situations.

Site Speed Optimization Case Study Test Report at Pingdom.

Pingdom website speed optimization case study test result

Factor Before Optimization After Optimization Result Gain
Page size 857.7 kB 769.9 kB Improved 10%
Load time 4.04 s 2.63 s Improved 35%
Requests 82 43 Improved 48%
Perf. Grade 61/100 90/100 Improved 48%

Your website is faster than 58% of all tested websites (Earlier it was 39%) Improved (Gain of 49%)

Site Speed Optimization Case Study Test Report at Webpagetest.

Wordpress speed optimization case study Webpagetest Report

Factor Before Optimization After Optimization Result
First Byte Time A A Neutral
Keep-alive Enabled A A Neutral
Compress Transfer F F Neutral
Compress Images B B Neutral
Progressive JPEGs F F Neutral
Cache static content F A Improved
Effective use of CDN X X Neutral

In this report, Cache static content jumped from F to A.

Final Result on Site Speed Optimization Case Study

Overall, great site speed performance case study achieved after doing all the configuration changes. The server didn’t allowed to turn on Zlib Output Compression. Had the server allowed WHM on the VPS, some other minor problems would have also been fixed. We understand that every server comes with its own limiting factors, thus we cannot achieve absolute 100/100 speed optimization score for all the sites. Although, we can always improve the performance on a relative scale.

Considering the bottlenecks of the server design, the site speed optimization case study site is fully optimized for speed and better loading time performance. Now, we can say that the site is fast and responsive. Our case study site has been fully optimized with all the possibilities exploited entirely.


Hosting platform is quite important for speeding up any WordPress site. It offers a playground to us (speed optimizers); wider is the field, better are we at optimizing site speed. Based on Mark de Scande‘s WordPress site speed optimization skills and experience, we personally recommend WP Engine and WP Engine as two great hosting platforms. They offer full potential to speed up the sites hosted on their servers.

Website Speed Optimization Case Study Details
Website –
Web Host Server – Digital Pacific
Site Speed Optimizer – +Mark de Scande
Editor – +Ashutosh Kasera


WordPress Site Speed Expert, Speeding up WordPress sites across the Globe

I am the fuel behind the high speed of innumerable fast running wordpress websites hosted either on a cheap server or a dedicated server.
Today, Speed is a matter of great concern, and I don't only optimize but re-energize. I am also a lifetime WPMU Dev member.

One of the largest free blogging websites BlogLines in South Africa is my baby. I not only conceived the idea of free blogging in South Africa, but also implemented it with an objective of adding a new dimension to the world of free blogging. Blogging helps us in enhancing the quality of our social life by transforming the ways in which we share our ideas and opinions with each other. South Africa blogging environment has never been so easy and user-friendly as it is today.

I have practised and learned all the technical aspects related to WordPress. In the past couple of years, I have developed a wide range of websites using WordPress, WordPress MU and now using the latest WordPress MultiSite.

I am the WordPress Speed Energizer Wiz, and I am always hunting around to find slow running websites. I know, these websites need me in order to live a long and healthy life.
Only the wordpress sites powered with speed, capable of running at full throttle are going to survive in this tough and competitive world of Internet.

Need my help but can not afford my hourly rate buy me coffee and i will do a full report on your website.

    Follow Me:
  • facebook
  • flickr
  • googleplus
  • linkedin
  • pinterest
  • twitter
  • youtube
  1. Mark De Scande BlogLines
    Mark De Scande BlogLines12-23-2013

    Super Cool Post

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.