Posted on Leave a comment

How to convert a non-WWW WordPress site to WWW

UPDATE (Jun 6, 2019): Converting this site from non-WWW to WWW created a significant caching issue with WP-Rocket.

Namely, WP-Rocket had created a cached version of the non-WWW homepage, and this version remained inside the /wp-content/cache/ directory even after the conversion. This version continued to exist despite clearing the cache from the WP-Rocket settings.

Since the non-WWW cached version of the homepage referenced non-WWW images, it displayed blank areas instead of WWW images.

It was this cached version that Googlebot continued to crawl, and for several months Google displayed this outdated & faulty version in its index. (ie: Google continued to index the non-WWW homepage version instead of the WWW version, its cached version did not display any images, and styles for the social media buttons were broken for mobile phones.)

Deleting old cache files & folders from the /wp-content/cache/ folder on the server solved this problem immediately.


UPDATE (Dec 30, 2018): This site’s SEO took a big hit following the conversion from non-WWW to WWW. Therefore, conversion to WWW is not recommended unless absolutely required for using a content delivery network.


Ancient Greek Keyboard’s original domain URL was https://ancientgreekkeyboard.com, but was recently changed to https://www.ancientgreekkeyboard.com.

While using WWW in the domain name is said to result in slight improvements in site speed, security and scalability, the main reason for the change was so that a content delivery network could be used in the future (CDNs typically require sites to use WWW in their domain names).

