Incsub, LLC (aka WPMU DEV) have the art of producing customer fear down to a science. For example, you can take their WP-Checkup for free, once in a 24-hour period. Their speed-test is scary but nonetheless wimpy at best. We’ve written about other SEO and Security portions of that test. Read about it.
But in this article, we focus only on speed. Our performance score was a 96/100. But scores are meaningless. There are 10 speed parameters. Here they are:
1Remove render blocking. 24/100
The test identified one offending file on PagePipe. It’s a CSS file loaded by a plugin called Add Search to Menu. We like this plugin. The test told us none of the above-the-fold content could be render until this CSS file got out of the way. Now from experience, we know above-the-fold rendering blocks are a deceptive waste of time. It’s pure crock. They gave us a red-alert alarm on this little thing. Why? Instilling fear.
Where is the fold on a mobile device anyway?
WordPress almost always fails render-blocking tests. Does Google punish your SEO for your failure? No. They don’t use any concocted speed parameters from PageSpeed Insights for their secret algorithm. They only use Time to First Byte (TTFB). That’s a function of your server responsivity. It has nothing to do with website design – or site performance optimization. Fast TTFB is something you buy from a hosting provider.
People ask us, “Should I rewrite my code or use plugins to remedy render blocking?” The answer is: no. It doesn’t make any difference in speed or SEO. So forget it. More than likely you’ll end up breaking your site over nothing. You’ll see a white screen of death – or a page of unstylized CSS. Not worth the grief.
Remember: This wasteful test doesn’t tell you how fast your site loads in milliseconds. That’s what counts. Not some silly score. Go test PagePipe.com on Pingdom. Milliseconds count, not that 99 “A” score.
2Minify CSS. 85/100
The test said we should minify a theme file: twentyseventeen/style.css to save 3.9k in page weight. Almost 4k. So much! We know how to minify with online minification tools using copy and paste. We could do that hassle – and maybe we will. But really. Is this significant? They gave us a yellow alarm on this one. Grrr!
Anyway, this test said we could reduce two theme-related files by 1.9k. Almost 2k. Wow! We’d risk breaking our site for that? I don’t think so. And we’ve tried minification. It breaks our ecommerce plugin for selling books. No thank you.
4Enable compression: 100/100
This refers to Gzip compression. It’s probably already activated on your server by default. If not, a simple, free plugin can switch it on. Learn more about Gzip compression here.
5Prioritize visible content: 100/100
Boy-oh-boy! What a relief since we didn’t even try. This is another bogus and silly parameter. Makes no difference whatsoever.
7 Minify HTML: 100/100
Interesting result. We’re not minifying HTML with a plugin. Again minification is not a big deal. Small gains – if any.
8Improve server response time: 100/100
This is Time to First Byte (TTFB). The only way you can improve it is switching to a different hosting provider. Our TTFB is 176 milliseconds on magnetic, shared, cheap GoDaddy hosting. That’s fast because we don’t use HTTPS/SSL certification which slows down TTFB by up to an additional 500 milliseconds. We don’t need it. All our transactions are via PayPal. And we don’t use signup forms for anything but email addresses. Read more about how HTTPS/SSL slows down your site.
9Avoid landing page redirects: 100/100
We’ve heard some people have problems with redirects. We don’t. It’s a simple matter of using the right settings in WordPress. And the Redirection plugin for changes. This is a silly thing to check in a speed test.
⒑Leverage browser caching: 100/100
We use two caching plugins: Cache Enabler and WP Super Simple Speed. Two caching plugins? Really? How odd. Are we paranoid? No. We’ve just found these two together do a nice job for us. Only repeat visitors benefit from browser caching. First time visitors are the bulk of your traffic – usually new visitors are around 60 to 80 percent. So caching doesn’t help everyone. Sometimes there’s no speed benefit at all. You have to test using millisecond comparisons.
Attempting to dictate the rules of speed quality, Google made the mobile Internet worse. How did they shoot their own foot?
Well, it didn’t happen overnight. Google shot over and over again. Destructive repetition. Foot target.
Google’s speed misadventure began in 2010. They announced speed as a factor in ranking websites. But Google was vague how much speed would affect SEO. Nor would they tell which aspects of speed made a difference. Everyone got excited. Lots of wild guessing. And soon, a web myth emerged. Never spoken by Google but assumed by the herd: “Speed is now critical to good SEO.” A blatant lie people use to sell speed services, addons, plugins, themes, and books. Panic in the air.
The truth is “page speed” never made much difference at all. Not for SEO anyway. It did for UX. It’s bad user experience to keep visitors waiting – especially on mobile devices. Google even said relevant content and UX were more important. But many website owners and bloggers ignored or missed those important words.
How much load time does www.google.com take? Using WebPagetest.org (owned by Google) the result is: 2.196 seconds. The full-load time can vary from 1.270 to 2.204 seconds depending on test server location. That’s right seconds. What? That naked page only has a logo and a search field. Tell us more: 16 HTTP requests. 471k page weight. Time to First Byte is 593 milliseconds.
Improve Server Response Time: This rule triggers when PageSpeed Insights detects that your server response time is above 200 milliseconds. – Google.com
Google TTFB (Time to First Byte) is 593 milliseconds?! Surely that’s a mistake. Nope. Their TTFB alone is almost triple the 200-millisecond Google rule.
Google doesn’t even keep their own edict of 200-millisecond TTFB (server response time). Their homepage TTFB ranges from 369 to 774 milliseconds depending upon where in North America the test server is located. So results fluctuate and vary.
Faster TTFB size is a benchmark of a well-configured server application.
TTFB is server overhead. An unfortunate delay caused by mechanical or physical parameters. It has nothing to do with page content or web code. TTFB is mostly hardware dependent. It’s usually beyond your control. TTFB is the duration after calling for server assets until the arrival in the browser. Good TTFB is under 200 milliseconds. Bad TTFB is one second and up. Terrible is above 4 seconds. Yes. Some servers are just that rotten.
So TTFB is something you buy. You pay for it. Your host owns it – not you. You can’t build or code it into your WordPress website. In other words, the poorer you are, the worse your TTFB. The richer … well, you get the idea. So much for web equality and democracy.
Yet, TTFB is the only parameter Google uses to check your site speed in their secret algorithm. And it improves your ranking less than 0.5 percent.
But, Google has the fastest servers in the world. Correct? Wouldn’t their TTFB be the best and faster than 593 milliseconds? I mean, our cheap GoDaddy hosting gets better than that. Why the difference? It’s Google’s SSL Certificate. Read more below how this causes speed delays.
PagePipe doesn’t use SSL certification. We don’t need it. We’ll save our 500 milliseconds. Sales transactions are managed securely and efficiently by PayPal. Yeah. We sell a downloadable ebook, Toxic WordPress.
Well, here’s another place Google shot themselves in the foot: Their HTTPS / SSL initiative in 2015. It wasn’t moving along like they wanted after a few years. So they again said, “SSL certification will not only affect security – it will now affect page ranking.” Everyone got excited again. People started adding this non-feature to their websites in droves. Did they all need it? No. Did it help SEO? No. Did it kill speed? YES!
HTTPS / SSL server handshaking creates an initial stall in making Internet connections. There’s a slow delay before anything starts to render on your visitor’s browser screen. This delay is measured in the Time-to-First-Byte information (aka TTFB).
What is the typical TTFB delay caused by SSL certificate handshaking? 500 milliseconds. That’s 25 percent of a 2-second performance budget.
Learn about the gory details of this silly blunder by Google:
Are we done bashing on Google and their weird speed policies and practices? Not yet. We want to mention Google AMP (Accelerated Mobile Pages).
In 2015, Google said articles served from its Internet network were four times faster. That’s right. But developers disagree. Engineering or “designing in” page optimization gives the same or even better results. That’s right. It appears Google has a hidden agenda not-so related to speed. That’s their mask.
PageSpeed Insights is the worst speed test on the web. Why? It’s usually impossible for WordPress to pass this test. WordPress almost always has jQuery enqueued. That causes goofy warnings. But Google doesn’t use PageSpeed test scores in it’s ranking algorithm. They use TTFB (time to first byte). It’s a frustrating waste of time.
We’re almost done! We must discuss Google Fonts and their impact on mobile speed:
External font scripts like Google Fonts slow down your site. We guarantee websafe fonts are faster. According to HTTP Archive, as of October 2016, web fonts (like Google Fonts) are just over 3 percent of an average page’s weight.
Disabling with Remove Google Fonts References plugin makes an average difference of only 53 milliseconds. But in the extreme, one theme had a 300 millisecond gain in speed. In some cases, there was no change in speed at all.
The difference in weight is anywhere from 60k to 300k. Again, it’s wasted mobile bandwidth.
Would we delete Google fonts and go with default browser fonts to save 300 milliseconds? You bet. When we’re working on getting under 2 seconds or even 1 second, that can make a big difference.
Again, there are times requesting Google Fonts will throw a 1-second delay. Why? We don’t know. Go ask Google. And, of course, the more fonts you call the slower things get. There’s a plugin that combines the Google font requests. Google WebFont Optimizer finds every Google Font request. It bulks them all together. Then your website only asks Google once for the fonts, instead of multiple times. Still, our preference is to delete Google Fonts completely.
OK. We’re finally done bashing on Google ruining speed. We may get blacklisted. It was worth it.
Google edicts! We’re sick of them. The new HTTPS speed penalty is incredible. To us, it’s horrible and appalling. There is a myth HTTPS / SSL Certification makes no increase in page delays. Our testing says otherwise. Read on.
“HTTPS sites also load significantly faster. In a test on HTTP vs HTTPS.com, the unsecure version of the page loads 334% slower than HTTPS.” – A3 creative Solutions
“HTTPS did have an impact on my page load times, however the difference is negligible and I only noticed a 300 millisecond difference.” – Dean Hume“
I need to make an apology … On Tuesday, I switched Blogging Wizard over to SSL (https). But in the process, I managed to crash the site completely… twice. Yep, twice”. – Adam
The quotes above reveal the foolishness of many people about site security and speed. HTTPS / SSL server handshaking creates an initial stall in making Internet connections. There’s a slow delay before anything starts to render on your visitor’s browser screen. This delay is measured in Time-to-First-Byte information (aka TTFB).
The HTTPS overhead (delay) is NOT due to the encryption. The overhead is due to the SSL handshakes. An extra time-to-first-byte delay of about 400 to 500 milliseconds is typical. Sites that were under 100 milliseconds TTFB are now over 500 milliseconds TTFB. When your performance budget is 2 seconds, that’s 25 percent waste.
HTTPS is slower because it does double the work. A normal HTTP request does a “2-leg” delay for network connections. This a round-trip request and response. With HTTPS, you have 4-legs (2 round trips). It’s 100 milliseconds to travel between the client and the server. That means your first HTTPS request is at least 500 milliseconds. (That’s what were seeing happen.)
HTTPS handshake overhead appears in Time-to-First-Byte information (TTFB). Common TTFB ranges from under 100 milliseconds (best-case) to over 1.5 seconds (worst case). But, of course, with HTTPS it’s 500 milliseconds worse.
Roundtrip, wireless 3G connections can be 500 milliseconds or more. The extra trips doubles delays to 1 second or more. This is a big, negative impact on mobile performance. Very bad news.
So if you use SiteGround 1.2 second TTFB + 500 ms for SSL + 125 ms for CloudFlare redirect = 1.825 seconds TTFB total. Subtract that from 2 seconds and you don’t have much left (175ms). That’s the result on a desktop – not mobile.
To put those times in perspective, a free WordPress theme loads in under only 50 milliseconds.
HOW MANY HAVE MADE THE SWITCH TO HTTPS SO FAR?
SSL by Default Usage Statistics
Only 1.9 percent of the top 1 million websites redirect users to a default HTTPS/SSL version. – trends.builtwith.com
Less than 2 percent! Hardly the stampede of panic many bloggers claim. Some are saying 30 percent of the web made the switch. That inflated bump occurred after Wikipedia switched to HTTPS. This shows the impact one powerhouse site can have. The English Wikipedia includes 5,475,729 articles and it averages 650 new articles per day. You can see why it made a statistical difference in HTTPS usage. But that hardly means everyone is using HTTPS.
Google announced using HTTPS as a “lightweight” ranking signal in search algorithms. Google stated if all factors are equal, HTTPS will act as a tiebreaker in search engine results. That was in mid-2014.
Google didn’t get significant compliance after 2 years. So, they incentivized moving from HTTP to HTTPS. Google Chrome browsers started shaming unencrypted HTTP websites. How? With a little “shield icon” in the Chrome address bar. See chart below.
We admit we love the irony of testing TTFB on Google’s page with ByteCheck.com online testing tool:
Google’s TTFB for their HTTPS-information page is 407 milliseconds. Oops! It could have been less than 100 milliseconds – if they left HTTPS off the site. Is there a monetary or even information transaction on this page? Nope. Sheer waste of speed. Especially for mobile users.
Let’s look at a few more examples:
This site formerly changed hosts to avoid a 1.5 millisecond TTFB. The new host had a TTFB of less than 100 milliseconds. Bravo! But today, after the site owner added SSL Certification, TTFB is 533 milliseconds. We ask: In this case, how much additional TTFB delay is caused by HTTPS / SSL Certification? Does he need SSL? No. He just has email signups. No monetary transactions!
459 milliseconds wasted!
That’s the same as adding a video or podcast player to every single page and post of the site.
If you botch installing HTTPS, you can end up with duplicate content issues. You’ll have both HTTP and HTTPS versions of your page getting indexed. Different versions of the same page might also show up in search engine results. This will confuse your visitors and lead to a negative user experience. HTTPS has a minor effect on search rankings. Producing quality, relevant content is still the most important SEO tactic.
To correct HTTPS problems, you have to do 301 redirects for every page and post of your site. Bummer! It takes time for Google to re-index your website and a certain drop in rankings will most likely happen.
“Don’t make the switch to HTTPS solely for SEO purposes. It’s a resource intensive process and there isn’t a strong correlation between the two.” – Neil Patel
There is no point serving a blog over HTTPS when you have no sensitive data exchanged. Why on earth would Google force you to do it? Why would you favor a secure blog over a non-secure blog, if you don’t exchange any sensitive data anyway?
“My recent profile of my homepage, HTTP vs HTTPS, the average load times were 1.5s and 4.5s, respectively. When looking at the connection details, the big slow down factor was the extra round trips due to the SSL handshake. Mobile browsers over 3G was even worse. The numbers were 5s and 9s, respectively.” – Clint Pachl
Do site owners realize the contradictory nature of Google edicts about speed?
Google’s claim: To help you stay safe on the web, Chrome requires websites to use certificates from trusted organizations. – support.google.com
The argument is that the website owner is assured they’re going to the right website owned by the right party. In a perfect world, this would be correct. In the world we live in though, it’s incorrect. Not because the certificate doesn’t verify the owner – it does. If a website housing a phishing page has verified HTTPS, it will show the user the lovely green padlock. Everyday users see the padlock and trust everything else from there, even if it’s from a different domain. Deception!
HTTPS isn’t going to stop the spying of anything. The average user doesn’t care. HTTPS is not going to stop websites from getting hacked. Nor the distribution of malware or keeping website owners safe.
HIDDEN COSTS OF HTTPS
You can get an SSL certificate for free. Blog posts debate the value of a free SSL Certificate. But, the costs can shoot up to $1,499/year if you opt for an SSL certificate from a provider like Symantec. You don’t have to provide corporate documentation to get SSL Certification. The authorization may be a simple email. Confirm the email inquiry, and you’re accepted as the authorized domain holder. Can Free TLS Certificates provided by Let’s Encrypt still be hacked? Absolutely. Anyone can get an SSL certificate – including hackers. They can set up a site to harvest information.
SSL Certificates aren’t justifiable for small business owners with limited budgets. Are you a blog owner that only asks for email info from your visitors? You’re better off spending your limited budget somewhere else.
But what if you’re using secure PayPal as a payment gateway? Why do you have to wear the derogatory “Scarlet Letter” on your site’s address bar? Why does a site that’s collecting zero information from anyone need an SSL certificate? It makes no sense at all. If your web site doesn’t have financial transactions, why do you need an SSL certificate?
If you have small, lightweight, 1M page weights or less, stick with HTTP. It’s all you need.
It’s often implied (pure lies?) HTTPS secures your website. It won’t. SSL Certification doesn’t make a web site impervious to hackers. Labeling a site as secure because it has SSL is wrong. In error, users think they’re using a secure site when in reality its not better than before.
What HTTPS will do is deliver the intended good or bad information securely. We repeat “good or bad” information. HTTPS is indifferent to what’s transmitted. Infected websites distribute malware. HTTPS doesn’t do anything to ensure displayed information’s integrity. HTTPS will also deliver manipulated information to unsuspecting website visitors. Installing a Secure Socket Layer certificate prevents man-in-the-middle attacks. That’s it. It doesn’t warn of evil.
An encrypted HTTPS connection doesn’t stop attackers from hacking a website or server. It won’t stop an attacker from exploiting software vulnerabilities. They can still do brute force access. Or cause Distributed Denial of Services (DDOS) attacks.
Encrypting information over HTTPS can be a good thing for some users – but not all users.
If you need speed – and don’t have critical confidential information – forget HTTPS and SSL Certification. Stick with the cheaper and faster HTTP.
Visual Composer is a $34 page builder for WordPress.
We don’t use Page Builders. Mobile sites don’t usually need them with only one column of content. We find them too frustrating (slow) and in the end we can get the same results (only faster) using discrete plugins and other workarounds.
We did an investigation of a PagePipe reader’s site. It was built with Visual Composer using the $25 paid theme Vertikal:
Theme Vertikal (built on top of Bootstrap).
Vertikal theme is a multipurpose theme.
Features left, vertical, animated navigation menu.
BEST-CASE SCENARIO Pingdom.com to Dallas, TX, USA:
Cache Enabler and WP Super Simple Speed combined. WP Super Simple Speed enables Gzip for you – among other things. Don’t be afraid of the two-year staleness warning on WP Super Simple Speed plugin. It works fine with PHP 7.1.
WP jQuery Plus is undetectable. It depends upon if the Google version is in the cache. Which it probably is. But no speed test will reflect the improvement of an asset that is already present. It’s transparent. But you will see changes in the “waterfall” of page elements. Check that for file name changes. This helps you verify where the jQuery source is coming from.
Images: 7 PNGs and 1 JPG. Low-hanging fruit
60% of page weight is images (pretty typical). Three optimize-image suggestions:
Reduced to actual dimensions of PNG 250px wide instead of JPG 2,048 px wide. File size reduction: 166k to 8k = 158k savings.
Convert from PNG to JPG. Reduction: 267k to 35k = 232k savings.
Convert from PNG to JPG. Reduction: 80k to 18k savings = 62k savings.
Changing those three images reduce the page weight by 452k. The original image weight total was 552k. So this reduces the image weight by 81 percent. With no loss in image quality.
Unfortunately, even drastic image changes often won’t reduce speed by half.
What made the biggest improvements? Cache Enabler plugin reduced TTFB from 1.35 seconds to 364 milliseconds. Image optimization did the rest of the heavy lifting.
Suggestions “How good is good enough” depends upon percentage of audience visits via mobile devices. They need better speed than required by desktop visitors. Google recommends below 3 second load time. We recommended 2 seconds.
Here is our reader’s question: “What is your recommendation for developing WP pages? Is there an editor that can make developing pages more time effective while still enabling a fast loading website?”
WordPress is adding Gutenberg editor to WordPress 5.0 core. It will change how pages are built. Study about it or test with the Gutenberg plugin.
A 3,760-word article at WP Elevation is about the pain of producing websites. The article expresses everything we hate about website creation. The thought of building “explosive live hand grenades” stresses us. Just reading the article was stressful. Why?
Because it’s true. The nit-picky horrors described are exactly what occur during web projects. Client or website owner expectations are high. Their technical knowledge is often low.
Last month a new monster arose on the WordPress horizon. New problems for PagePipe anyway.
The fragile nature of WordPress and PHP v7.1.
Why does adding PHP 7.1 break your site? Our recent GoDaddy-host-server transition rattled the nerves of even the initiated. It’s a good example of what goes wrong. Upgrading PHP version 5.6 to version 7.1 is a simple C-panel setting – but not without potential consequences.
PHP 7 released long ago on December, 3rd, 2015. GoDaddy didn’t add this server option for a year and a half. Why? Because they knew the changes might break hundreds of thousands of WordPress websites. They left it up to users to perform the update. And they delayed the service call costs for as long as possible. The GoDaddy default version is set to 5.4. Making users choose their poison was smart. Users then are responsible for breakage. Or dialing back the PHP version themselves – or tracking down fixes. GoDaddy is blameless – sort of.
Above: Pie chart – Percentages of WordPress sites using different PHP versions.
Risk breaking my site? Why even care about PHP version 7.1?
PHP is the code of WordPress, a server-side programming language. It first appeared in 1995. All themes and plugins use PHP, too. Upgrading your site to run on PHP 7 instead of PHP 5.6, you’ll improve the performance of WordPress by 2x. That’s right. Twice as fast is the typical gain in speed. For us, that’s phenomenal. We’ve anxiously waited and watched for this no-extra-cost, speed opportunity. Free speed. Most vendors upgraded long ago. So we felt snubbed. But we didn’t change hosts. We like bragging about good speed achieved under the worst conditions!
PHP 7.1 isn’t going to break WordPress – it may cause some of your plugins to malfunction. Perhaps your theme. But the result is the same, your site appears broken. You can test all your plugins using a free plugin. Naturally! We tested with:
With this plugin, you can check your site for PHP 7 compatibility.
So what broke after the change from 5.6 to 7.1?
Broken Link Checker – compatible – warning 1 – This plugin broke the site when viewed on an Apple iPad. Meaningless code was all over the screen. We disabled the plugin.
Simple Content Adder – We got a red flag for the file revisions.php. But we couldn’t find it breaking anything. We left it as-is.
SS Downloads – red flag – This favorite old plugin broke the site with PHP error screen. The plugin failed because it triggered a fatal error. The plugin is for email capture before PDF downloads. We had to dump the plugin. Presently, all our downloads don’t need signup.
Title Experiments Free – compatible but 7 warnings. We wrote plugin author, Jason Funk, and he updated the plugin to version 8.9 for PHP 7.1 compatibility. No more warnings. Thanks, Jason.
WordPress Popular Posts – compatible – 24 warnings. The plugin stopped gathering data for page visits. This is the primary reason we use this plugin. It’s very popular with 300,000+ active installs (v3.3.4) but not updated for over 1 year. Why? It’s a pain to get things approved by WordPress. GitHub has version 4.0.0 free substitute – and it’s PHP 7.1 compatible. It has slow Font Awesome onboard but it’s not enqueued. We’re thankful. We like the new GUI control panel for the plugin. The original plugin was a 125k zip file. The new one is 759k. Most extra weight is font overhead for the control panel. It doesn’t affect your site’s front end.
How fast was PagePipe home page after the switch to PHP 7.1? 699 milliseconds unprimed cache and 440 primed. Super fast even on GoDaddy mechanical, shared server with no CDN.
If you search the phrase “Essential WordPress Plugins,” you’ll get about 1.8 million results. They all tend to regurgitate suggestions for the same old plugins. Copycat content. No wonder the identical plugins keep getting more installs. Even when better alternatives exist.
Includes important tips for mobile speed without coding.
83 pp, 362k, 8.5 x 11 inches, PDF download.
Sorting and testing all the new plugins is too much work. So people don’t test. They assume. The assumption is “popularity” is good. For plugins, that is usually decided by looking at the number of active installs. Active installs is not a sign of quality or performance. It’s a standard of herd mentality.
Herd mentality, or mob mentality, describes how people are influenced by their peers to adopt certain behaviors. Examples of the herd mentality include nationalism, stock market trends, superstition, and home décor. —Wikipedia
To Engineer is Human by Henry Petroskiis a book about engineering failures – mainly of buildings and bridge structures and airplanes during the 1980s and before. The main takeaway from the book is still applicable – and maybe even more so today: When technology or ideas are changing rapidly, there is never the opportunity to build a history or library of experience. This increases errors. Experience is what prevents accidents and disasters.
New upgraded versions of WordPress come out multiple times each year. And new plugins are being introduced at a breakneck pace. In 2013, 15,000+ plugins were in the WordPress plugin repository. In 2014, there were 29,000+ plugins in the repository. By 2015, the number was 35,000+. By Sep. 2016, over 46,000+ free plugins in the repository. And today, over 55,000 plugins. It’s difficult to stay on top of that rapid rate of change. It’s staggering.
To make a fast decision, it’s plainly easier to select from the most popular plugins – and consider that good enough. There are over 55,000 free plugins in the repository. And this doesn’t count any of the plugins available on GitHub where authors refused to go through the WordPress red-tape of acceptance.
You can choose any plugin from the TOP100 and from our experience it will be the slowest and most bloated plugin in its class. For example: #1 Akismet: 52M installs, #2 Contact Form 7: 42M installs, #3 Yoast SEO: 33M installs, #5 Jetpack: 28M installs. These are all heavy plugins and either directly or indirectly affect load time. We see these plugins installed on most slow sites.
Plugin popularity is rarely an indicator of good value. People assume they must be good. At one time, they were either the-only-game-in-town or repaired or compensated for WordPress deficiencies that later became solved with new WordPress versions. So even though the need for “repair” was gone or obsolete, the herd kept installing out of habit and myth. It became de-facto standard best practice.
Many recommended “essential” plugins have negative speed repercussions.
Our rule of thumb is: the more popular a plugin is (active installs), the higher the probability it’s a slow loading plugin. Why? We don’t know exactly why this correlates. But it holds up in our speed testing.
It’s the quality –not quantity– of plugins that slows down a site. Speed testing free plugins and themes is our specialty. Millions of herd-mentality WordPress plugins slow down the Internet, waste web resources, – and use up your precious time.
PagePipe.com (our blog) has 53 active plugins. It loads in under a half second in the USA and about 1.2 seconds for Europe (Pingdom.com). It can vary. That is using the cheapest, shared, old-magnetic GoDaddy hosting located in Arizona. No CDN. It will go even faster when GoDaddy updates to PHP 7.1 – but they’re running on outdated version 5.4. We share our server with 24 other domains. Why? We want to prove a point: You can use “speed strategy” rather than throwing money at load-time problems.
Our Mantra is avoid popular plugins. High number active installs means they’re the slowest.
We don’t know why “popular = bloated.” We speculate the plugin authors are content and apathetic to speed and quality. Popular plugins existed first and use old unoptimized coding techniques (obsolescence). They tend to get heavier with revisions instead of lighter (kludges).
The authors of old plugins don’t have competitive motivation to be lean for speed. This isn’t true for newer, less-installed, lighter plugins. Speed (load time) is now a desired feature we’re seeing more because of mobile devices. But fresh, fast plugins are not easy to find. There are 55,000+ plugins in the free directory. Wow! An ocean.
What is more characteristic of “goodness” is retention rate. That’s calculated by taking the active installs and dividing by the number of downloads for all time. A plugin with a retention of 20 percent is pretty good. If it’s 5 percent or less, it’s a danger sign. They were tried – and dumped.
Slow plugin’s download file size is a clue. Bigger files load slower. There are some exceptions – but they are few.
In our new Toxic WordPress, we present typical time-wasting herd plugins suggested on thousands of WordPress blogs. And we give you speed alternatives.
83 pp, 362k, 8.5 x 11 inches, PDF download.
… having read your book and browsed your site I had installed pretty much every plugin that you warn against using! I’ve spent I don’t know how much money buying plugins … I’ve reassessed the plugin functionality I actually need and struck a line through most that I had installed; the rest I think I can replicate with the lighter versions you’ve educated me about. … I am hugely grateful for the help and advice on your site and in your book: it’s great to know that good things are possible with WordPress on shared hosting!
Steve built speed websites before – coding by hand. A tedious method but fast loading even on shared, cheap hosting. Creating sub-second loading web pages fascinated Steve. And he developed all sort of tricks and strategies to solve the puzzle of speed. But no one appeared to care. Small mobile screens and wireless connections hadn’t hatched. Cross-device didn’t exist in the web lexicon yet.
Christian, our favorite advisor, persuaded Steve. He said, “Building websites by hand (the old way) is obsolete. The ‘CMS of the Day’ is WordPress.” Steve hated Content Management Systems because they were so bloated and slow. Christian claimed Steve was a Luddite. But, Christian also said something that changed Steve’s life:
“Then make WordPress do what you want.”
A light bulb went on. Steve’s most valued super-power is creativity. Steve thought, “You can do that?” It had the ring of a creative challenge to it.
In 2013, Christian threw down the gauntlet. And Steve picked it up. At that moment, Steve began discovering if WordPress could load in under two seconds or not. Most WordPress sites load in 4-seconds to 8-seconds. But some were much worse, like 20 seconds or more. In fact, the average website load time by the end of 2016 was 8 seconds on a desktop. Nothing improved! Yet, many sites now have 60- to 70-percent mobile traffic. Ouch!
Steve’s goal is the industry-best-practice of under 2 seconds – good enough. 1 second being the ideal. Sub-second being magic.
The market need for speed increases. Mobile has slow connections. Heavy page weight is a detriment to good user experience (UX). Ironically, websites get heavier and heavier each year. Sites that weighed 750k in 2010 now weighed an average of 2.3M in 2017 (and growing). Average web page weight is expected to exceed 3M in late 2017. Apathy is the main reason. You can fight this trend of heavy page weight and improve slow speed. The main enemies of speed today are sloppy branding with heavy images and indiscriminately adding third-party scripts with plugins.
Steve researches WordPress speed techniques and methods. Christian often said, “No one cares about these kinds of speeds. No one’s going to read this stuff.” But Christian read it – and that’s all that mattered to Steve.
In 2017, WordPress crossed another milestone. Now, a bigger chunk than ever of the Internet uses WordPress. The WordPress free plugin repository grew at a rate of 25 percent per year. It now has over 50,000+ plugins. And there are over 1,500+ free, responsive WordPress themes.
Site owners need education. Not how to make nice-looking sites. But how not to abuse and ruin WordPress – and thus the Internet itself. Steve’s mission: save the Internet from the approaching WordPress Apocalypse!
Steve Teare researches experimental speed techniques. Steve’s passion is balancing the perception of speed with color and images. Building for speed avoids website user abuse.
Fast, responsive, branded websites are for businesses who depend on web income.
Today, speed and branding are big concerns for most website owners and web developers. Branding and speed solve your user experience needs. Pain-free mobile sites.
Why bloat happens?
Fear of being perceived as insignificant.
Designer is not using themes properly.
A common mistake is the belief that a good site includes everything.
He’s the author of SiteGround’s free Ebook. “SPEED MATTERS: 21 Expert Tips to an Ultra-Fast WordPress Site.” Hristo’s an expert on WordPress speed optimization. He has a video online from a 2016 WordCamp. But we have found a few ideas in his Ebook that don’t measure up to our experience and testing. Naturally. But most of his speed suggestions are safe and sane.
We recently evaluated a London-based site’s home page for speed opportunities. Load times on Pingdom were: 2.05s, 1.95s, 1.85s for three consecutive readings. And on WebPagetest.org: 2.862s, 2.6s, 3.273s. The site owner Niel’s audience is predominantly on smartphones and tablets. Speed is important to them – and him.
We told Niel:
You are not sharing your server. Fast. But TTFB (time to first byte) is around 1.3s that is an “F” for fail. It’s your worst problem right now. Talk to your host and ask about TTFB specs.
We’ve written about TTFB specifications before in our article:
The Time to First Byte (TTFB) is the time your browser spends waiting on the web server to send back the data.
Niel contacted SiteGround. He asked what was the deal with their bad TTFB. Here’s SiteGround’s response:
“The website is quite fast from my end. It loads for 1.35 seconds from my browser and for 2.25 from GTMetrix.
The TTFB time depends mostly of the type of website used. There is a difference. When you(r) website is a simple HTML site the browser just downloads the HTML code to the browser and the TTFB is very low. You will get an A there, however if you have a PHP application for website like WordPress or Joomla the TTFB is the time needed for the web server to compile the PHP code in index.php file to HTML code so this is why the websites built on top of PHP are slower.
For WordPress for instance when the index.php is compiled all plugins of WordPress are read by the web server as well so this why it is so slow.”
This is the best attempt we’ve seen from SiteGround explaining their lousy TTFB.
But we suspect the information isn’t really true. One potential reason they’re getting long TTFB delays is they use NGINX (EngineX) servers instead of Apache – just like CloudFlare.
We have seen erratic TTFB on SiteGround hosting. There are spikes when average load times are 12 to 26 seconds for pages that normally load in under 1 second. For one site we have under test, this slowdown happened 4 times in the last 30 days on SiteGround. And about the same frequency the month before. The slow times seem to occur every 5 to 6 days like a wave. Everything goes sour those days.
SiteGround can’t give any “scientific” explanation. Voodoo. They just reset the server cache. Then cherry-pick a WebPagetest.org test result that looks good – and report saying, “Look! We fixed it.”
But we can do the exact same thing ourselves. The cache reset has nothing to do with it. It doesn’t fix anything.
Being consistently bad on magnetic drives is better than being occasionally great on SSD drives.
SiteGround is saying they can’t perform well as long as you’re using WordPress. They’re pointing the finger at WordPress. It could be true – but we doubt it. Here’s why: 26.4 percent of the Internet is using WordPress – 500 new WordPress sites are created every day! Surely SiteGround isn’t ignoring this? Do all their WordPress customers see this badness? If so they have a big problem – not WordPress.
SiteGround isn’t being honest about their TTFB problems. Cognitive dissonance? If what they’re saying is true, wouldn’t the speeds be consistently bad instead of erratically bad?
You can find out your TTFB on: ByteCheck for free.
PagePipe is a WordPress site on crappy GoDaddy hosting and it loads in under 1 second. We get a predictable 500ms TTFB from GoDaddy. One of the worst TTFBs in the industry. As long as that “badness” never changes PagePipe loads in under 1 second. (Note: Yes. We host on magnetic GoDaddy drives. This is evidence of what is really possible using speed strategy).
Why doesn’t GoDaddy produce the same “PHP compilation delay” SiteGround is claiming? One difference is the shared GoDaddy server is Apache. PagePipe shares its server with 20 other domains. Niel and others on SiteGround share with none! With Solid-state Disk Drives (SSD) even! Are SiteGround customers paying for fantasy speed?
SiteGround claims the WordPress plugins are causing TTFB delays. They have to be kidding! PagePipe has 39 active plugins – and it’s not slow. That excuse is a smokescreen. A deflection away from the real problem which SiteGround isn’t disclosing. They need to own the problem, be transparent and responsible.
We smell a rat.
“I have been using SiteGround shared mid plan and the TTFB times are horrendous at least half the day and every day. I’m lucky in a sense at this point that my blog is small, theme is fast and it’s quite optimized. Even so, I’m giving strong thought to move to a (semi ) dedicated server in a month or so and not renew with them, even while acknowledging their outstanding customer support.” —author: Howard Milstein
Many of the sites we evaluate for speed testing are using free Cloudflare CDN services. A CDN (content distribution network) is a way to get servers geographically closer to user and thus reduce latency. That’s the goal anyway.
CloudFlare is a US-based website performance company founded in 2009. CloudFlare claims to improve page load times and performance.
In the recent past, we’ve used free CloudFlare CDN services and their plugin to bulletproof our WordPress websites. Testing the Codium Grid theme, we found CloudFlare doesn’t guarantee consistent load speeds. During this project, we saw unpredictable and random page load times from 10 to 25 seconds. That’s unacceptable even if the average time is one second.
We first thought there was traffic congestion on the shared-hosting server. We checked using yougetsignal.com and found only three domains resided on the shared server. One was inactive and the other two had benign, low-traffic content. The server wasn’t our offender.
After plugin testing, it was clear that CloudFlare was the culprit throwing in random delays. We canceled the account and removed the plugin. Then things stabilized. We also got better results in WebPagetest.org. Our cached time improved from 750 milliseconds to a 500 millisecond load. We’re giddy from this discovery.
Christian Nelson, ally and web critic, saw this weird, random, delay phenomenon years ago – but not on CloudFlare. He’s maintained a low opinion of CDN solutions since. He’s right on the money. CDN response times can be unpredictable.
CloudFlare uses a modified version of Nginx – a key Russian-created technology. Nginx (engine-x) is an optimized open-source server software used in the LEMP stack (Linux, Nginx, MySQL, and PHP).
One more thing about CloudFlare CDN.
CloudFlare’s Nginx servers cause failure on time-to-first-byte measurements (TTFB). Usually shown as a red “F” as in failure or flunk using WebPagetest.org. This negative flag generated a brouhaha, and Cloudflare responded with a special blog entry about the topic and why they think it not a real problem. We agree. TTFB isn’t a problem. CloudFlare flakiness is the problem.
CloudFlare’s claim is “Gzip compression of web pages reduces the time it takes a web page to download, but the compression itself has a cost. That cost causes TTFB to be greater even though the complete download is quicker.” But only on nginx servers. Apache servers are just fine.
Nginx waits until compression has started before sending the HTTP headers; when compression is turned off it sends the headers immediately.
Our complaint: Who cares about TTFB when CloudFlare throws a monkey wrench into the running engine and randomly gives 10 second to 20 second page loads? Hiccups aren’t acceptable.
Our experience is Cloudflare CDN is notorious for slowing down your site with 500 and 501 server errors. That’s probably where your TTFB errors are coming from. Cloudflare uses NGINX servers instead of Apache. This causes lazy loading of all gzip compressed assets. Unnecessary delays. TTFB is the only metric Google uses in their SEO ranking algorithms.
Using Cloudflare would explain the reason for your speed fluctuations. We do not recommend them – nor any CDN for that matter. CDNs are band-aids for poorly optimized websites. It’s better to build quality into your site.
Certain falsehoods about web speed are repeated over and over on blogs that should know better. They drive us crazy. Can we get rid of these mythical speed ideas? We doubt it. But we’ll feel better if we inform you of “propaganda” that’s unwittingly passed along.
Aggregator websites getting 1 to 2 million visitors per month is pretty nice – and profitable!
Many agregator sites are somewhat “responsive” for mobile – but frequently don’t have good UX on small screens like an iPhone. It’s very cluttered and confusing. Aggregator sites have about a 70% bounce rate typically. Top aggregator sites are getting as low as 25% bounce rates with 2 million monthly visits.
Strategic monetization attempts forcing users to look at ads. It’s bad UX – but perhaps it pays out for your company. User’s generally have a low tolerance of anything that gets in the way of content. Perceived obstacles are bad.
Most aggregator home-page loads are between 8 and 10 seconds in the USA. Mobile speeds will be twice that. Our goal (performance budget) is a 2-second page-load time (4-seconds for mobile).
“Ads are always the worst code on the Internet, and once you include them you can’t really be accountable for performance any more.” —Matt Mullenweg: August 28, 2015 at 5:45pm
Aggregator sites use many third-party widgets.
There’s esoteric talk and proposals in the “website-performance” community to solve 3rd-party integration problems – but few actually provide real-world solutions. They talk about the web future – but not today’s resources. Third-parties are often apathetic about speed. This is a killer for mobile (and desktops, too).
How to manage and control 3rd-party content is the critical factor for speeding up your website. What this means with present “tools” is using better strategy to decide what third-party provider content can be synchronously loaded, deferred (or lazy loaded) – or disabled on critical pages. And things like not updating user-facing Facebook stats in real time.
Landing pages, product pages, and pages on the “money path” are of most interest.
Most offsite (third-party) assets have mechanisms (alternatives) for better browser behavior. But each has to be examined based on your goals.
Is all of this investigation worth the grief? Common sense says, “Absolutely.” People hate slow-loading pages. Bloat is frustrating and annoying. But there’s also experiments (data) by large companies that prove speed affects profitability.
Speed helps you stay ahead of your competitors by differentiating your mobile UX. Optimization is best when it’s built-in with advance strategy –instead of after-the-build fixes. Measuring the impact of third-party content on a site’s usability is often an afterthought — if it even gets thought about at all.
Studies such as those from Moz demonstrate site speed is a small part of Google ranking factor. Nothing suggests it improves SEO more than 1 percent. We agree that overall page load time is not the SEO killer many make it out to be.
Backlinko’s detailed 2016 investigation of wider ranking factors shows relevance and authority remain the driving forces in terms of organic traffic.
Nevertheless, users demand fast-loading sites, and the potential negative impact of slow speed on conversions is well-proven. With the rise of mobile showing no signs of slowing, the need for speed remains strong.
Google’s in 2010 announced site speed as a ranking factor, but the actual details revealed were vague. Citing previous internal studies, Google confirmed that site speed would be added into the mix of existing ranking signals, but stopped short of discussing how much weight it would actually carry. A number of points were, however, stressed from the outset:
How could we resist a list of select WordPress websites reported as “cool” – as in neat-o or spiffy? They described the the sites as astonishing and perfect examples. Our curiosity got the best of us. We had to know how fast these “cool” websites loaded in browser windows. You can see the article and website thumbnails at: 25 Cool Websites Made with WordPress
T urns out not all of the websites were made with WordPress. Oops! These are noted in the article’s comment section. There were only a few offenses – but demonstrated this wasn’t a well-researched article. Credibility in the toilet!
To make fast measurements of load time (speed), we used a Firefox Add-on. It allows us to get the page load time of any web page. That add-on is app.telemetry Page Speed Monitor. As soon as you access a page, you’ll see the load time in the Firefox browser status bar.
We accessed each featured website’s home page. As expected, we saw appalling long load times. But just how bad were these “cool” websites for poor speed.
How good is good enough?
We’ve written before about the audience expectation for wait time. Here’s a quick summary:
Usability studies established how long people expect “machines” to take. Passing seconds alter human perception. These human expectations have not changed for over 30 years.
Sub-second page loads have the illusion of instant response. This is achievable on the web under excellent and pricey hosting conditions.
A one-second page load, or page change when clicked, yields a seamless flow of thought. This meets an ideal criteria of having the user be “in the flow.” Changes are not noticed thus causing no distractions.
After 10 seconds of waiting, attention begins to wane. This is the point where users will bail out off a page. They may begin another search or hit the back button. At 11 seconds, the “visitor” is usually gone for good. Only the diehard who arrived with an exact purpose – or knows the value of the website content – will hang on – maybe? But at the least, it’s still annoying and frustrating.
We’ve suggested a WordPress standard of a two-second, load-time goal or performance budget. This is for sites using low-cost shared hosting. It’s not perfection but it’s “good enough.” We’ve proven it’s possible.
So how did the sample of 25 “cool” websites measure up?
Eleven sites loaded in under 11 seconds and eight were under 10 seconds. None of the sites loaded in under 2 seconds. The fastest site (Facebook blog) was 3.44 seconds. They were trying to set a good example but still had poor performance.
The rest of the 14 remaining websites loaded anywhere from 12 seconds to 40 seconds. The medium being 15 to 20 seconds. These are horrible load times. Many sites showed spinner indicators. Users then wait and watch the little animated whirling icon. These are throwbacks to Flash animated websites that most everyone hated.
Our conclusion: the “cool” factor had too big of a performance price tag. It rendered a poor user experience – or even better said, “No user experience.”