Website speed tests

It’s Sunday, too hot to be outside, and I’m kinda bored. I think just for fun I’ll test-drive a few of the website speed checkers that clutter the web. Speed matters. WP, like any CMS, is handicapped from the start. My browser asks a flat html site for a page, the site says “OK, here you go.” By comparison, WP says “OK, sure. Hang around a bit. I’ll query and pull a bunch of stuff from the database, fetch some images, some CSS and Javascript files, and build that page for you.” So, I do what I can – or at least what I think makes sense – to make my sites speedy.

website speed tests

It makes sense to test my sites’ speed, to use the results to optimize where I can, and to track over time to catch any new speed bumps that arise. Challenge 1: There are so many available online speed checkers – which should I use? Challenge 2: Very inconsistent results from checker to checker, but also from the same checker at different times. Will circle back to the challenges; for now on to the checkers – in rough order of Google listing when I search on “website speed checker”. Some of the checkers allow me to choose a location. I’ll pick San Francisco or San Jose.

  1. The very popular Pingdom. And I do mean popular …
    Really? #273 in line? No thanks. I’ll move on.
  2. GTMetrix:
    Not too bad. My grade is A or B – I’ll average it to B+. Speed is a bit under two seconds.
  3. Google Page Insights:

    Score is ‘Good’, which I will conflate with a ‘B’. Page speed is “Unavailable”. Really? Google has ample resources to libel me as a purveyor of hate and a criminal copyright pirate, but has no way to check page speed? Are you kidding me? Not terribly helpful.
  4. UpTrends:
    Hmm. Score is great – 94, a solid ‘A’. Load time is awful – 4.4 seconds.
  5. WebPageTest:
    Hey! Straight A’s! Yea me.
    Load time 1.3 seconds – pretty good.
  6. DotComTools:

    On “Repeat Visit”, load time is 634 ms, very good.
  7. ThinkWithGoogle:

    Grade is “Good”, which I will conflate with a ‘B’. Load time is 4 seconds – seems pretty bad to me.
  8. Montis: No grade given. Load time 3.4 seconds – pretty bad.
  9. KeyCDN: No grade given. Load time 2.7 seconds – just OK.
  10. Gotta circle back and retry Pingdom – maybe it has unqueued:
    Load time less than a second – pretty good. Performance grade C – not so good.
  11. That’s it for the first page of Google search. But – gotta try one more. Buried around the middle of page 2 in the search results is my favorite website speed checker – GiftOfSpeed:


    Grade A and A, load time less than a second. Very good.

In summary, results are all over the damn place. My site’s speed grade is A, B+, B, or C. Load time is less than or second, or over 4 seconds. Also, there seems to be no correlation between grade and actual speed. Pingdom gives me a ‘C’ with less than a second load time, Uptrends gives me an ‘A’ with a 4.4 second load time.

Furthermore, if I use the same 10 checkers again, I will get different – sometimes wildly divergent – results from the same checker at different times.

So, what to do? My POV:

  • I disregard website speed and optimization grades completely. They seem arbitrary – almost random even – and have no obvious correlation to actual speed.
  • I stick with one checker. I use GiftOfSpeed. I have no real evidence, but it seems to me to be the most consistent. Others – Pingdom in particular – may be victims of their own success, too popular and therefore too overloaded to give accurate results.
  • To track a site’s speed over time, I do not use the raw load time. Rather, I use the delta between my site’s load time and that of a baseline site. My sites are WP, so I use WordPress.org as a baseline to measure my site’s speed against. I figure the experts at WordPress have optimized the speed of their site pretty well. If my site can match or exceed that speed – and they do, consistently – I think I am doing OK.

Rocket Loader rocks! (finally)

Since 2011 CloudFlare, even on their free tier, has offered a very promising, very frustrating feature called Rocket Loader. Rocket Loader promises to greatly accelerate the loading of JavaScript, turbocharging JavaScript-heavy sites like those that use WP.

Rocket Loader rocks

At the beginning, Rocket Loader was labeled ‘beta’ – meaning buggy – and gained an unfortunate reputation for causing wonky behavior, especially with WP sites. In my case Rocket Loader broke the sliders on my WP sites. So, I patiently waited for the bugs to be eradicated and the ‘beta’ moniker to be banished. The years crawled by. 2012 – still beta, still wonky. 2013 to almost half way through 2018 – still beta, still wonky. I had almost given up. I don’t mean to unduly criticize the good people at CloudFlare – they provide a truly awesome service of which I take full advantage of the free tier.  I benefit tremendously and they make not a penny from me. I owe them immense gratitude and they owe me absolutely nothing. Still, I was selfishly irritated waiting years for Rocket Loader to finally work right.

