Posted on Leave a comment

Online Quizzes For Ancient Greek Verbs

Click for Ancient Greek verb online quizzes

In 2011, I wrote 17 Flash pages for testing users’ knowledge of Ancient Greek verbs.

Unfortunately, Adobe’s support for Flash is slated to conclude at the end of 2020, and browser support will end at the same time as well.

In anticipation of Flash’s obsolescence, I have begun re-writing these Flash pages in JavaScript for Ancient Greek Keyboard.

The entry page for these tests was by-and-large completed in January of 2019, with a few minor changes made in February & March. The HTML & CSS on the entry page utilizes responsive design, and looks very similar to the old Flash page.

Once the entry page was finished, work began on the first quiz (for the verb-endings for Ancient Greek Present Active Indicative verbs). A working copy was completed on February 27th, but refinements continued to be made up to March 11th. (A request was made to Google to index the page on March 2nd, and the request granted on March 3rd).

A few difficulties arose in converting the quiz page to JavaScript. These were as follows:

1) Global variables vs. local variables

For a while, there was an issue with local variables that should have been global (ie: populated arrays were being returned as “undefined”). This was resolved by declaring the variables outside of the functions at the beginning of the first <script> tag.

2) Grammar review table

Initially, the vertical Grammar Review button opened up the grammar review table using JavaScript. However, there were 3 identical tables placed in the HTML, which added unnecessarily to the length of the file.

JavaScript code was found to generate this table into divs on the fly. See the link for further details.

3) Animated GIFs

Flash allows developers to export animations as GIFs rather than SWFs, so I attempted to export 3 SWF animations as GIFs. Unfortunately, only one of the three animations (the frowning Medusa) was successfully exported by this method.

One other animation (the winking Owl) was successfully exported using the Thundersoft SWF to GIF converter. However, the third animation (spinning “Self-Test” text) could not be recovered by either method.

With two of the three animations recovered as animated GIFs, a further problem occurred in which the animations would only play a single time rather than whenever they were called as background images with the following code:

document.getElementById("my-div").style.backgroundImage = "url(images/my-animated-file.gif)";

This was resolved by reloading “my-animated-file.gif” with a random hash based on the date & time. While the concept sounded easy enough, it took some searching to find the correct syntax:

document.getElementById("my-div").style.backgroundImage = "url('images/my-animated-file.gif" + "?" + (new Date()).getTime() + "')";

(From the above, it can be seen that a key part of getting this to work lies in getting all the single and double quotation marks right!)

4) Vertical button

Vertical buttons are easy to make in Flash, and the vertical button for the Present Active Indicative Verb Ending Page was exported as a PNG for use as background image button.

However, I decided that doing this would be too cumbersome for all 17 quizzes. To wit: For each button, I might have to change the text in Flash for the Link, Hover and Active state. Then, the PNG images of the Link, Hover & Active states of the button would have to be exported. Next, the images would have to be cropped with Photoshop, renamed, and moved to the proper image folder. And finally, the background images would have to be referenced correctly on the page’s internal stylesheet.

After all of this, the text on the vertical background image button still wouldn’t be crawlable by the search engines.

A better solution was to create vertical text with the <svg> tag. I believe that the linear gradient was generated using the online tool provided by CSS3factory.com.


UPDATE (Mar 13, 2019): Added OG meta tags for Facebook for the Present Active Indicative Verb Test page. Added Twitter meta tags as well.

Also fixed Statcounter code for the page. Did this by logging into StatCounter.com and clicking on settings beside the project (the gear icon). Then, clicked “Reinstall Code” and the large blue “Continue to Default Installation” button. Finally, copied & pasted the HTML and JavaScript code before the end of the page’s </body> tag.


UPDATE (Mar 15, 2019): Added social media like & share buttons to the quiz page.

Initially planned to add them beneath the <h1> tag, but found that they changed the desktop layout too much (and were somewhat distracting as well). Therefore, they’ve been added below the main content, before the first Greek meander divider.

Facebook

Facebook Like & Share button code was generated by the Facebook for Developers page. The code consists of two sections:

1) Immediately following the <body> tag:

<div id="fb-root"></div>
<script async defer crossorigin="anonymous" src="https://connect.facebook.net/en_US/sdk.js#xfbml=1&version=v3.2"></script>

2) Button code (for small button with counter showing number of FB Likes, but not displaying people’s FB profile pictures):

