WP Speed Optimization Case Study
In the series of our WP speed optimization case studies, we are back with another WordPress speed optimization case study. I am going to explain the entire speed optimization process performed on one of my client’s website. The site is hosted on Site Ground. As I have mentioned in all my previous WP speed optimization case studies, taking a full backup of your site before making any changes is highly recommended.
I have also written down the entire procedure of taking a full site backup in WordPress Speed Optimization Guide – Part 1. Once full site backup is taken, you can move ahead with rest of the steps required to optimize a WordPress site for speed.
Site speed analysis to understand the current site speed rating is the first step towards site speed optimization. It helps us understand and list down all the site speed limiting factors responsible for slowing down the site on speed meters. Diagnosing site load speed factors which are responsible for high page load time is quite crucial towards achieving fast loading websites. The first and the foremost observation was the slow slider. It was noticed manually even without using any speed test.
Some widgets on certain pages/posts looked out of place and the web host server appeared to be quite slow with the manual inspection of the website. Manual inspection is good to observe certain speed limiting factors but most of them can be detected only after running a couple of site speed tests. Let us have a look at some of the most prominent site speed tests. We will also perform a detailed site speed report analysis to understand the scope of site speed improvement.
Next, the website was tested on GTmetrix to dig other speed hogging factors responsible for increasing site load time. GTmetrix speed test returned the following score.
Page Speed Grade: (88%) B
YSlow Grade: (66%) D
Page load time: 2.84s
Total page size: 2.27MB
Total number of requests: 55
Looking at the details of the GTmetrix speed test report, I listed out the following site speed factors which need to fixed to improve site load time.
1.1.1 Site speed factors to improve Page Speed Grade
- Leverage Browser Caching
- Serve Scaled Images
- Remove Query Strings from Static Resources
- Optimize Images (including theme images)
1.1.2 Site speed factors to improve YSlow Grade
- Add Expires Header
- Make fewer HTTP requests
- Compress components with gzip
- Use a Content Delivery Network (CDN) (Read Impact of CDN on Page Load Time)
- Configure entity tags (ETags)
- Use cookie-free domains
On testing our case study site on Pingdom Tools, I got the following score.
Page size: 2.2 MB
(Page size should be in the range of 1 MB – 1.5 MB)
Load Time: 6.88s
(Website of 1 MB size should load in around 1s)
Perf. Grade: 72/100
Your website is slower than 79% of all tested websites.
Further analyzing the website, I realized that the big load hog on home page is Google Maps and Google Analytic. Fixing these two factors on the site had the potential to improve site load time.
I also tested the website on Webpagetest and got the following site speed score.
First Byte Time: F
Keep-alive Enabled: A
Compress Transfer: A
Compress Images: N/A
Cache static content: F
Effective use of CDN: X
First View: 6.306s
Repeat View: 3.051s
Looking at the detailed tab of the speed test report, I spotted two problems.
- Line 21 your slider image http://www.sanantonioaccidentlawyer.com/wp-content/uploads/2014/06/cropped-Screen-Shot-2014-06-15-at-12.19.39-AM.png
- Google Maps
I also tested the site to analyze its power to support when a large number of users access the site at the same time. A look at the load impact report gives us a clear view that the site is not equipped with the required power to support a large number of users accessing the site simultaneously.
In order to optimize this WordPress site for speed, all the above mentioned speed hogging factors need to be fixed. In the next steps, I am going to fix these site speed limiting factors one by one.
Web host server is the backbone of any website. Unless and until, the backbone is strong, we cannot expect a site to return optimal performance on site speed optimization score. I have even dedicated a separate case study on the importance of web host servers for site speed optimization. According to my personal opinion, WP Engine is one of the best choice for running WordPress sites.
The web host infrastructure depends on your web host service provider but certain factors can be improved at our end. First of all, we should check the web server configuration before improving it to enhance the site speed score.
Added a file mark.php to public_html folder in WP install and pulled the file in web browser to check some server configurations. (You can have a look at WordPress Speed Optimization Guide – Part 4 to see the code appended inside mark.php file.) It returned the following result
In order to switch on zlib.output_compression, I added a custom php.ini but realized that it was slowing down the website. I had no other choice than to leave it switched off as earlier.
Keeping your WP install clean from unwanted code, unused WP plugins and some other crap files can help improve site load time of your site. I removed W3 Total Cache, old error logs and cleaned the following files to get rid of undesired code residing in WP install.
I also cleaned the following folders
wpconfig.php and .htaccess files are two most important files in WordPress install that can be used to improve site load speed by adding right code into the files.
2.3.1 wpconfig.php Configuration to Improve Page Load Time
Edit your wpconfig.php file by adding the following codes at the end of the file. You can edit the file using cPanel of your web host login page. You can read my four part series on WordPress speed optimization Guide to learn some tips and tricks practiced by me.
2.3.2 .htaccess Configuration to Improve Site Load Time
I added certain lines of code to .htaccess file using cPanel. You can have a look at the code that I have already mentioned in WordPress Speed Optimization Guide – Part 4.
CloudFlare is a good tool to speed up websites. It also offers a free account capable of powering most of the sites with CDN and some other basic caching stuff. I created a free account at CloudFlare and used out of box settings in the beginning. After doing certain speed tests, I configured CloudFlare with CDN and Full Optimizations. MaxCDN is another good CDN service provider. I have even arranged a 25% discount on MaxCDN plans for my readers.
Rocket Loader™ (Web optimization) is a good feature, but most of the time it creates certain issues so I switched it off. I looked at the DNS configuration changes propagation using whatsmydns and get dns and observed that the NAMESERVERS were pointing to the right servers.
cPanel of SiteGround offers some good caching options. I wanted to try whatever works best with this site. First of all, I compressed all the content on the site by turning on an option available at its cPanel.
Cleaning WP Install against the unused WP plugins is an important task to improve site load speed. I looked at the list of activated plugins and removed WP Smush.it as never had a good experience with this WP plugin.
Image optimization is quite important for all the sites as most of the raw images are quite heavy in size which results in an increase in page size due to which the site gets slow to load. You can try any of the following plugins to optimize your site’s images and keep whatever works best in your case.
All of the above image optimization WP plugins are goods tool to optimize your site’s images, but you should only use the one that best suits to your web server environment. Hit and Trial can help you choose a plugin that works best on your site.
Looking at the site, I observed that the site was using three different Sitemap files, two search engine crawlable sitemaps while one user sitemap. I removed Google sitemap plugin and installed WordPress SEO by Yoast plugin to manage this site’s sitemap. It was strange but after removing Google sitemap plugin, the site generated following list of errors:
[Thu Nov 06 05:52:58 2014] [alert] [client 220.127.116.11] /home/sanant56/public_html/.htaccess: Invalid command ‘php_flag’, perhaps misspelled or defined by a module not included in the server configuration, referer: http://www.sanantonioaccidentlawyer.com/wp-admin/plugins.php
[Thu Nov 06 05:33:04 2014] [error] [client 18.104.22.168] client denied by server configuration: /home/sanant56/public_html/what-to-do-2
The errors had to be fixed. Since the site was not using any category or tags, I installed and activated the removed sitemap plugin back. I did some tests and realized that this sitemap plugin was working better so decided to keep it on the site. I also removed iThemes Security Pro as it had some bugs into it. Finally, the sitemap was fixed on the site to generate sitemaps for search engines without any trouble.
SiteGround offered some inhouse caching options and I wanted to try it out for speeding up this site on speed meters. On activating the following three different types of caching options available through cPanel, I got the following site speed test results
Enable Google PageSpeed
Varnish Static Cache
I also added SGCachePress.zip module provided by SiteGround. Benchmarking the site on some speed test meters, I realized that the site was loading fast (CDN with Full Optimizations from CloudFlare was also active), but I wanted the site to load faster.
A huge load on site is because of the use of non-optimized images. Websites should try optimizing and scaling their images before uploading in order to keep the page size small As a result you will also get fast page load time. By going through a quick analysis of the site, I noticed that the header image was too big in size. Using Compress Now online image optimization tool, I optimized the image to reduce its size, although, without losing any details. Also, added a favicon file in its optimized form.
By this time, most of the site speed optimization tasks were carried out successfully, but I wanted to benchmark the website on some premiere online speed testing tools. My objective was not only to analyze the speed performance of the site, but also to diagnose and treat all the minor site speed pulling factors. Although, these are minor speed related issues but they turn out to be quite major collectively.
Let us have a look at some of the most prominent site speed test reports to move ahead on our site speed optimization process further.
Page Speed Grade: (87%) B
YSlow Grade: (93%) A
Page load time: 3.34 s
Total page size: 517 KB
Total number of requests: 22
Page size 553.5 kB
Load time 2.39 s
Perf. grade 82/100
Your website is faster than 63% of all tested websites
First Byte Time: F
Keep-alive Enabled: A
Compress Transfer: A
Compress Images: B
Cache static content: F
Effective use of CDN: YES
First View: 3.137s
Repeat View: 1.789s
Looking at the detailed GTmetrix site speed report, I picked up some speed limiting factors and fixed them one by one.
The first site speed pulling factor that caught my attention is Remove Query Strings from Static Resources.
Remove Query Strings from Static Resources is showing a score of D 62, which need to be fixed. In order to fix this issue, I installed a WP plugin Remove Query Strings from Static Resources and activated it from WP Dashboard. I took another site speed test at GTmetrix and got the following result.
Now, you can see that the score on Remove Query Strings from Static Resources moved up from its earlier value of D 62 to A 93, a remarkable improvement.
Next site speed limiting issue clouding our site is related to serving scaled images. Looking at the following screenshot, you can see the score on Serve Scaled Images as D (60). The GTmetrix speed test report gives a list of images which are resized in HTML or CSS.
Noting down the actual size of the images in which these images are served, I downloaded the original images from site and scaled it to the given size. I replaced the original images with the scaled images after scaling the images manually with the help of an image editor software. Most of the photo editing software have an option to scale the images.
I benchmarked the site once again on GTmetrix to analyze the speed performance achieved so far. Looking at the following site speed test report, you can see that the score on Serve Scaled Images has moved up from its earlier value of D (60) to A (90).
Optimize Images got a score of D (62) when the site was benchmarked for speed at Gtmetrix. Looking at the following screenshot, you can see a list of images which are not optimized.
Looking at the GTmetrix report, you can also see a link to “See optimized version”. Clicking on the link opens the optimized version of the image. An easy fix is to download the optimized version of the image and substitute the original images against its optimized version. You can either use cPanel or an FTP client to upload optimized images. After replacing the original images with their optimized versions, I benchmarked the site once again on GTmetrix and got the following result.
You can see that the score on Optimize Images moved up from its earlier value of D (62) to A(100), a perfect full improvement.
Looking at another section of GTmetrix site speed test report, I noticed the score on Leverage Browser Caching at C (76).
Since we are using CloudFlare on this site, I thought of fixing the issue of Leverage Browser Caching from CloudFlare Performance settings page. I edited the value of Minimize expire TTL 5 days and made it to 7 days. I benchmarked the site once again on Gtmetrix and got the following GTmetrix site speed report.
As you can see in the GTmetrix report, Leverage Browser Caching score shot up to A (100) against its previous value of C (76).
Overall, the site speed score report is showing good improvement over its previous values, page load time 3.79s. In order to improve page load time further, I moved ahead to fine tune the site so that it can load faster.
zLib compression is another important site load improvement factor that can speed up websites load time. In order to turn on zLib compression, I created a file named php.ini in the root folder and added the following lines into the file.
memory_limit = 512M
max_execution_time = 240
max_input_time = 120
After making the above changes, I cleared all the cache before pulling the site once again. GTmetrix speed test report returned the following results.
Page Speed Grade: (94%) A
YSlow Grade: (94%) A
Page load time: 1.65s
Total page size: 349KB
Total number of requests: 20
The site speed test result looks nice, but it also seems that the DNS change has not propagated yet. Once the DNS propagates across the world, the site speed is expected to improve further.
I thought of giving it some time so DNS propagates well across the globe before moving ahead to any other speed optimization on this website.
Benchmarking the site on Load Impact Test, the following result was received, showing that the site is now quite stable to manage heavy traffic bursts.
Now, everything on the site looks good except the DNS propagation. Since the site is powered by CloudFlare, I expect a remarkable improvement in site load time after the DNS propagates across the world.
In the meantime, I also looked around at different pages on site and fixed certain speed issues found on individual pages. Most of the speed issues on individual pages were related to images optimization, which I fixed as explained above by replacing the original image with its optimized image respectively.
Another minor issue was of Google map, which has been fixed by embedding the map into the page. It helped us reduce the page load time to a great extent.
I benchmarked the site once again to analyse its speed improvement over the earlier speed scores. It helps us make a comparison to evaluate the performance improvement after I finish my WP site speed optimization process. Let us test the site once again for speed on some good online site speed test tools.
|Factor||Before Optimization||After Optimization||Result||Gain|
|Page Speed Grade||88% (B)||95% (A)||Improved||08%|
|YSlow Grade||66% (D)||93% (A)||Improved||41%|
|Page load time||2.84 s||1.65 s||Improved||42%|
|Total page size||2.27 MB||515 KB||Improved||78%|
|Total number of requests||55||27||Improved||51%|
Values of Page Speed Grade, YSlow Grade, Page load time, Total page size and Total number of requests improved.
|Factor||Before Optimization||After Optimization||Result||Gain|
|Page Size||2.2 MB||497.2 KB||Improved||78%|
|Load time||6.88 s||1.20 s||Improved||83%|
Your website is faster than 86% of all tested websites. [Earlier: Your website is slower than 79% of all tested websites.]
Values of Page size, Load time, Requests and Perf. Grade improved on a relative scale.
|Factor||Before Optimization||After Optimization||Result|
|First Byte Time||F||F||No Change|
|Keep-alive Enabled||A||A||No Change|
|Compress Transfer||A||A||No Change|
|Cache static content||F||B||Improved|
|Effective use of CDN||NO||YES||Improved|
|First View||6.306 s||2.539 s||Improved (60%)|
|Repeat View||3.051 s||1.410 s||Improved (54%)|
The website is now fully powered with CloudFlare and my WP speed optimization tips and tricks. In a nutshell, non-optimized images and non-optimized plugins were some of the primary issues holding this site back on speed performance. No doubt, WP plugins make WordPress more powerful and robust but plugin developers also need to take a proactive approach regarding the impact of their plugins on WP site speed.
As Google has officially declared site load time as one of the important ranking factors for Google SERP, WP plugins developers also need to improve their plugins in terms of speed. It is not only about adding functionality through plugins, but also to keep page load time under control. Unfortunately, I had to remove certain plugins as they were hampering the site load speed. I hope, WP plugin developers can pay more attention to site speed while coding their plugins in future.
Mark was awesome to work with.
He made my site amazingly fast and had excellent communication and documentation.
I would not hesitate to recommend him to anyone looking for a WordPress site speed expert.