My irritation ended today. Rocket Loader graduated from beta and entered prime time on June 1, 2018 – but I just noticed today. In my admittedly so-far brief testing it works perfectly – it no longer breaks my sliders. And it significantly speeds up my sites. Using my favorite website speed test – GiftOfSpeed.com – on this site before Rocket Loader:

Load time 1.5 seconds, faster than 90% of tested sites. Pretty good. Maybe I don’t need Rocket Loader after all.

With Rocket Loader:

Wow! All metrics are improved. Load is time less than half, at 580 milliseconds – faster than 95% of tested sites. Rocket Loader rocks! Very much worth the wait.

http or https

Should my websites use standard plain text http, or https (i.e. SSL)? I need to consider ease of implementation, search engine optimization (SEO), security, and speed.

http or https

Ease of Implementation: Once I have a site up and running, http just flat works. If I choose to switch to https I need to …

  • Make a full site backup in case something goes horribly wrong.
  • Obtain and install an SSL certificate. This is easy breezy if my host provides free Let’s Encrypt, otherwise it can be a bit costly and time consuming.
  • Make some WP configuration changes.
  • Search/replace my WP database to change all ‘http://mysite’ to ‘https://mysite’
  • Cross my fingers and hope everything worked perfectly.
  • Since everything never works perfectly, troubleshoot the problems.

For ease of implementation, http wins hands down.

SEO: Google now favors secure sites. Not by much, but I expect the delta to increase over time. More secure = better search engine rankings. Https wins.

Security: If I allow for any sort of user input – logins, comments, contact page, or especially sensitive information like credit card numbers, gotta go https. Https is not a magic fix-all-security-problems solution, but it does encrypt data in transmission to foil eavesdroppers. Even if my site simply serves pages – in which case http should be just fine – some users just really like to see the secure lock in the browser window.

For security, https wins. Not even close.

Speed: There is an interesting ongoing kerfuffle on which is faster. Examples, On the “Https is faster” side: I wanna go fast: HTTPS’ massive speed advantage; And on the “No it isn’t” side: Stop. Just Stop. HTTPS is not faster than HTTP.

Https requires a bit more processing, so all else being equal http is undeniably faster. But – all else is not equal. When it comes to speed the question is not http vs. https but rather legacy HTTP vs. modern HTTP/2.  HTTP/2, the specification for which was published in March 2015, uses more efficient mechanisms for data streaming, and is much faster than HTTP.

While there is no rule preventing plain text HTTP/2, browsers and other applications only support secure HTTP/2. So, in practice, https is faster.

The Verdict: The ease of implementation of http is more than outweighed by the SEO, security, and performance benefits of https.

As of the date of this post, roughly 75% of websites use http, but well over half of all web traffic uses https. So, bigger, more popular sites have gone https, while most of us rabble are still living in the dark age of plain text http. The trend is inescapably toward https, and I gotta go there at some point. I might as well do it now.

Optimizing the WP Database

Optimizing the WP databaseEvery time I edit a post or page, WP keeps a copy of the old version in my database. It is a great feature, handy when I mess up and need to revert to the previous version. But once my post or page is final, I have no use for the prior revisions. By default, WP keeps all the old versions, forever, and they can add up over time. I recently checked one of my sites and was surprised to find 3,566 useless old pages cluttering up my database. A large, cluttered database slows my site, as the server takes longer to retrieve information.

I should always make sure I have an up-to-date backup of my site. This is especially true before doing any database maintenance. I never know when something could go horribly wrong.

To clean out old posts and pages, as well as other database clutter, I can use a popular free plugin called WP-Optimize. Once all the clutter is removed, WP-Optimize can defragment/compact the database tables for optimum efficiency. Since my site is on a LiteSpeed server I could also use similar functionality provided by the excellent LiteSpeed Cache plugin.

I can limit the number of future page and post revisions that are saved by adding a line to wp-config.php. In my case, I save the latest two revisions: define('WP_POST_REVISIONS', 2);