The following procedure was used in converting this WordPress site from non-WWW to WWW:

  1. Use the Duplicator plugin to create a backup of the current site.
  2. Download the backup created by Duplicator to the local computer (and download the corresponding INSTALLER.PHP file as well).
  3. Download the current HTACCESS file at the root of the WordPress installation using Filezilla. Save a copy in a secure location on the local computer.
  4. Comment out all HTTPS redirection code in the HTACCESS file.
  5. Upload the edited HTACCESS file back to the root of the WordPress installation on the server.
  6. Download the WP-CONFIG.PHP file from the root of the WordPress installation on the server.
  7. Comment out:
    define(‘WP_HOME’, ‘https://ancientgreekkeyboard.com’);
    and:
    define(‘WP_SITEURL’, ‘https://ancientgreekkeyboard.com’);
    (If these statements are nowhere to be found in WP-CONFIG.PHP, then ignore this step.)
  8. Save WP-CONFIG.PHP file & upload it to the root of the WordPress installation on the server. (If the previous step was skipped, this step can be skipped as well.)
  9. On the WordPress administration page, go to: Settings > General.
  10. WordPress Address (URL) set to https://www.ancientgreekkeyboard.com.
  11. Site Address (URL) set to https://www.ancientgreekkeyboard.com
  12. Click the Save button.
  13. Automatically logged out of the WordPress administration page.
  14. Log back into the WordPress administration page.
  15. Check Settings > Permalinks to verify all permalinks include WWW. (They did.)
  16. Add & activate the Velvet Blues Update URLs plugin.
  17. Click the Update URLs link on the WordPress administration plugin page.
  18. Input Old URL: https://ancientgreekkeyboard.com
  19. Input New URL: https://www.ancientgreekkeyboard.com
  20. Click all checkboxes for updating URLs (except GUIDs).
  21. Click the Update URLs NOW button.
  22. Velvet Blues updated 131 content items, 19 attachments, and 34 custom fields.
  23. Also used Velvet Blues to update from HTTP to HTTP://WWW (ie: from http://ancientgreekkeyboard.com to https://www.ancientgreekkeyboard.com.) Two content items were thus updated. (This was unexpected, since I believed there were no HTTP URLs residing on the site.)
  24. Deactivate the Velvet Blues Update URLs plugin.
  25. Change WP-CONFIG.PHP to reflect the new WWW domain name:
    define(‘WP_HOME’, ‘https://www.ancientgreekkeyboard.com’);
    define(‘WP_SITEURL’, ‘https://www.ancientgreekkeyboard.com’)
  26. Change the salts in WP-CONFIG.PHP.
  27. Upload WP-CONFIG.PHP to the root directory of the WordPress installation.
  28. Automatically logged out of the WordPress administration panel.
  29. Log back into the WordPress administration page.
  30. Change the HTACCESS code in the root of the WordPress installation to automatically redirect URLs to HTTPS://WWW.
    ### First rewrite any request to the wrong domain to use the correct one (here www.)
    RewriteCond %{HTTP_HOST} !^www\.
    RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    ### Now, rewrite to HTTPS:
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  31. Update URL addresses in HTACCESS to refer to WWW.
  32. Save HTACCESS & upload to root directory of the WordPress Installation on the server.
  33. In the Child Theme folder, find the STYLE.CSS, STYLE-LOGIN.CSS, and FUNCTIONS.PHP files and change all references from non-WWW to WWW. (NOTE: If the latter two files don’t exist, then just update the STYLE.CSS file.)
  34. Save these three files & upload them to the Child Theme folder on the server. (Again, don’t bother with STYLE-LOGIN.CSS and /or FUNCTIONS.PHP if they don’t exist!)
  35. Check a few images in the Media Library to verify that the images now have the correct WWW URL.
  36. Check a few Pages & Posts that they have WWW URLs.
  37. If using a shopping cart plugin, go to the settings & change all URLs to include WWW.
  38. Change all URLs to WWW in whatever SEO plugin is being used.
  39. The Guest custom avatar was somehow reset to default settings during the entire process. Go to Settings > Discussion to set it correctly again.
  40. Clear the WP-Rocket cache (or the cache for whatever caching plugin you’re using, if any).
  41. On Google Webmaster Tools, delete the current non-WWW property. Add a new WWW property, verify it, and add a sitemap.
  42. Repeated the previous step for Bing Webmaster Tools.
  43. Updated references to WWW in the ROBOTS.TXT file, and uploaded to the server.

Other posts in this series:

  1. Manual eCommerce Site Setup On SiteGround: Day 1
  2. Manual eCommerce Site Setup On SiteGround: Day 2
  3. Manual eCommerce Site Setup On SiteGround: Day 3
  4. Manual eCommerce Site Setup On SiteGround: Day 4
  5. Manual eCommerce Site Setup On SiteGround: Day 5
  6. Manual eCommerce Site Setup On SiteGround: Day 6
  7. Manual eCommerce Site Setup On SiteGround: Day 7
  8. Manual eCommerce Site Setup On SiteGround: Day 8: (Site brought live)
  9. Manual eCommerce Site Setup On SiteGround: Week 2
  10. Manual eCommerce Site Setup On SiteGround: Week 3
  11. Manual eCommerce Site Setup On SiteGround: Week 4
  12. Week 5: Speed optimization tests
  13. Manual eCommerce Site Setup On SiteGround: Week 6
  14. How to convert a non-WWW WordPress site to WWW
Posted on Leave a comment

WP Rocket Speed Test (with & without SiteGround Static Caching)

Now that the WP Rocket caching plugin is being used on Ancient Greek Keyboard, it would be useful to know if SiteGround’s Static Caching makes a positive contribution to the site’s page load speeds. To find out, 36 speed tests were conducted with and without Static Caching.

Methods

Each test was performed using Pingdom.com’s Website Speed Test, using the San Francisco, California location option. Each test was conducted with the HTTPS URL.

Control trials were conducted using WP Rocket with default & additional settings, with SiteGround’s Static Caching turned off. These results were compared to test trials with identical settings for WP Rocket, but with SiteGround’s Static Caching turned on.

In all, 9 tests were run each day for 4 days. Load time results were recorded, and averaged at the end of the study.

Results

The following HTML table was generated by the Tableizer Excel to HTML conversion site:

Site Load Speed With WP Rocket (With & Without SiteGround Static Caching

DateTimeLoad Time of Control (sec)Load Time with Static Caching (sec)
11/16/201817:501.3001.080
1.2801.100
1.2801.310
20:561.3401.260
1.2601.130
1.0301.090
22:451.1401.360
1.4101.570
1.4401.410
11/17/201817:231.2001.330
1.2901.110
1.4001.050
19:441.0501.090
1.2701.190
1.2101.330
23:211.2101.350
1.3701.470
1.1101.430
11/18/201812:371.2101.330
1.1801.070
1.0101.240
15:121.2901.130
1.1401.120
1.2801.110
20:161.4001.280
1.3701.140
0.9671.070
11/19/201812:381.3501.550
1.5301.250
1.0401.170
19:191.3401.340
1.1601.130
1.3901.100
23:231.2701.260
1.1701.260
1.4401.470
n3636
Average1.2541.241
Std Dev0.1360.146

Observations

Siteground’s Static Caching option improved the average load speed of this WordPress installation by 0.012 seconds (1.254 sec vs 1.241 sec).

Conclusions

SiteGround’s Static Caching option improved site speed by a very modest amount (0.012 seconds, or twelve thousandths of a second). It will therefore not be used for two reasons:

  1. I’d like to see an improvement of 0.05 seconds or better from any speed-improving measure. Anything less may very well be due to random speed test errors.
  2. Using Static Caching adds an additional level of complexity which must be taken into account during CSS troubleshooting. (ie: When changing the site’s styles, the webmaster must remember to both clear WP Rocket’s cache, as well as clear SiteGround’s Static Caching before refreshing the page to see the style changes).

Other posts in this series:

  1. Siteground Speed Test (With & Without Static Caching)
  2. Speed Test of Swift Performance Lite plugin
  3. Caching Plugin Speed Tests: Swift Performance Lite vs. W3 Total Cache
  4. Speed Test: W3 Total Cache With Autoptimize
  5. Speed Test of WP-Rocket plugin (default settings)
  6. Speed Test of WP-Rocket plugin (additional settings)
  7. WP Rocket Speed Test (with & without SiteGround Static Caching)
Posted on Leave a comment

Speed Test of WP-Rocket plugin (additional settings)

Settings beyond the standard defaults in the WP-Rocket caching plugin were tested for their effect on site speed on Ancient Greek Keyboard. The control consisted of  Siteground’s Static Cache running in the background.

Methods

Each test was performed using Pingdom.com’s Website Speed Test. The San Jose, California location option was used initially. (For the second half of the tests, Pingdom.com changed its system & the San Francisco, California location was the only similar option). Each test was conducted with the HTTP URL rather than the HTTPS URL.

For each setting, 9 tests were run during a single day. (The number of tests per setting was deliberately kept low to reduce the total testing time.)

Load time results were recorded, and averaged at the end of the study. While typically, only settings which improved speed would be kept, in these tests the small sample size created random error & it was arbitrarily decided that even settings which led to a reduction of speed as low as -0.05s would still be used. (Since reduction of speed was essentially close to zero, anyways.)

Results

The following HTML tables were generated by the Tableizer Excel to HTML conversion site:

Table 1. Page Load Speed with Setting: Cache > Separate Cache Files for Mobile Devices

DateTimeLoad time of control (sec)Load time of setting (sec)
9/20/201816:161.2101.450
1.2001.240
1.3601.370
21:151.2101.520
1.4901.450
1.4101.430
22:391.3601.230
1.2701.250
1.3301.310
n99
Average1.3161.361
Std Dev0.1010.108

Analysis: The Separate Cache Files for Mobile Devices setting harmed load speed by 0.046 seconds (1.316 seconds for the control vs 1.361 seconds for the setting).

While this reduction of performance was less than the -0.05 second threshold, this setting WILL NOT be used in the future because the site serves little content on mobile devices that is not served to desktop devices.

Table 2. Page Load Speed with Setting: File Optimization > Minify HTML

DateTimeLoad Time of control (sec)Load Time of setting (sec)
9/21/201812:541.3601.360
1.4101.390
1.4001.360
16:521.4901.210
1.2101.220
1.2801.390
19:461.3701.430
1.2101.050
1.2501.140
n99
Average1.3311.283
Std Dev0.0980.132

Analysis: The Minify HTML setting improved load speed by 0.048 seconds (1.331 seconds for the control vs 1.283 seconds for the setting).

This setting WILL be used in the future. While it doesn’t seem to improve page load speed much, it doesn’t appear to harm it, either.

Table 3. Page Load Speed with Setting: File Optimization > Remove Query Strings

DateTimeLoad Time of control (sec)Load Time with setting (sec)
9/22/201813:031.5401.280
1.4201.450
1.2801.270
16:591.1201.420
1.2501.420
1.3701.240
22:391.3501.290
1.2201.260
1.5001.270
n99
Average1.3391.322
Std Dev0.1360.082

Analysis: The Remove Query Strings setting improved load speed by 0.017 seconds (1.339 seconds for the control vs 1.322 seconds for the setting).

This setting WILL be used in the future. While it doesn’t seem to improve page load speed much, it doesn’t appear to harm it, either.

Table 4. Page Load Speed with Setting: File Optimization > Minify CSS

DateTimeLoad Time of control (sec)Load Time with setting (sec)
9/23/201813:081.2201.530
1.2101.480
1.4801.570
15:551.3601.770
1.3501.500
1.2201.740
21:161.5001.630
1.2301.080
1.2401.840
n99
Average1.3121.571
Std Dev0.1150.224

Analysis: The Minify CSS setting harmed load speed by 0.259 seconds (1.312 seconds for the control vs 1.571 seconds for the setting).

This setting WILL NOT be used in the future since it causes a significant loss of page load speed.

Table 5. Page Load Speed with Setting: File Optimization > Combine CSS

DateTimeLoad Time of control (sec)Load Time with setting (sec)
9/24/201812:161.4001.550
1.3401.430
1.3401.420
14:341.2201.490
1.3501.110
1.3601.330
16:361.3201.310
1.2301.190
1.4401.450
n99
Average1.3331.364
Std Dev0.0710.143

Analysis: The Combine CSS setting harmed load speed by 0.031 seconds (1.333 seconds for the control vs 1.364 seconds for the setting).

This setting WILL NOT be used in the future, despite its negative impact on page speed being insignificant (ie: it fell below the -0.05 second threshold).

The reason for rejecting this setting is because it breaks some of the Child Theme styles.

Table 6. Page Load Speed with Setting: File Optimization > Optimize CSS delivery

DateTimeLoad Time of control (sec)Load Time with setting (sec)
9/25/201819:401.4301.250
1.1601.120
1.1401.110
22:091.2601.030
1.2901.320
1.2801.150
1.0401.190
1.0701.280
1.0501.120
n99
Average1.1911.174
Std Dev0.1330.093

Analysis: The Optimize CSS delivery setting improved load speed by 0.017 seconds (1.191 seconds for the control vs 1.174 seconds for the setting).

This setting WILL NOT be used in the future. Although it had a minor positive impact on page speed, it required 2 IPs to be whitelisted.

Table 7. Page Load Speed with Setting: File Optimization > Minify JS

DateTimeLoad Time of control (sec)Load Time with setting (sec)
9/26/201818:331.1401.170
1.1101.260
1.2901.070
21:121.3201.090
1.2801.120
1.3501.110
22:471.1801.300
1.3301.160
1.1901.190
n99
Average1.2431.163
Std Dev0.0890.077

Analysis: The Minify JS setting improved load speed by 0.080 seconds (1.243 seconds for the control vs 1.163 seconds for the setting).

This setting WILL be used in the future because it has a major positive impact on page speed.

Table 8. Page Load Speed with Setting: File Optimization > Combine JS

DateTimeLoad Time of control (sec)Load Time with setting (sec)
9/27/201812:121.2401.200
1.2401.150
1.2401.310
15:321.2800.991
1.1801.110
1.2901.100
18:021.0701.310
1.1101.200
1.1101.220
n99
Average1.1961.177
Std Dev0.0810.102

Analysis: The Combine JS setting improved load speed by 0.019 seconds (1.196 seconds for the control vs 1.177 seconds for the setting).

This setting WILL be used in the future. While it doesn’t seem to improve page load speed much, it doesn’t appear to harm it, either.

Table 9. Page Load Speed with Setting: File Optimization > Load JS Deferred

DateLetter GradeLoad Time of control (sec)Load Time with setting (sec)
9/28/2018861.2001.210
861.3001.460
861.1101.160
861.3001.160
841.4601.310
861.3301.230
861.3101.310
861.3301.210
861.1301.190
n99
Average1.2741.249
Std Dev0.1100.097

Analysis: The Load JS Deferred setting improved load speed by 0.026 seconds (1.274 seconds for the control vs 1.249 seconds for the setting).

This setting WILL be used in the future. While it doesn’t seem to improve page load speed much, it doesn’t appear to harm it, either.

Table 10. Page Load Speed with Setting: File Optimization > Load JS deferred + Safe mode for Jquery

DateTimeLoad Time of control (sec)Load Time with setting (sec)
9/29/201810:471.3401.310
1.2401.490
1.4801.410
13:031.2401.230
1.3201.340
1.4301.250
15:001.2201.450
0.8041.480
1.6001.230
n99
Average1.2971.354
Std Dev0.2240.106

Analysis: The Load JS deferred + Safe mode for Jquery setting harmed load speed by 0.057 seconds (1.297 seconds for the control vs 1.354 seconds for the setting).

This setting WILL NOT be used in the future, since it harmed page load speed beyond the -0.05 second threshold.

Table 11. Page Load Speed with Setting: Media > Lazy Load for Images

DateTimeLoad Time of control (sec)Load Time with setting (sec)
9/30/201810:181.5001.380
1.5201.360
1.4601.440
12:461.3001.200
1.4701.160
1.2501.310
15:311.4401.260
1.3001.540
1.6301.490
n99
Average1.4301.349
Std Dev0.1230.129

Analysis: The Lazy Load for Images setting improved load speed by 0.081 seconds (1.430 seconds for the control vs 1.349 seconds for the setting).

This setting WILL be used in the future because it has a major positive impact on page speed.

Table 12. Page Load Speed with Setting: Media > Lazy Load for iFrames / Videos

DateTimeLoad Time of control (sec)Load Time with setting (sec)
10/1/201810:591.3701.320
1.3001.550
1.4701.360
13:561.1901.360
1.2101.270
1.2201.440
16:291.3601.370
1.3501.300
1.4901.250
n99
Average1.3291.358
Std Dev0.1090.092

Analysis: The Lazy Load for iFrames / Videos setting harmed load speed by 0.029 seconds (1.329 seconds for the control vs 1.358 seconds for the setting).

This setting WILL be used in the future, since the reduction of performance was less than the -0.05 second threshold.

Table 13. Page Load Speed with Setting: Media > Replace YouTube iframe with preview image

DateTimeLoad Time of control (sec)Load Time with setting (sec)
10/2/201810:571.3801.290
1.2201.470
1.2401.240
15:471.4501.480
1.2101.400
1.2401.220
17:441.2401.190
1.3801.390
1.1101.380
n99
Average1.2741.340
Std Dev0.1070.108

Analysis: The Replace YouTube iframe with preview image setting harmed load speed by 0.066 seconds (1.274 seconds for the control vs 1.340 seconds for the setting).

This setting WILL NOT be used in the future, since the reduction of page load speed exceeds the -0.05 second threshold and the site does not currently use any YouTube videos or iFrames.

Table 14. Page Load Speed with Setting: Preload > Sitemap-based cache preloading

DateTimeLoad Time of control (sec)Load Time with setting (sec)
10/3/201810:571.3901.220
1.1701.420
1.2001.270
13:151.4201.510
1.2801.430
1.3901.210
15:551.3601.210
1.2101.340
1.2001.300
n99
Average1.2911.323
Std Dev0.0990.109

Analysis: The Sitemap-based cache preloading setting harmed load speed by 0.032 seconds (1.291 seconds for the control vs 1.323 seconds for the setting).

This setting WILL NOT be used in the future. Although the reduction of performance was less than the -0.05 second threshold, this setting caused cron jobs to “crawl” the site every 12 hours (cluttering up the site’s statistics).

Table 15. Page Load Speed with Setting: Preload > Preload bot (automatic)

DateTimeLoad Time of control (sec)Load Time with setting (sec)
10/4/201812:011.4601.440
1.2501.450
1.2301.250
14:111.3801.240
1.6001.530
1.2701.300
17:111.2701.600
1.3901.210
1.2901.300
n99
Average1.3491.369
Std Dev0.1210.140

Analysis: The Preload bot (automatic) setting harmed load speed by 0.020 seconds (1.349 seconds for the control vs 1.369 seconds for the setting).

This setting WILL be used in the future, since the reduction of performance was less than the -0.05 second threshold.

Conclusions

Unusable Settings

The following settings for WP-Rocket will not be used on Ancient Greek Keyboard because they either cause a reduction of page load speed more than the -0.05 second threshold, or require outside IPs to be whitelisted, or initiate undesirable cron jobs which clutter up the site’s statistics, or break the site’s CSS:

  1. Cache > Separate Cache Files for Mobile Devices
  2. File Optimization > Minify CSS
  3. File Optimization > Combine CSS
  4. File Optimization > Optimize CSS delivery
  5. File Optimization > Load JS deferred + Safe mode for Jquery
  6. Media > Replace YouTube iframe with preview image
  7. Preload > Sitemap-based cache preloading

Usable Settings

The following settings will be used on Ancient Greek Keyboard because they either improve page load speed (or at the very least, do not harm it significantly):

  1. File Optimization > Minify HTML
  2. File Optimization > Remove Query Strings
  3. File Optimization > Minify JS
  4. File Optimization > Combine JS
  5. File Optimization > Load JS Deferred
  6. Media > Lazy Load for Images
  7. Media > Lazy Load for iFrames / Videos
  8. Preload > Preload bot (automatic) [See Nov 8, 2018 update]

UPDATE (Nov 8, 2018): The recent update of WP Rocket (vers. 3.2) no longer uses a bot for Preload, so this option no longer exists.

The replacement will not be used however, since it tends to clutter up the statistics log.


Other posts in this series:

  1. Siteground Speed Test (With & Without Static Caching)
  2. Speed Test of Swift Performance Lite plugin
  3. Caching Plugin Speed Tests: Swift Performance Lite vs. W3 Total Cache
  4. Speed Test: W3 Total Cache With Autoptimize
  5. Speed Test of WP-Rocket plugin (default settings)
  6. Speed Test of WP-Rocket plugin (additional settings)
  7. WP Rocket Speed Test (with & without SiteGround Static Caching)
Posted on Leave a comment

Speed Test of WP-Rocket plugin (default settings)

In a previous speed test on Ancient Greek Keyboard, Pingdom.com graded W3 Total Cache poorly for JavaScript combination & minification. Because of this, a different caching plugin (WP-Rocket, with default settings) was tested against a control (Siteground’s Static Cache running in the background).

Methods

Each test was performed using Pingdom.com’s Website Speed Test. The San Jose, California location option was used initially. (For the second half of the tests, Pingdom.com changed its system & the San Francisco, California location was the only similar option). Each test was conducted with the HTTP URL rather than the HTTPS URL.

In all, 9 tests were run each day for 4 days. Load time results were recorded, and averaged at the end of the study.

Results
The following HTML tables were generated by the Tableizer Excel to HTML conversion site:

Page Load Speed with WP-Rocket

DateTimeLoad Time of Control (sec)Load Time with WP-Rocket (sec)
9/16/201816:451.2300.873
1.4900.914
1.2400.970
18:301.2400.907
1.5101.150
1.2401.210
20:521.4201.120
1.2200.910
1.1901.110
9/17/201815:451.2001.140
1.4401.150
1.4800.886
17:501.2400.931
1.4900.932
1.1901.130
20:061.5001.100
1.4901.200
1.4401.010
9/18/201810:451.4801.360
1.5201.250
1.4101.360
13:461.4101.260
1.5201.330
1.6301.250
16:121.6101.320
1.4901.420
1.3901.270
9/19/201812:011.6801.330
1.3901.430
1.4501.370
14:182.1601.220
1.6301.580
1.7801.480
17:521.4601.240
1.5301.340
1.5301.390
n3636
Average1.4531.190
Std Dev0.1910.189

Results

WP-Rocket improved page load speed by 0.263 seconds over the control (1.190 sec vs. 1.453 sec).

Conclusions

An alternative to W3 Total Cache was sought because this plugin did not minify Javascript well. WP-Rocket was therefore chosen and speed tested with its default settings, yielding a page load speed of 1.190 seconds.

This result seems unimpressive, since W3 Total Cache was previously found to increase page load speed to 1.046 seconds. However, it should be noted that the two speeds are not really comparable: W3 Total Cache’s speed was recorded under conditions in which it broke CSS styles. (The two plugin speeds can only be compared under conditions in which they both leave CSS styles unbroken).

WP-Rocket speeds will be further tested over the next few weeks with settings adjusted beyond the default settings.


Other posts in this series:

  1. Siteground Speed Test (With & Without Static Caching)
  2. Speed Test of Swift Performance Lite plugin
  3. Caching Plugin Speed Tests: Swift Performance Lite vs. W3 Total Cache
  4. Speed Test: W3 Total Cache With Autoptimize
  5. Speed Test of WP-Rocket plugin (default settings)
  6. Speed Test of WP-Rocket plugin (additional settings)
  7. WP Rocket Speed Test (with & without SiteGround Static Caching)
Posted on Leave a comment

Speed Test: W3 Total Cache With Autoptimize

In previous tests, Pingdom.com rated W3 Total Cache rather poorly for combining JavaScript files. Because of this, an effort was made to run W3 Total Cache alongside Autoptimize (the latter was being used to combine & minify JavaScript).

Initial results appeared very encouraging, with page load speeds around 0.5 – 0.6 seconds. However, it was later discovered that these numbers were completely wrong: Autoptimize & W3 Total Cache were interfering with each other and causing a 500 Internal Server Error on Ancient Greek Keyboards.

This 500 error occurred under the following conditions:

  1. W3 Total Cache (JS Minify enabled) plus Autoptimize (Optimize JavaScript Code enabled)
  2. W3 Total Cache (JS Minify disabled) plus Autoptimize (Optimize JavaScript Code enabled)

This incompatibility means that Autoptimize cannot be used to optimize JavaScript alongside W3 Total Cache (ie: Autoptimize can only be used to Combine & minify CSS alongside W3 Total Cache).


Other posts in this series:

  1. Siteground Speed Test (With & Without Static Caching)
  2. Speed Test of Swift Performance Lite plugin
  3. Caching Plugin Speed Tests: Swift Performance Lite vs. W3 Total Cache
  4. Speed Test: W3 Total Cache With Autoptimize
  5. Speed Test of WP-Rocket plugin (default settings)
  6. Speed Test of WP-Rocket plugin (additional settings)
  7. WP Rocket Speed Test (with & without SiteGround Static Caching)
Posted on Leave a comment

Manual eCommerce Site Setup On SiteGround: Week 6

WordPress Caching Plugin Changed, Rich Snippets Added, Styling

1) The Swift Performance Lite caching plugin was found to clutter the statistics on the security plugin. In its stead, the W3 Total Cache plugin is now being used (with CSS minification turned off).

2) Tried to set up rich snippets to increase click-through rates.

Initially used the All In One Schema Rich Snippets plugin to do this, but the generated HTML failed Google’s validation test. This was because Ancient Greek Keyboard has no product review plugin set up, which is something that All In One Schema Rich Snippets seems to require. (All In One Schema Rich Snippets does not permit the administrator to turn reviews off, either.)

So instead, the structured data markup was done semi-manually on the landing page in the following manner:

First, an online microdata generator was used to generate most of the base code for a product and product offer (ie: for the product’s name, image, description, sku #, price currency, price and condition).

Second, structured data was manually written for product availability in accordance with Schema.org’s documentation.

At this point, structured data was also manually written for the product’s sku # as part of the product (rather than the product offer) for purposes of style.

Finally, this code was validated on Google’s Structured Data Testing Tool. When it passed, it was adapted to the current HTML for the first product listing on the landing page.

(Just to be safe, the final code was validated as well).

3) Adjusted font sizes on Archive & Category pages.


Other posts in this series:

  1. Manual eCommerce Site Setup On SiteGround: Day 1
  2. Manual eCommerce Site Setup On SiteGround: Day 2
  3. Manual eCommerce Site Setup On SiteGround: Day 3
  4. Manual eCommerce Site Setup On SiteGround: Day 4
  5. Manual eCommerce Site Setup On SiteGround: Day 5
  6. Manual eCommerce Site Setup On SiteGround: Day 6
  7. Manual eCommerce Site Setup On SiteGround: Day 7
  8. Manual eCommerce Site Setup On SiteGround: Day 8: (Site brought live)
  9. Manual eCommerce Site Setup On SiteGround: Week 2
  10. Manual eCommerce Site Setup On SiteGround: Week 3
  11. Manual eCommerce Site Setup On SiteGround: Week 4
  12. Week 5: Speed optimization tests
  13. Manual eCommerce Site Setup On SiteGround: Week 6
  14. How to convert a non-WWW WordPress site to WWW
Posted on Leave a comment

Caching Plugin Speed Tests: Swift Performance Lite vs. W3 Total Cache

A problem was experienced with the Swift Performance Lite caching plugin over the past week. Whenever a plugin was activated or deactivated, the Swift Performance Lite plugin would crawl the entire site, cluttering up the statistics in the security plugin. This also occurred at night, when the site was unattended.

In all, it appeared as though Swift Performance Lite crawled the site about a hundred times a day.

(Initially, this behavior was mistaken for an external bot coming from Siteground Hosting since its hostname was given as XXX.YYYYY.siteground.us. However, blocking this hostname resulted in frequent crawling attempts from WP-CRON.PHP — a cron job most likely caused by a plugin.)

Although it was always my intention to compare page load speeds of Swift Performance Lite with W3 Total Cache, the discovery of this issue gave this comparison test a high priority.

The two caching plugins were therefore tested 36 times to gauge their effect on site speed. (Both were tested with Siteground’s Static Cache running in the background.)

Methods

Each test was performed using Pingdom.com’s Website Speed Test, using the San Jose, California location option. Each test was conducted with the HTTP URL rather than the HTTPS URL.

In all, 9 tests were run each day for 4 days. Load time results were recorded, and averaged at the end of the study.

Results

The following HTML tables were generated by the Tableizer Excel to HTML conversion site:

Table 1. Page Load Speed with Swift Performance Lite vs. W3 Total Cache

DateTimeLoad Time with Swift Performance Lite (sec)Load Time with W3 Total Cache (sec)
9/5/201815:041.0700.861
0.9041.040
1.0301.060
17:091.0501.130
1.0601.190
1.8901.090
19:401.2701.770
1.2501.220
1.0900.975
9/6/201813:461.1401.150
1.1501.160
1.0700.888
16:570.9271.150
0.9670.860
1.0901.150
19:140.9590.849
1.0200.994
1.1300.994
9/7/201817:160.9620.873
0.9450.899
1.0600.906
18:580.9581.100
1.0800.873
0.9761.120
20:441.1101.140
1.0901.120
0.9020.866
9/8/201810:210.9580.910
1.1101.210
1.0700.951
13:360.9111.080
0.9940.887
0.9541.110
16:020.9670.872
1.1001.070
1.0501.130
n3636
Average1.0631.046
Std Dev0.1680.173

Table 2. Pingdom Grades for Swift Performance Lite vs. W3 Total Cache

Performance FactorsSwift Performance LiteW3 Total Cache
Overall GradeA (91%)B (88%)
Combine External JavaScriptD (61%)F (44%)
Combine External CSSB (80%)B (86%)
Minimize DNS LookupsB (87%)B (88%)
Leverage Browser CachingA (92%)B (80%)
Remove Query StringsA (92%)B (87%)
Specify A Cache ValidatorA (100%)A (95%)
Serve Static Content fr. Cookieless DomainA (100%)A (97%)

Table 1 shows that the Swift Performance Lite caching plugin yielded slightly slower page load speeds than W3 Total Cache (1.063 sec vs. 1.046 sec). Although the 0.017 second difference may not be significant, at the very least it appears that the two caching plugins are at least comparable in their effect on page load speeds.

Table 2 shows that Pingdom.com gave Swift Performance Lite slightly higher letter & numerical grades than W3 Total Cache (A vs. B; 91% vs 88%). It also granted Swift Performance Lite higher grades for a variety of scoring factors.

Despite this apparent advantage, Swift Performance Lite was still still slightly slower than W3 Total Cache.

Conclusions

An alternative to Swift Performance Lite was sought because this plugin tended to clutter up the statistics by excessively crawling the site during cron jobs. Since page load speeds with W3 Total Cache were determined to at least as fast as Swift Performance Lite (and possibly faster), W3 Total Cache will be used as the caching plugin on Ancient Greek Keyboard from now on.

It should be mentioned that W3 Total Cache sometimes breaks CSS styles, so it is anticipated that some of the site’s styles will have to be given greater priority (either through use of the !IMPORTANT property or by using greater specificity in CSS rules).


UPDATE (Sep 10, 2018): W3 Total Cache activated on site. As expected, this plugin broke link and header styles. This could not be fixed with the !IMPORTANT property, so the CSS Minify setting was disabled.

After this was done, Swift Performance Lite was deleted from the site.


Other posts in this series:

  1. Siteground Speed Test (With & Without Static Caching)
  2. Speed Test of Swift Performance Lite plugin
  3. Caching Plugin Speed Tests: Swift Performance Lite vs. W3 Total Cache
  4. Speed Test: W3 Total Cache With Autoptimize
  5. Speed Test of WP-Rocket plugin (default settings)
  6. Speed Test of WP-Rocket plugin (additional settings)
  7. WP Rocket Speed Test (with & without SiteGround Static Caching)
Posted on Leave a comment

Speed Test of Swift Performance Lite plugin

The Swift Performance Lite caching plugin was tested 36 times to gauge its effect on site speed. It was tested with SiteGround’s Static Cache running in the background, while the control had only SiteGround’s Static Cache running.

Methods

Each test was performed using Pingdom.com’s Website Speed Test, using the San Jose, California location option. Each test was conducted with the HTTP URL rather than the HTTPS URL.

In all, 9 tests were run each day for 4 days. Load time results were recorded, and averaged at the end of the study.

Results

The following HTML table was generated by the Tableizer Excel to HTML conversion site:

Site Load Speed With & Without Swift Performance Lite caching plugin

DateTimeLoad Time of Control (sec)Load Time with Swift Performance Lite (sec)
8/27/201816:051.3400.886
1.4100.890
1.4400.837
18:361.3600.849
1.3400.852
1.4201.070
20:481.3100.986
1.4401.080
1.4101.060
8/28/201810:141.5100.914
1.4600.793
1.4400.927
17:021.3700.941
1.4501.090
1.3000.932
20:141.2901.110
1.2500.953
1.2501.220
8/29/201817:071.4000.923
1.2501.010
1.2401.030
20:411.2800.939
1.2501.080
1.4501.010
23:001.5800.927
1.2801.210
1.2201.100
8/30/201816:531.3901.040
1.2900.940
1.2601.030
20:121.3601.110
1.2700.954
1.2600.961
22:321.4400.951
1.2101.060
1.2201.030
n3636
Average1.3460.992
Std Dev0.0940.100

Swift Performance Lite improved the average load speed of this WordPress installation by 0.354 seconds when SiteGround’s Static Cache was running in the background (0.992 sec vs 1.346 sec).

Conclusions

The Swift Performance Lite plugin will be used on Ancient Greek Keyboard due to its enhancement of page load speed.


Other posts in this series:

  1. Siteground Speed Test (With & Without Static Caching)
  2. Speed Test of Swift Performance Lite plugin
  3. Caching Plugin Speed Tests: Swift Performance Lite vs. W3 Total Cache
  4. Speed Test: W3 Total Cache With Autoptimize
  5. Speed Test of WP-Rocket plugin (default settings)
  6. Speed Test of WP-Rocket plugin (additional settings)
  7. WP Rocket Speed Test (with & without SiteGround Static Caching)
Posted on Leave a comment

Manual eCommerce Site Setup On SiteGround: Week 4

Social Media Buttons Added, WordPress Styling

  1. Added social media share buttons & Facebook Like button.
  2. Set Social Meta settings on All-In-One SEO Pack plugin.
  3. Adjusted font sizes on H2 & H3 tags for blog & archive pages for Ancient Greek Keyboard.
  4. Product image finally indexed by Google (as were a couple key photos). Gravatar was indexed a few weeks earlier.
  5. Set CSS to not display social media buttons on Checkout, Cancelled Transaction and Thank You pages.
  6. Used FUNCTIONS.PHP & STYLE-LOGIN.CSS to customize styles on login page.
  7. Deleted the Custom Login Page Customizer plugin (since login page is being customized via FUNCTIONS.PHP).

Other posts in this series:

  1. Manual eCommerce Site Setup On SiteGround: Day 1
  2. Manual eCommerce Site Setup On SiteGround: Day 2
  3. Manual eCommerce Site Setup On SiteGround: Day 3
  4. Manual eCommerce Site Setup On SiteGround: Day 4
  5. Manual eCommerce Site Setup On SiteGround: Day 5
  6. Manual eCommerce Site Setup On SiteGround: Day 6
  7. Manual eCommerce Site Setup On SiteGround: Day 7
  8. Manual eCommerce Site Setup On SiteGround: Day 8: (Site brought live)
  9. Manual eCommerce Site Setup On SiteGround: Week 2
  10. Manual eCommerce Site Setup On SiteGround: Week 3
  11. Manual eCommerce Site Setup On SiteGround: Week 4
  12. Week 5: Speed optimization tests
  13. Manual eCommerce Site Setup On SiteGround: Week 6
  14. How to convert a non-WWW WordPress site to WWW
Posted on Leave a comment

Siteground Speed Test (With & Without Static Caching)

In an effort to get a sense of the effectiveness of Siteground’s Static Caching, 90 speed tests were conducted with and without Static Caching.

Methods

Each test was performed using Pingdom.com’s Website Speed Test, using the San Jose, California location option. Each test was conducted with the HTTP URL rather than the HTTPS URL.

In all, roughly 9 tests were run each day for 10 days. (Although 3 tests were omitted on August 19th, and were made up for on August 24th.) Load time results were recorded, and averaged at the end of the study.

Results

The following HTML table was generated by the Tableizer Excel to HTML conversion site:

Site Load Speed With & Without Siteground Static Caching

DateTimeNo Static Caching Load Time (sec)With Static Caching Load Time (sec)
8/13/201811:402.451.37
1.381.35
1.161.33
18:061.351.18
1.281.18
1.401.17
22:561.481.43
1.361.21
1.171.15
8/14/201813:051.701.43
1.471.24
1.741.42
19:411.521.14
1.341.38
1.341.18
22:301.181.15
1.381.19
1.141.13
8/15/201816:301.511.18
1.221.12
1.191.13
19:532.621.22
1.181.92
1.761.36
22:251.391.13
1.141.35
1.391.41
8/16/201810:401.321.14
1.141.14
1.151.11
13:131.191.17
1.361.17
1.331.19
17:562.431.40
1.161.44
1.151.13
8/19/201814:321.691.19
1.121.14
1.281.13
17:281.191.16
1.391.41
1.441.38
8/20/201810:541.851.45
1.381.42
1.181.38
15:551.251.23
1.201.38
1.211.15
18:481.371.44
1.151.27
1.171.18
8/22/201812:471.491.16
1.271.33
1.151.17
17:161.261.34
1.131.18
1.351.37
20:451.371.18
1.321.15
1.351.13
8/23/201810:551.691.42
1.371.33
1.171.17
13:471.191.21
1.261.34
1.351.27
16:281.631.16
1.271.35
1.301.37
8/24/201812:091.451.39
1.451.36
1.461.44
15:221.191.17
1.441.12
1.351.12
18:181.301.26
1.171.21
1.361.42
20:361.141.18
1.201.34
1.671.39
8/25/201810:331.501.38
1.391.15
1.191.19
12:481.201.18
1.381.20
1.181.32
15:351.651.14
1.401.13
1.211.12
n9090
Average1.371.26
Std Dev0.270.13

Siteground’s Static Caching option improved the average load speed of this WordPress installation by 0.11 seconds (1.26 sec vs 1.37 sec).

Static Caching also halved the variability of load speeds (the standard deviation of load speeds with Static Caching was 0.13 vs 0.27 without).

Conclusions

Siteground’s Static Caching option appears to work, and will be used on Ancient Greek Keyboard from now on. (NB: Remember to turn this off when doing CSS work!)

In addition, future speed tests will use a smaller sample size (about 36, instead of 90) in order to reduce testing time.

Finally, it should be noted that these load times were obtained prior to activation of social media button plugins, and may not represent current load times. However, the relative difference between load times with & without Static Caching is expected to remain the same.


Other posts in this series:

  1. Siteground Speed Test (With & Without Static Caching)
  2. Speed Test of Swift Performance Lite plugin
  3. Caching Plugin Speed Tests: Swift Performance Lite vs. W3 Total Cache
  4. Speed Test: W3 Total Cache With Autoptimize
  5. Speed Test of WP-Rocket plugin (default settings)
  6. Speed Test of WP-Rocket plugin (additional settings)
  7. WP Rocket Speed Test (with & without SiteGround Static Caching)