<div class="fb-like" data-href="https://my-url-here.html" data-layout="button_count" data-action="like" data-size="small" data-show-faces="false" data-share="true"></div>

Twitter

The Twitter Share button code was generated by the Twitter Publish page after clicking on the “Twitter Buttons” icon. The code does not require the URL of the page, and is as follows:

<a href="https://twitter.com/share?ref_src=twsrc%5Etfw" class="twitter-share-button" data-show-count="false">Tweet</a><script async src="https://platform.twitter.com/widgets.js" ></script>

LinkedIn

The LinkedIn Share button code was written according to directions given by ChillyFacts.com. The code is as follows:

<a href="https://www.linkedin.com/shareArticle?mini=true&url=https://my-URL-here.html &title=My%20Web%20Page%20Title&summary=mywebsite.com&source=My%20Website%20Name" id="linkedin-share-button" onclick="window.open(this.href, 'mywin',
'left=20, top=20, width=500, height=500, toolbar=1, resizable=0'); return false;" ><img src="https://my-URL-for-my-LinkedIn-button.gif" alt="" width="54" height="20" /></a>

(On my page, I’ve commented out the <img> tag & used background images for the <a> tag instead. This allow a different image to be presented for the HOVER state.)

Pinterest

The Pinterest Share button code was written according to instructions from BrandAidDesignCo.com. This code does not require the URL of the page, and is as follows:

<a href='javascript:void((function()%7Bvar%20e=document.createElement('script');e.setAttribute('type','text/javascript');e.setAttribute('charset','UTF-8');e.setAttribute('src','https://assets.pinterest.com/js/pinmarklet.js?r='+Math.random()*99999999);document.body.appendChild(e)%7D)());' id="pinterest-pin-it-button"><img src='https://my-URL-for-my-Pinterest-button.png'/></a>>

As with the LinkedIn Share button, I’ve commented out the <img> tag & used background images for the <a> tag instead. This allows a different image to be presented for the HOVER state.

Note also that I had to change http://assets.pinterest.com/js/pinmarklet.js
to:
https://assets.pinterest.com/js/pinmarklet.js
for BrandAidDesignCo’s code to work correctly. (Possibly because my site uses HTTPS instead of HTTP).


UPDATE (Mar 16, 2019): Discovered that the HOVER and ACTIVE states for the NEXT button weren’t being displayed on cell phones. The same was true when the user tried to tap one of the multiple choice options on a cell phone as well.

After 4 or 5 hours, I discovered the problem was that the JavaScript was initiating too quickly for these states to be observable. The solution was to set a 400 ms pause in JavaScript initiation for the NEXT button HOVER / ACTIVE state to be visible, and a 150 ms pause for the multiple choice options.

The HTML code for this was as follows:

<img src="my-relative-URL-for-the-NEXT-button.png" onclick="myFunction()" />

While the JavaScript called when this image button is clicked is:

function myFunction() {
	//CHECK IF USER IS USING MOBILE (IE: SCREEN WIDTH LESS THAN 768PX)
	if (window.screen.availWidth lt; 768) {
		//PAUSE REQUIRED FOR MOBILE. (SET A 400 MS PAUSE BEFORE CALLING THE NEXT FUNCTION)
		setTimeout( function() {
			myNextFunction();
		}, 400);
	}
	//NO PAUSE REQUIRED FOR DESKTOP (IMMEDIATELY CALL THE NEXT FUNCTION)
	else {
		myNextFunction();
	}
}

function myNextFunction() {
	//REQUIRED CODE GOES HERE
}

UPDATE (Mar 17, 2019): Upon further consideration, have decided to give the user radio buttons allowing him to turn the animated GIFs off.

This was because in order to get the animations to play from the start, the animated gifs need to be reloaded each time with a random hash. A cell phone user could find himself using a very large amount of bandwidth if he used the page regularly.

Consider: the animated owl is 182 kB in size, so a user who got 10 answers right in a single session would use 1.82 MB. If he did this for 30 days straight, he’d consume about 55 MB.

If instead this cell phone user turned off the animations, he’d only load the static owl image once regardless of how many answers he answered correctly, consuming only 6.15 kB per session. Over 30 days, he’d only use 0.184 MB.

The HTML for the radio buttons:

<form>
	<fieldset>
		<legend><i>Enable animation?</i></legend>
					
		<input type="radio" name="animatedGIFs" id="animation_yes" value="animationEnabled" checked="checked" />
		<label for="animation_yes">Yes</label>
						
		<br />
						
		<input type="radio" name="animatedGIFs" id="animation_no" value="animationDisabled" />
		<label for="animation_no">No</label>
						
	</fieldset>
</form>

And the JavaScript code for receiving the radio button data is as follows:

//SET GLOBAL VARIABLE AS A FLAG (ASSUME USER WANTS ANIMATIONS)
var useAnimatedGIFs = true;

function checkRadioButtonForAnimation() {

	// FIRST, SEE IF THE USER HAS CHECKED THE ID OF THE RADIO BUTTON ("animation_no") SAYING HE DOESN'T WANT ANIMATION)
	if(document.getElementById('animation_no').checked) {
		//CHANGE THE FLAG TO "false" IF THE USER DIDN'T WANT ANIMATION
		useAnimatedGIFs = false;
		
}
// (OTHERWISE, useAnimatedGIFs REMAINS "true")

[...]

function laterFunction() {

	//THE STRING FOR THE IMAGE TO BE DISPLAYED FOR CORRECT ANSWERS
	var rightBackgroundImageStr;

	// IF THE USER WANTED ANIMATION, LOAD THE ANIMATED GIFS WITH NUMERICAL HASHES
	if(useAnimatedGIFs === true) {

		rightBackgroundImageStr = "url('relative-URL-path-to-animated-image.gif" + "?" + (new Date()).getTime() + "')";

	}
	//IF THE USER DOESN'T WANT ANIMATION, LOAD STATIC GIF INSTEAD
	else {
		rightBackgroundImageStr = "url('relative-URL-path-to-static-image.gif";
	}

	[...]

	//IF THE USER ANSWERED CORRECTLY, DISPLAY A CERTAIN IMAGE
	if (chosenAnswer === correctAnswer {
		/DISPLAYS THE ANIMATED OR STATIC IMAGE (DEPENDING ON USER'S RADIO BUTTON CHOICE)
		document.getElementById("background-image-div").style.backgroundImage = rightBackgroundImageStr;

	}
	//IF THE USER ANSWERED INCORRECTLY, DISPLAY A DIFFERENT IMAGE
	else {
		//CODE TO DISPLAY THE DIFFERENT IMAGE
	}
}

(For people with data plans of 2 GB per month or more, this is probably not a major concern. But for those like myself with 500 MB per month plans, it could be an important consideration.)

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://www.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://www.ancientgreekkeyboard.com');
    and:
    define('WP_SITEURL', 'https://www.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://www.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 https://www.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

Date Time Load Time of Control (sec) Load Time with Static Caching (sec)
11/16/2018 17:50 1.300 1.080
1.280 1.100
1.280 1.310
20:56 1.340 1.260
1.260 1.130
1.030 1.090
22:45 1.140 1.360
1.410 1.570
1.440 1.410
11/17/2018 17:23 1.200 1.330
1.290 1.110
1.400 1.050
19:44 1.050 1.090
1.270 1.190
1.210 1.330
23:21 1.210 1.350
1.370 1.470
1.110 1.430
11/18/2018 12:37 1.210 1.330
1.180 1.070
1.010 1.240
15:12 1.290 1.130
1.140 1.120
1.280 1.110
20:16 1.400 1.280
1.370 1.140
0.967 1.070
11/19/2018 12:38 1.350 1.550
1.530 1.250
1.040 1.170
19:19 1.340 1.340
1.160 1.130
1.390 1.100
23:23 1.270 1.260
1.170 1.260
1.440 1.470
n 36 36
Average 1.254 1.241
Std Dev 0.136 0.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

Date Time Load time of control (sec) Load time of setting (sec)
9/20/2018 16:16 1.210 1.450
1.200 1.240
1.360 1.370
21:15 1.210 1.520
1.490 1.450
1.410 1.430
22:39 1.360 1.230
1.270 1.250
1.330 1.310
n 9 9
Average 1.316 1.361
Std Dev 0.101 0.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

Date Time Load Time of control (sec) Load Time of setting (sec)
9/21/2018 12:54 1.360 1.360
1.410 1.390
1.400 1.360
16:52 1.490 1.210
1.210 1.220
1.280 1.390
19:46 1.370 1.430
1.210 1.050
1.250 1.140
n 9 9
Average 1.331 1.283
Std Dev 0.098 0.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

Date Time Load Time of control (sec) Load Time with setting (sec)
9/22/2018 13:03 1.540 1.280
1.420 1.450
1.280 1.270
16:59 1.120 1.420
1.250 1.420
1.370 1.240
22:39 1.350 1.290
1.220 1.260
1.500 1.270
n 9 9
Average 1.339 1.322
Std Dev 0.136 0.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

Date Time Load Time of control (sec) Load Time with setting (sec)
9/23/2018 13:08 1.220 1.530
1.210 1.480
1.480 1.570
15:55 1.360 1.770
1.350 1.500
1.220 1.740
21:16 1.500 1.630
1.230 1.080
1.240 1.840
n 9 9
Average 1.312 1.571
Std Dev 0.115 0.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

Date Time Load Time of control (sec) Load Time with setting (sec)
9/24/2018 12:16 1.400 1.550
1.340 1.430
1.340 1.420
14:34 1.220 1.490
1.350 1.110
1.360 1.330
16:36 1.320 1.310
1.230 1.190
1.440 1.450
n 9 9
Average 1.333 1.364
Std Dev 0.071 0.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

Date Time Load Time of control (sec) Load Time with setting (sec)
9/25/2018 19:40 1.430 1.250
1.160 1.120
1.140 1.110
22:09 1.260 1.030
1.290 1.320
1.280 1.150
1.040 1.190
1.070 1.280
1.050 1.120
n 9 9
Average 1.191 1.174
Std Dev 0.133 0.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

Date Time Load Time of control (sec) Load Time with setting (sec)
9/26/2018 18:33 1.140 1.170
1.110 1.260
1.290 1.070
21:12 1.320 1.090
1.280 1.120
1.350 1.110
22:47 1.180 1.300
1.330 1.160
1.190 1.190
n 9 9
Average 1.243 1.163
Std Dev 0.089 0.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

Date Time Load Time of control (sec) Load Time with setting (sec)
9/27/2018 12:12 1.240 1.200
1.240 1.150
1.240 1.310
15:32 1.280 0.991
1.180 1.110
1.290 1.100
18:02 1.070 1.310
1.110 1.200
1.110 1.220
n 9 9
Average 1.196 1.177
Std Dev 0.081 0.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

Date Letter Grade Load Time of control (sec) Load Time with setting (sec)
9/28/2018 86 1.200 1.210
86 1.300 1.460
86 1.110 1.160
86 1.300 1.160
84 1.460 1.310
86 1.330 1.230
86 1.310 1.310
86 1.330 1.210
86 1.130 1.190
n 9 9
Average 1.274 1.249
Std Dev 0.110 0.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

Date Time Load Time of control (sec) Load Time with setting (sec)
9/29/2018 10:47 1.340 1.310
1.240 1.490
1.480 1.410
13:03 1.240 1.230
1.320 1.340
1.430 1.250
15:00 1.220 1.450
0.804 1.480
1.600 1.230
n 9 9
Average 1.297 1.354
Std Dev 0.224 0.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

Date Time Load Time of control (sec) Load Time with setting (sec)
9/30/2018 10:18 1.500 1.380
1.520 1.360
1.460 1.440
12:46 1.300 1.200
1.470 1.160
1.250 1.310
15:31 1.440 1.260
1.300 1.540
1.630 1.490
n 9 9
Average 1.430 1.349
Std Dev 0.123 0.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

Date Time Load Time of control (sec) Load Time with setting (sec)
10/1/2018 10:59 1.370 1.320
1.300 1.550
1.470 1.360
13:56 1.190 1.360
1.210 1.270
1.220 1.440
16:29 1.360 1.370
1.350 1.300
1.490 1.250
n 9 9
Average 1.329 1.358
Std Dev 0.109 0.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

Date Time Load Time of control (sec) Load Time with setting (sec)
10/2/2018 10:57 1.380 1.290
1.220 1.470
1.240 1.240
15:47 1.450 1.480
1.210 1.400
1.240 1.220
17:44 1.240 1.190
1.380 1.390
1.110 1.380
n 9 9
Average 1.274 1.340
Std Dev 0.107 0.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

Date Time Load Time of control (sec) Load Time with setting (sec)
10/3/2018 10:57 1.390 1.220
1.170 1.420
1.200 1.270
13:15 1.420 1.510
1.280 1.430
1.390 1.210
15:55 1.360 1.210
1.210 1.340
1.200 1.300
n 9 9
Average 1.291 1.323
Std Dev 0.099 0.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)

Date Time Load Time of control (sec) Load Time with setting (sec)
10/4/2018 12:01 1.460 1.440
1.250 1.450
1.230 1.250
14:11 1.380 1.240
1.600 1.530
1.270 1.300
17:11 1.270 1.600
1.390 1.210
1.290 1.300
n 9 9
Average 1.349 1.369
Std Dev 0.121 0.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

Date Time Load Time of Control (sec) Load Time with WP-Rocket (sec)
9/16/2018 16:45 1.230 0.873
1.490 0.914
1.240 0.970
18:30 1.240 0.907
1.510 1.150
1.240 1.210
20:52 1.420 1.120
1.220 0.910
1.190 1.110
9/17/2018 15:45 1.200 1.140
1.440 1.150
1.480 0.886
17:50 1.240 0.931
1.490 0.932
1.190 1.130
20:06 1.500 1.100
1.490 1.200
1.440 1.010
9/18/2018 10:45 1.480 1.360
1.520 1.250
1.410 1.360
13:46 1.410 1.260
1.520 1.330
1.630 1.250
16:12 1.610 1.320
1.490 1.420
1.390 1.270
9/19/2018 12:01 1.680 1.330
1.390 1.430
1.450 1.370
14:18 2.160 1.220
1.630 1.580
1.780 1.480
17:52 1.460 1.240
1.530 1.340
1.530 1.390
n 36 36
Average 1.453 1.190
Std Dev 0.191 0.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

Date Time Load Time with Swift Performance Lite (sec) Load Time with W3 Total Cache (sec)
9/5/2018 15:04 1.070 0.861
0.904 1.040
1.030 1.060
17:09 1.050 1.130
1.060 1.190
1.890 1.090
19:40 1.270 1.770
1.250 1.220
1.090 0.975
9/6/2018 13:46 1.140 1.150
1.150 1.160
1.070 0.888
16:57 0.927 1.150
0.967 0.860
1.090 1.150
19:14 0.959 0.849
1.020 0.994
1.130 0.994
9/7/2018 17:16 0.962 0.873
0.945 0.899
1.060 0.906
18:58 0.958 1.100
1.080 0.873
0.976 1.120
20:44 1.110 1.140
1.090 1.120
0.902 0.866
9/8/2018 10:21 0.958 0.910
1.110 1.210
1.070 0.951
13:36 0.911 1.080
0.994 0.887
0.954 1.110
16:02 0.967 0.872
1.100 1.070
1.050 1.130
n 36 36
Average 1.063 1.046
Std Dev 0.168 0.173

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

Performance Factors Swift Performance Lite W3 Total Cache
Overall Grade A (91%) B (88%)
Combine External JavaScript D (61%) F (44%)
Combine External CSS B (80%) B (86%)
Minimize DNS Lookups B (87%) B (88%)
Leverage Browser Caching A (92%) B (80%)
Remove Query Strings A (92%) B (87%)
Specify A Cache Validator A (100%) A (95%)
Serve Static Content fr. Cookieless Domain A (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

Date Time Load Time of Control (sec) Load Time with Swift Performance Lite (sec)
8/27/2018 16:05 1.340 0.886
1.410 0.890
1.440 0.837
18:36 1.360 0.849
1.340 0.852
1.420 1.070
20:48 1.310 0.986
1.440 1.080
1.410 1.060
8/28/2018 10:14 1.510 0.914
1.460 0.793
1.440 0.927
17:02 1.370 0.941
1.450 1.090
1.300 0.932
20:14 1.290 1.110
1.250 0.953
1.250 1.220
8/29/2018 17:07 1.400 0.923
1.250 1.010
1.240 1.030
20:41 1.280 0.939
1.250 1.080
1.450 1.010
23:00 1.580 0.927
1.280 1.210
1.220 1.100
8/30/2018 16:53 1.390 1.040
1.290 0.940
1.260 1.030
20:12 1.360 1.110
1.270 0.954
1.260 0.961
22:32 1.440 0.951
1.210 1.060
1.220 1.030
n 36 36
Average 1.346 0.992
Std Dev 0.094 0.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