Update (2018-07-18):  Another cause of database clutter is deleted plugins. A well-behaved plugin should clean up after itself – giving me the option of removing all its data from my database when I delete it. Many plugins are not so polite. Deleting the plugin removes only the files, leaving now-useless database tables behind. A tool that can help with this is Plugins Garbage Collector. After making sure I have an up-to-date DB backup, I can run PGC to search my DB for tables left behind by deleted plugins, then remove those tables.

Custom 404 Error Page

In another post I present a case for using a short, simple text string to report 403-Forbidden errors. For Not Found errors, I want to serve a friendly helpful 404 error page that fits reasonably well with the look and feel of my site. But I still want to limit resource use to the extent practical, otherwise serving a lot of 404 pages could slow my site or even bring it down.

friendly helpful 404 error page

My solution is a custom 404 error page in my child theme, that includes simple html code to display the page with a minimum of resource demands.
<?php
/**
* Title
*
* Custom 404 error page (Not Found).
*
* @package responsive_mobile_child
* @license CC0, public domain
* @copyright Released, to the extent practical under law
* @since 2017-03-09
*
*/
// If this file is called directly, abort.
if ( ! defined( 'WPINC' ) ) {
die;
}
?>
<html>
<head>
<title>404 | a WP Point of View</title>
</head>
<body>
<p style="text-align: center; font-size: 2em; font-family: Verdana, Arial, Helvetica, sans-serif;">a WordPress Point of View</p>
<p style="text-align: center; color: #000080; font-size: 1.5em; font-family: Verdana, Arial, Helvetica, sans-serif;">Oops! The page you requested could not be found.</p>
<p style="text-align: center; font-family: Verdana, Arial, Helvetica, sans-serif;">The page may have moved or may no longer be available, or the URL may be misspelled.</p>
<p style="text-align: center; font-family: Verdana, Arial, Helvetica, sans-serif;">Please return to the <span style="color: #000080; font-size: 1.1em;"><a href="https://wppov.com">WP POV home page</a></span>.<br>From there you can search for the lost page, or visit some of our many other pages.</p>
<p style="text-align: center; font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 1.1em;">Error code 404 - Page Not Found</p>
<p><a title="wppov.com" href="https://wppov.com"><img style="display: block; margin-left: auto; margin-right: auto;" src="https://wppov.com/wp-content/uploads/2016/12/wppov-logo-169x100.png" alt="a WordPress Point of View" width="169" height="100" /></a></p>
</body>
</html>

CloudFlare Speed Settings

miscellaneous CloudFlare speed settingsIn another post I cover a CloudFlare page rule for blazing site speed. This post discusses miscellaneous CloudFlare speed settings. CloudFlare, even at the free tier, offers a plethora of speed and security settings that seem daunting at first. Most of them work fine using the default setting, and I can adjust settings at my own pace as I am able to make time to learn and optimize.

Crypto

The first CloudFlare performance setting is Opportunistic Encryption, on the Crypto page.

CloudFlare speed settings

 

Opportunistic Encryption provides performance and security benefits over HTTP. I use HTTPS exclusively, so as far as I know Opportunistic Encryption does nothing for me. The default setting is ‘On’, and I leave it that way.

Speed

Auto Minify removes unnecessary characters like whitespace, lowering the amount of data that needs to be transferred to visitors and improving page load times.

I have to be cautious to minify only once. Since I use CloudFlare to minify, I must not also minify using a WP plugin. Multiple minifies break stuff.


Rocket Loader optimizes JavaScript resources.

Unfortunately Rocket Loader is in Beta (i.e. Buggy), and CloudFlare acknowledges “… not all scripts work with this feature.” Rocket Loader intermittently stops my sliders from sliding, or sometimes even loading. I use it only on slider-less sites. I am keeping an eye on it though, and will retry it when the Beta label vanishes.

Update: After seven years in Beta, CloudFlare announced the General Availability (GA, e.g. production operation) of Rocket Loader on June 1, 2018. In my initial brief testing it seems to not break sliders now, and provides a significant speed boost. I am turning it on for a trial run.

Caching

The Caching Level setting only goes up to Standard. For more aggressive caching I use a page rule for blazing site speed on relatively static sites like this one.


Browser Cache Expiration specifies how long cached resources will remain in the visitor’s browser cache.

Browser Cache Expiration: Respect Existing Headers

WordPress presumably does a good job of determining the optimal browser cache duration of various resources – e.g. longer for static resources, shorter for dynamic resources – so I don’t want CloudFlare to mess with this. I leave this setting at the default “Respect Existing Headers”.

Update: I changed the ‘Browser Cache Expiration’ setting to 1 month, to bump up my speed scores in services like Pingdom, GTmetrix and PageSpeed. Surprisingly, it seems to have bumped up my actual site speed a bit as well.

Caching Plugin

LiteSpeed cache logoI chose my web host carefully. My sites are hosted on a LiteSpeed web server, so I am able to use the remarkable free LiteSpeed Cache (LSC) plugin. LSC provides much more than just lightning-fast server-side caching. In also includes a suite of optimization tools such as: Database optimization; Image optimization – which seems to be equal to or better than the paid/premium versions of competing plugins; Connection to CloudFlare so I can put CF in development mode or purge the CF cache; and Miscellaneous settings like ‘Remove query strings from static resources’.

Using my two favorite website speed checkers, WebPageTest.org and GiftOfSpeed.com

  1. LSC Off | CF in Development Mode (baseline site)
  2. LSC On | CF in Development Mode (significant speed increase over baseline)
  3. LSC Off | CF Caching On (a significant speed increase over LSC)
  4. LSC On | CF Caching On (no significant speed change over CF alone)

A few observations:

  • On my relatively static sites like this one, I use a CloudFlare page rule for blazing site speed. On these sites I am not able to squeeze out any more speed by using a caching plugin – even an exceptional one like LSC. So why run LSC on these sites? Because of the other optimization features that LSC offers, and because it boosts site speed when CF is in development mode or doesn’t have a page cached for some reason.
  • On sites with dynamic content, I use CF with default cache settings. On those sites, I do get a nice increase in speed by using LSC in addition to CF.
  • Kinda funny how my Compress Images grade on WebPageTest jumped between A and B even though all tests used the same images. I guess my images must be borderline A- / B+.
  • Strait A’s on the final test. Yea me!

Many LSC features only work on sites hosted on LiteSpeed web server. For sites hosted on Apache, I like Comet Cache for its plug-and-play simplicity as well as performance. The very popular W3 Total Cache (W3TC) is another excellent choice.

CloudFlare page rule for blazing site speed

CloudFlare page rule for blazing site speedCloudFlare, even the free tier, improves my site speed and security – so much so that I use it for all my sites. The default settings boost site speed by global distributed caching of static content. Static content, by CloudFlare’s definition, excludes HTML. This makes sense for dynamic sites with frequent new posts and user comments. For my sites like this one, that have less frequent new posts and do not allow user comments or other dynamic content, I can dramatically increase site speed using a page rule. The free tier gives me three page rules, and I need the first two for login security. The third – and order is important, it needs to be after my login security rules – supercharges my site speed.

CloudFlare page rules for login security

*wppov.com/*
Cache Level: Cache Everything, Edge Cache TTL: a month

Kinda obvious but worth stating – replace “wppov.com” with your site URL. With this setting, HTML is globally cached along with ‘static’ content.

Example speed tests using tools.pingdom.com

1. Baseline site, CloudFlare paused – my web host is already pretty speedy, Faster than 64% of tested sites:

Site speed check baseline

2. CloudFlare using default cache settings – Faster than 88% of tested sites:

Speed test, CloudFlare default setttings

3. CloudFlare using blazing fast page rule – Faster than 99% of tested sites:

Site speed test blazing fast
For my relatively static sites I use the blazing fast page rule and no caching plugin. For my dynamic sites, I use the CloudFlare default cache settings pared with the excellent Comet Cache plugin.

Update: My host uses LiteSpeed web server. I switched from the excellent Comet Cache to the even more excellent – if hosted on LiteSpeed – LiteSpeed Cache plugin.

Site speed has many variables, some of which I can’t influence, and the variability is reflected in pingdom test results at different times. I don’t always hit 99%, but I am tickled when I do.

403 Text String

If my site gets attacked, it could serve up a lot of 403-Forbidden error pages, which would use a lot of resources, slowing my site or even bringing it down. For 404-Not Found errors, I want to serve a friendly helpful page that fits in with the look and feel of my site. Legitimate visitors should rarely if ever encounter a 403-Forbidden error though, so I prefer to politely limit resource use to the extent practical.  My solution is a custom 403 text string, using the following line at the beginning of my .htaccess file:

ErrorDocument 403 "403: Sorry, not permitted."

A user who encounters a 403 error will see a simple text message in his or her browser, similar to the following image.

Custom 403 text string

Serving a simple text string requires far fewer resources in comparison to a php or html page.