Overcoming MailChimp signup on Twenty-seventeen theme with no page section widget.

Want to use the MailChimp WP Subscribe form on the default WordPress Twenty-seventeen theme?

Then you have a problem. The Home page is sectional pages in the customizer. You ask, “That’s a problem? How so?” Choosing this customization, sacrifices home-page sidebars – and thus no standard widget areas. Widgets are only allowed on posts. Here’s our journey to find a workaround  solution:

We ran into a problem using WP Subscribe on a test site. There, we used the default WordPress Twenty-seventeen theme. Notice during the test (image above), we got a 404-error message. “The requested resource could not be found.” Why was this happening? The same form worked fine on PagePipe.com. We’ve verified the MailChimp API key and the widget matched. It was Kosher.

The Twenty-seventeen theme has a surprise built-in dilemma. You customize the theme home page with optional front-page sections. These allow parallax scrolling images between sections. Nice. Thank you very much. But Twenty-seventeen theme doesn’t allow sidebar widgets on pages. Only posts allow that. Therein lies the problem [disapproval – Boo!]. Since WP Subscribe is in a widget area, we tried using a workaround to place the signup at top, front, and center.

There are various plugins that can help create a widget area inside a page. We thought we’d be clever and use one of those. Failure!

We tried first a plugin called Widgets on a Page. We disabled all other plugins except “WP Subscribe” and “Widgets on Page” plugins. The same 404 error message still reappeared with another test.

Widgets-on-Page plugin is superseded with Turbo-Widgets plugin. But it doesn’t allow editing of the WP Subscribe settings. Widgets on Page is still maintained and last updated 3 weeks ago and has 70,000+ installs. It is compatible with WP 4.7.3 – which we’re using. We suspect this combination of plugins is corrupting code somewhere. And we mean permanently altered – as in undoable.

To remove variables, we tested this errant plugin combination back on PagePipe.com. The result was the same 404 error message. We removed “Widget on Page” plugin. The results on all sidebar signup forms – that formerly worked fine. Errors galore. Corruption of the plugin database.

On PagePipe.com, because the WP Plugin database was now corrupted. That forced us to reinstalled a recent site backup. That cleared the errors. That was a harsh lesson.

We also investigated AMR Shortcode Any Widget as a workaround to embed a widget. Further testing on PagePipe revealed more. The “AMR shortcode any widget” plugin fails also (unknown error, call etc) when embedding the WP Subscribe plugin widget. But it doesn’t corrupt sidebar widget versions of WP Subscribe. We didn’t have to reinstall backups. No corruption. Whew!

https://wordpress.org/plugins/widget-shortcode/

This plugin also fails but not destructively. We finally ran out of widget embedding options.

Because of these problems, we switched to “YIKES Easy Forms for MailChimp” plugin (freebie). 50,000+ installs, 3.7M download size. You can place its shortcode on the front page of the Twenty-seventeen theme. That’s the secret fix. Now you can place a MailChimp signup on default Twenty-seventeen theme pages. Note: In spite of it’s massive plugin download weight (11.5MB decompressed), it is a lightweight plugin and doesn’t bog down page speed. Much of the weight (8M) is in SVG image files for international flag icons. What?! Silliness.

The good news is with a Autoptimize minification plugin installed, this final signup form only added 36 milliseconds to site drag. This is 20 times faster than other alternatives – like iContact.

 

Popular plugins usually aren’t the best for page speed.

From our experience with WordPress search, we get better results without the search enhancement plugin Relevanssi. It shuts down or bypasses normal search functions. There is no failsafe or fallback when Relevanssi malfunctions.

We tested the Relevanssi plugin free version some time ago. Many reviewers were sold on it. But real-world testing by us didn’t reveal much value from it. It was theoretically better. That doesn’t mean you shouldn’t use it if you want but we see no reason to recommend it to clients.

Relevanssi is available as free and paid versions. It doesn’t appear to slow down a website with any HTTP requests. P3 Profiler plugin (authored by GoDaddy) reports it adds only 19 milliseconds to load time. Big deal. It’s just another benign plugin taking up space.

We’ve never had a circumstance where WordPress search wasn’t sufficient – and even sometimes impressive. We use it all of the time to relocate obscure content on PagePipe. We suspect WordPress “search” has improved over time.

https://premium.wpmudev.org/blog/dont-waste-time-improving-your-wordpress-site-search/

Summary: The WordPress search is much maligned but it’s probably not justified and the importance of a search function is often overstated.

Quote from that posts comments:

“As the developer of Relevanssi, I have to agree with your premise: for most users, the WP default search is good enough, now that it can sort results by relevancy and not just date (that search was awful, and something that had to be replaced in most cases).

I wrote Relevanssi, because I own two sites that are basically information warehouses. When you have 4000 book reviews, you need a good full-text search. But not every site is like that.” September 30, 2014, 2:33 am – Mikko Saari

To Engineer is Human by Henry Petroski is 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+. There are now (Sep. 2016) over 46,000+ free plugins in the repository. It’s difficult to stay on top of that rapid rate of change. It’s staggering – an annual growth rate of over 50 percent.

To make a fast decision, it’s plainly easier to select from the Top100 most popular plugins – and consider that good enough. Even this chart with a recent copyright of 2016 is outdated. It wrongly states there are over 35,000 plugins in the repository (it’s over 46,000). 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.

Jetpack plugin alone weighs almost as much as WordPress in it’s entirety!

Plugin popularity is rarely an indicator of good value. People assume they must be good. It makes for a faster decision. 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.

As an example, WP Smush Image Optimization plugin (500,000+ installs) is an extremely popular plugin. But best case, it only reduces JPEG image file sizes by 10%. That’s insignificant for speed improvement. That’s because it uses lossless optimization. To get the real improvement from lossy compression (up to 70% reduction), you have to buy the premium/paid version. But WP Smush still doesn’t address the biggest issue. That is actual image dimensions. It will attempt to “smush” a monstrously-sized camera image – which of course still remains the same huge dimensions and a slow load.

The most preposterous marketing claim made by WP Smush plugin authors is that it will improve your SEO. Ridiculous!

That is why we recommend using Imsanity free plugin instead. It resizes and does lossy compression to whatever values we set. In our case, we set Imsanity to crop uploaded images to a maximum blog column width (750 pixels) and compress to a quality of 70. It doesn’t compress PNG images by default which we don’t care about in our case.

There are many free, good, lossy image optimization plugins but they are less popular with less than 100k installs. People just don’t test. They assume popular must be the best. To the contrary, it usually means they contribute to site drag and slow page speed.

Is there a speed benefit from costlier SSD hosting versus cheap magnetic servers?

Shared hosting is web hosting in which the service provider serves pages for multiple web sites, each having its own Internet domain name, from a single web server. … Although shared hosting is a less expensive way for businesses to create a web presence, it is usually not sufficient for web sites with high traffic.

SOURCE: What is shared hosting? – Definition from WhatIs.com

Magnetic servers are old mechanical technology using spinning hard drives. Modern Solid State Drives (SSD) have no moving parts. An SSD is a type of mass storage device similar to a hard disk drive (HDD). Hosts claim SSDs are faster because they have faster access times. From our testing, that is theoretical improvement. We’ve never seen any real-world benefit. So paying more for SSD has no apparent advantage over cheaper magnetic technology.

The advantages for the host company are many including reducing cooling expenses and space and technical service time. They benefit. But should you pay more for SSD hosting?

We don’t usually recommend or prefer any hosting service. Because they fluctuate depending upon how well or bad their business is doing. It’s cyclical.

We use the two hosts with the most disrespected and low credibility for quality. Those are BlueHost and GoDaddy. They are the most hated hosts. They’re not a problem for us because of the way we build speed sites.

If you use original optimization as taught on PagePipe, about any host can get good-enough speed.

For clients who have money to burn, we recommend Pressidium hosting. But you can achieve the same speed results applying your brain and creativity – and cheap, shared hosting.

Remember, all hosts fluctuate from good to bad speed at some time. Our advice is don’t throw money at the problem. Build your site using origin optimization instead.

Testing mobile speed

 
ANALYSIS
 
 
Pingdom to frankfurt 3040.0 milliseconds 1.1M page weight 63 requests
 
WPT.org default settings 4087.0 milliseconds 1M page weight 57/62 requests 1.605 TTFB
 
https://tools.pingdom.com/#5a4e81be0ac00000
 
https://www.webpagetest.org/result/190301_B7_f85e21d01d46825585034b0d342aa584/
 
We use unconventional practices with the P3 Plugin Performance Profiler by GoDaddy. This helps us get approximate load times for each plugin and rank them from slowest to fastest.
 
REFERENCE: P3 Plugin Performance Profiler and mobile WordPress speed.
 
 
 
After sorting the extracted data, we see what “nails” stick out. We then focus on hammering back in the worst cases. This is a management by exception technique and application of the Pareto law (the 80/20 rule). 80% of site drag come from 20% of the causes. The biggest chunk of plugin site drag comes from only a few slow inefficient plugins.
 
 
Site drag is globally loading a plugin on every page and post of your site even if the plugin isn’t used. This doesn’t appear in a speed test waterfall. It’s masked inside the HTML load time.
 
The goal is using value-analysis decision-making techniques. We borrow value analysis from industrial manufacturing process. It’s a way to build quality and efficiency into products. In our case, it’s helps us optimize web performance.
 
We highlight the worst problems in RED in the following table. We can then calculate the estimated speed overhead. In this case, it’s 4.5 seconds overhead.
 
Other speed data is from online tests. Scores do NOT matter. Only time in milliseconds count. Scores are not used by search engines to rank your pages.
 
Our performance budget is a 2,000 millisecond load (2 seconds).
 
HOSTING
 
The first problem is plain. The server has a Time to First Byte of 2,124 milliseconds. This information is from the online test at http://bytecheck.com/
 
Server overhead consumed our entire budget!
 
We take the average of six consecutive samples. HTTPS/SSL handshaking delay is a separate problem. That extra delay is an unchangeable 500 milliseconds.
 
It would seem impossible. But we host our store on BlueHost, too. And can get under 2-seconds (barely). (We also hosts our blog on GoDaddy. Yes. A split site trick).
 
What’s the difference? BlueHost’s TTFB fluctuates – but generally it’s around 1 to 1.5 seconds. That means the page must load in under the remaining 500 milliseconds budgeted. We can do that.
 
Additionally, we’re lucky. We aren’t sharing our server with other domains. That’s right, we pay less and get special treatment. Why? We have no clue.
 
You’re sharing with 16 other domains. None of them are high-traffic porn sites. We test this using:
 
 
We have no logical explanation of why your server TTFB is slower. The solutions include:
 
1) Ask your host to move you onto a different server (but not ours!) – and see if it improves. Tell them you’ll have to move if they can’t get you on a faster server with better TTFB. They may say, “Pay us more and will fix it. But some hosts are eager to please. You should try this first.
 
2) Change hosts and migrate the site. That means you’d have two accounts. That increases annual monetary outlay by $70 most likely. Not good. But needed.
 
THEME
 
Changing your theme will make no significant difference in speed. The X-Child Theme loads in 125 milliseconds. If you were to change to a faster theme, it might load in 30 to 50 milliseconds.
 
SLOW PLUGINS
 
25 percent of speed consumption is from two plugins: The two worst offenders are:
 
1) Cornerstone paid page builder (811 milliseconds).
 
Elementor (free version) page builder is faster: about 41 milliseconds. But only when used in the hands of professionals. Novices add unneeded features and slow things down.
 
 
2) Yoast SEO (198 milliseconds).
 
I’m attaching a $10 eBook about Yoast SEO. No charge. Please review it.
 
We do NOT think Yoast SEO plugin makes any difference in page ranking. Nor do any other SEO plugin. The plugin indicates if your site is Google compliant. That has no guarantees or promises. Irrelevant activity. There’s no documentation establishing these plugins improve page ranking more than alternatives. You’d get better improvement for SEO by improving site content or user experience.
 
We also recommend reading this plugin article:
 
Faster and free alternatives to popular OptinMonster or SumoMe WordPress plugins.
 
 
RESULTS
 
OTHER SPEED SUGGESTIONS
 
You’re loading a Vimeo video on your homepage. We recommend lazy loading it with a plugin:
 
REFERENCE: Lazy load images and video for mobile speed.
 
We recommend changing to Elementor. And using a theme like GeneratePress with fast-loading mobile system fonts.
 
REFERENCE: WordPress dream theme for mobile speed: GeneratePress 2.0.
 
 
You can also cut: jQuery overhead, Font Awesome site drag, and Emojis.
 
There are faster ways to load Google Analytics. We don’t recommend heavy W3 Total Cache. We use other methods using lightweight plugin substitutes. Those load in about 3 milliseconds equal results.
 
I’m not testing your most traffic pages until you decide what you want about the server slowness. My recommendation is migrating the site to a new host if the present host can’t provide you a faster server.
 
I will do one site migration and speed tweaking as part of the $500 “Plugin Surgery” fee. I’d like to see your site loading in under 2 seconds.
 
Let me know what you’d like based on these recommendations.
 
Number one is the server. Any other work would be futile until that’s resolved.
 
Steve Teare
 
performance engineer
 
PagePipe.com

 

What’s the truth about calculating plugin retention?

Calculating retention rate is a indicator of usefulness – rather than popularity (active installs). To determine ballpark retention rate: Take “active installation” from the plugin page. Let’s say it’s: 200,000. Then click on “advanced view.” And scroll down. Get the “All-time downloads:” Let’s use: 2,560,081. Do the math division. The result is 7.8 percent plugin retention rate. Less that 8 percent of the people who tried the plugin kept it. Not great. Rule of Thumb: Below 10 percent is low retention. 10 to 25 is OK. 25 to 30 is good, and 50 percent is excellent. – Source

Who’s Dave Baker?

Dave Baker

Dave Baker currently works for Envato (ThemeForest). Previous to that he was a WordPress theme and plugin author under the brand “dtbaker”.

He has no affiliation with Elementor besides having made a few themes and plugins that integrate with the Elementor page builder. He’s page builder agnostic. But finds himself using Elementor quite a bit. Its free version is pretty powerful compared to other options – and his customers love free!

At work, he uses Elementor to build pages such as:

Dave is also the programmer behind this plugin: https://wordpress.org/plugins/envato-elements/

This gives him direct access to download statistics. He knows that a download graph jumps as soon as he releases an update. Daily download counts are reset at about 10AM AEST (Australian Eastern Standard Time).  So that’s when the chart updates.

Other details about Dave Baker:

A discussion about erroneous plugin retention calculations between Steve Teare (PagePipe) and Dave Baker (Envato – and plugin author):

Dave: I was just having a read of https://pagepipe.com/how-elementor-page-builder-affects-mobile-page-speed/

I wanted to quickly correct you on something about WordPress stats.

The “Download Count” includes everybody who:

  • Clicks the download button on the wordpress.org page (even those who don’t install the zip).
  • Installs the plugin via the WordPress update panel
  • Updates the plugin via WordPress – this is the important one.

If you have 100 users and they all update the plugin, the download count will jump to 200, but you will still only have 100 active installs.

Retention rates are impossible to determine by WordPress stats, because download numbers include every time someone updates the plugin.

You can easily see this on less popular plugin such as: https://wordpress.org/plugins/envato-elements/advanced/
The “Downloads per day” chart spikes every time there is a plugin update released, because that is all the existing customers downloading the plugin update again without a growth in active installs.

Steve: Thanks for sharing your thoughts about retention calculation.

I’m sorry if I’ve misrepresented Download Count. Where did you get this information about the definition of an “official and unofficial download”?

Dave:  As for how I know about this download counter, I asked Dion Hulse, [WordPress Core Contributor – https://profiles.wordpress.org/dd32] about it when we caught up at WordCamp Brisbane.

I really wanted to see if we could track zip downloads vs installations vs updates separately, as the current numbers are a mess. I wanted to see if he could help nudge that particular feature forward in the WordPress core, as he is a major core contributor.

But unfortunately it’s not going to happen – and everything will continue to hit the same “download” endpoint. Updates / downloads and install numbers will all be jumbled together for the foreseeable future. The only way we can track this metric is using 3rd party analytics, or the (quite unreliable – that’s another story all together!) active install count on WP.org.

If you really want to test it yourself, hit the “Download ZIP” button on a plugin a few times, and then refresh the stats page. The numbers update instantly. You can also install an older version of an unpopular plugin, then update it in WordPress, and watch the download count increase. Repeat as necessary.

So tl;dr, it’s impossible to track retention, even for people like me who create the plugins and really want to know what retention is.

Steve: So I want to clarify something.

If an automatic update is done by a host provider, does that increase the download counter? Or is it actual downloads through the browser that increment the counter? Or in other words, I download and then upload the plugin zip file via the WordPress dashboard.

Can I find a lonely plugin and start pumping up the numbers in manipulation?

If updates count as downloads, that’s really lame and flawed. What good are these numbers for anything?

I’m speechless.

For example, GoDaddy automatically updates millions of WordPress plugins with new releases. So do many MANAGED WordPress hosts like Kinsta and Pressidium (smaller number of users) etc. Are these included in the count?

For example, GoDaddy automatically installs “Limit Login Attempts Reloaded” plugin. And Akismet is loaded on every stinking WordPress install. Those count as downloads?

So can I game the system as a plugin author and make it look like my plugin is hugely popular?

Just trying to wrap my head around this potential weirdness. Also it seems like plugins who do frequent and rapid updates like Elementor would run up the tab – and possibly be an indicator of churning. Frequent updates are indicators of unpredictable fragility more than strength.

Now there’s one company deliberately doing regular systematic updates even when unneeded. That’s Yoast SEO plugin. It’s part of their marketing plan. This triggers ad presentation in the WordPress dashboard. Those have to be dismissed. Anyway, they are definitely gaming – and it works.

Aren’t you effectively saying the number of download counts – reported immediately – double every single time a release is made?

Is there any residual value in “active installs divided by all time downloads” indicating churning, quality, or management practices? Or is it completely useless drivel?

My gut says it’s telling something – even if it’s the shame of WordPress reporting policy.

Dave: Yep. WordPress core will download the plugin update or installation from the same URL (example: https://downloads.wordpress.org/plugin/envato-elements.0.1.2.zip )

This is the identical URL you click to get the ZIP from the WP.org page: https://wordpress.org/plugins/envato-elements/

So yes you’re correct, clicking “Download” on wp.org increases the count, the same way as installing through WordPress, the same as updating through WordPress.

Yes. Managed hosted, managewp, automatic installs, if the underlying system tells WordPress to “fetch an update” or “install this plugin” then that download count will increase.

Numbers do double on updates, that’s why the chart is “Downloads per day” and not “Total downloads”.

You can get an indicator of plugin growth by looking at the top of the “download” spikes. This is a great indicator to how many people are actively updating their plugins. If the top of those spikes are going up, it means more people are engaging with the product over time.

You could in theory “game” the system by increasing your download count slowly over time, but no need to game it if you can just release a plugin update and double your download count the next day.

Yoast is a good example, 143,129,874 downloads and 5,000,000 active installs.

That 5 million is only 3% of total downloads.

Also considering there are only about 75,000,000 WordPress sites running WordPress, that download count is a clear indication of all time installs, updates, and zip downloads.

We’ve found no value in this number for our own product and in competitor analytics. It’s just a nice metric to compare popularity between plugins.

Basically, a higher daily number means it’s a more popular plugin. Automated tools such as ManageWP do increase this number, so take it with a grain of salt for sure.

Steve: Thanks for the plugin tutorial.

Reduce SSL speed overhead for Easy Digital Downloads plugin and PayPal transactions.

Performance Offloading delivers content, features, or functions. But from different hosts, domains, or web services. This improves speed.

We saw performance offloading by using two domains with a French client. It was a brilliant accident. He hosted his lifestyle WordPress blog on one domain. And his super-heavy, subscriber, real-time, location map on another subdomain. He styled the two sites the same and used different themes to manage specialty functions. Users were unaware of the theme switch because the domain names were similar. And the user interface and navigation were identical.

It was seamless and amazing.

He quarantined all his poisonous Google Map requests on one domain. Google Map bits-and-pieces load on every page and post – a bad undocumented effect we call site drag. This nasty effect wasn’t happening on the blog posts and pages. They had speed purity. Untainted.

This ploy kept global loading (site drag) from slowing down all his blog posts. He didn’t discern the speed benefit – until we brought it to his attention. The blog posts were his visitor entry pages. Not the map section. The map got limited member traffic. Perfect.

Did this division hurt his SEO? Not from what we could determine. He received over 100,000 visits per month to his blog.

USING THE “FRENCH CONNECTION” TO OFFLOAD Secure Sockets Layer handshaking – SSL

SSL offloading keeps encryption and decryption on another website. It’s moved to a separate location for the task – like for an ecommerce store. Performance efficiency of the main site blog increases. We distribute the workload between two or more websites on the same server.

So what? Why would anyone care about this speed trick?

By offloading SSL, PagePipe achieved two goals:

PagePipe Goal #1: Reduce backup plugin overhead.

We wanted to get the heavy self-hosted PDFs off our media library. And stored somewhere else for free.

Our downloadable PDFs slowed down backups and consumed server resources. Offloading meant producing two site backups. The media library and our store didn’t need updating as often as blog content. Splitting backups improved server-resource efficiency. Our PDF inventory was pretty static compared to daily blog changes. This efficiency idea produces optimal resource usage, maximizes throughput, and minimizes response time.

Automatic site backups cause server-resource consumption. During these period of high server activity, your shared server will slow down. The more you need to backup, the longer you’ll slow down the site. Keeping our media library light helps speed up the backup process. Our blog is set to backup weekly and our store backs up fortnightly.

Is this a huge speed advantage? It depends upon how bloated your media library is. We’ve encounter some huge 45-Gigabyte media libraries. Those can’t be backed up with a free plugin and stored on a free 2-Gigabyte Dropbox account. This means extra cost purchasing backup, storage and restoring services for your website. Keeping your media library lean reduces your site’s annual overhead.

Merely backing up on your host server is not recommended. If the server gets hacked, you’re out of luck. Keep a backup offline or in the cloud – or both. And be sure you can restore. Many site owners don’t test this.

OFFSITE LINK: https://kinsta.com/blog/wordpress-backup-plugins/

Our Goal #2: Secure PayPal connections per PayPal’s specifications.

Our PagePipe ecommerce pages for selling ebooks needed SSL compliance to communicate between PayPal and Easy Digital Downloads (EDD) plugin. We were resisting PayPal dictates. Results: We got random transaction misfires.

By not complying, sales were still booked by PayPal and Easy Digital Downloads plugin. (We got our money!) But some buyers weren’t getting their confirmation EDD email with download links embedded. We also didn’t get email verification of payment received generated by the EDD plugin. Some buyers were left hanging out in the breeze with no product fulfillment. Terrible user experience and resultant distrust if not sheer panic of a scam. UX dud.

“Merchants and partners use HTTPS to securely connect with PayPal servers. We use the Transport Layer Security (TLS) protocol to encrypt these communications. To ensure the security of our systems and adhere to industry best practices, PayPal is updating its services to require TLS 1.2 for all HTTPS connections. At this time, PayPal will also require HTTP/1.1 for all connections.

This change is complete as of June 28, 2018.”

Reference

Oddity. It was in June our disgruntled buyers started writing saying, “Where’s the #$%@& stuff I paid for, you *&(%^!?.” An embarrassing coincidence of ignorance and techno bliss caused us loss of credibility. Buyer’s remorse.

PagePipe forced to use SSL/HTTPS?! Horrors! Instant revulsion. Why? The disgusting thought of adding 400 to 500 milliseconds SSL handshaking to normal slow server delays. That meant doubling or tripling our server losses. An excellent TTFB (time to first byte) is 300 milliseconds on a shared host. That’s a best-case scenario.

OFFSITE LINK: https://hackernoon.com/why-migrating-your-site-to-https-may-be-a-bad-idea-9d69d8c27fca

On shared web hosting, the TTFB is 500 to 800 milliseconds most often.  And in bad scenarios 1.0 to 1.5 seconds long. With a 1.5-second TTFB, plus an extra 500-millisecond SSL handshake, we’d consume our entire 2-second performance budget in one greedy gulp.

A full TLS handshake involves 2 round trips between the client and the server. Because of the difference between latency and bandwidth, a faster internet connection doesn’t make these round trips any faster. This handshake will typically take between 250 milliseconds to half a second, but it can take longer.
SOURCE

[fade-in fortissimo weeping sounds here]

We can do minor miracles and build speed sites loading in under 2 seconds even with a cruddy 1.5 second TTFB. That’s right. Compromise. Cram everything in the 500-millisecond remaining. But if you add SSL handshaking on top of that then we’re doomed. Thwarted.

So we setup a separate website for speed to handle the SSL delay (also know as load sharing).

That’s the SSL speed travesty. Loss of speed.

What does it mean for your site? Well, loading of WordPress core, plus the theme and any plugins. Or images. Or any other doodad widget like email signup, YouTube video, podcast, or ads are deal killers. The results? A performance optimization nightmare!

We hate Google and PayPal SSL/HTTPS mandates. Read more wicked Google SSL *conspiracy theory* here.

We’re hosting on cheap, GoDaddy shared, mechanical servers to prove the impossible. That’s right – a website page-load time in under 2 seconds with our open-source plugin methods. No CDN. Using a stock Twenty-seventeen default theme with 70-plus free plugins activated. Extreme? Sure. But not for the speed obsessed. We’re walking the talk. Trying anyway.

Does GoDaddy SSL support TLS 1.2 and HTTP/1.1? We had no idea.

You can use Qualys SSL Labs vulnerability tester to check which TLS version your host is using: https://www.ssllabs.com/ssltest/

We tested the host GoDaddy’s homepage (go ahead test your own site if SSL certification is activated.) It’s takes about 1 minute to complete.

Our web hosting services by GoDaddy are already supporting TLS 1.2 connections. Great! How much does that cost to activate? The cheapest “Standard DV SSL” is:

$69.99 U.S. Annual Repetitive Price. Per domain.

It wasn’t a joke. Every stinking year: $69.99. Serious business. Opportunists! Gougers! Millions of domains. But it seems there’s a GoDaddy SSL sale for signup enticement – about $50 US annually.

We don’t want to move our blog. So let’s do “The French Connection” trick – but without any crime. We’ll offload our store pages to another cheap hosting but with free SSL.  Are we that desperate? No. But … we’re determined to practice what we preach. Workaround these dirt-bag web weasels.

Where does one go for cheap hosting with free SSL? Take a dart and throw it. Every host out there has poor or angry revues. Don’t trust reviews. All hosting cycles from good to bad and back again for many reasons.

So build your site rugged and tolerant of variations in server speed. Test your new host. Get a refund and leave it they aren’t good enough.

Our criteria:

  • Cheap hosting.
  • Moderate 500 to 1000 millisecond TTFB (magnetic or SSD doesn’t matter).
  • Free SSL.
  • Provide Cpanel.
  • Easy WordPress installation with Installatron or equal.
  • Enough storage space for our 333-megabyte site. (Yeah. Small, tight and clean).
  • Good enough uptime.
  • Register a store domain name.
  • 30-day money-back guarantee.

We decided to give Asura Hosting a try. Why not? A few people hated them.  Mean, nasty, vindictive and vulgar people. Always a good sign!

We’ll be dumb and trust our instincts and move forward into the unknown. We can always pull the store and move.

They had the right specs. TTFB with SSL handshaking for their homepage is 848 milliseconds tested using ByteCheck.com. That leaves us a whole second to load store pages – plus 152 milliseconds for dessert. And their site design didn’t look abandoned in the 90s like some other hosts.

Asura Hosting

Domain registration: $9.99 (recurring discount 1 year)
Starter – pagepipe-secure-store.com (05/10/2018 – 04/10/2019) $12.00 USD
TOTAL: $19.99 with free SSL.

Twenty bucks versus Google’s $70. Savings: $50 per year.

So about Asura: their default PHP version is 7.0. We dialed that up to version 7.2 in Cpanel. That’s a 15-percent boost in speed for WordPress, theme, and plugins.

But we never could login to our Asura WordPress backend dashboard. We became instant haters!

So we dumped that host. In the name of time savings, we went ahead with a $48.74 on-sale GoDaddy-sponsored SSL annual license fee.

Remember, we’re not doing this silly SSL trick to beef up security. PayPal is secure enough. We’re complying with PayPal’s dictates for reliable product fulfillment. PayPal broke our Easy Digital Downloads plugin and we’re fixing it. We work hard salvaging every millisecond of speed we can.

Do we feel ripped off by GoDaddy? Yes. Especially when after purchase, we found out we didn’t need to buy their pricey certificate. We could have used a free one.They didn’t mention that alternative, of course. “Too soon we grow old. Too late we grow smart.” We want to install “Let’s Encrypt” free SSL certificate.

Was there any recourse – like a refund? Did GoDaddy bury that refund information? Yeah. They don’t make it obvious.

Here’s the GoDaddy service-chat answer: 30-day refund from date of purchase. OK. We got our money back. But not without consequence.

When GoDaddy pulled the now-cancelled SSL certification, it nuked all the image links on the new store site. Every image was broken.

So we reverted to our backup and reinstalled WordPress and the store.

Let’s-Encrypt free certification expires every 90 days. You then must renew. But we’re determined to reduce website overhead. Here’s how we did that installation:

Step One

Go to ZeroSSL
https://zerossl.com/
Click on “Online Tools”
Start the “FREE SSL Certificate Wizard”.

Follow the instructions, and you will end up with the following files:
a) a domain key
b) a domain CSR (certificate signing request)
c) an account key
d) the domain certificate

Copy each of those into text files (not a Word Processor. It adds junk).

Step Two

Go to cPanel on GoDaddy.
Scroll down to the Security section
Click on SSL/TLS.
Under “Install and Manage SSL for your site (HTTPS)”, click on “Manage SSL sites”.
There you will see a simple form where you provide (copy-and-paste) the following information:
a) the domain
b) the certificate
c) the private key
d) the certificate authority bundle.

Items b, c, and d are all things received from ZeroSSL. Duh!

Included as parts of the certificate are the beginning and ending markers, e.g. “—–BEGIN CERTIFICATE—–” and “—–END CERTIFICATE—–“. If you don’t include these, you will get an error saying the certificate is not valid.

Also, the certificate you get from ZeroSSL has two parts. The actual certificate and the Certificate Authority Bundle (CABUNDLE). These are each marked with beginning and ending tags. Place them into two separate boxes on the form. Once you have filled in the form, and you have an indication that the content is correct, click on “Install Certificate”, and you’re finished.

Install Easy HTTPS (SSL) Redirection plugin if needed. We didn’t.
https://wordpress.org/plugins/https-redirection/

ONLY USE THIS PLUGIN IF YOU HAVE INSTALLED SSL CERTIFICATE ON YOUR SITE AND HTTPS IS WORKING CORRECTLY

NOTE

You’ll be asked to create two files with encrypted file names with encrypted content. Put these sub-directories on your hosting account root directory. The path will look like this: /public_html/.well-known/acme-challenge/ These are the files proving you have website ownership. When requesting the certificate at ZeroSSL, specify both yourdomain.com as well as www.yourdomain.com as a subdomain.

We used Cpanel file editor to created the nested folders and write the two single-line files.

The SSL installation wasn’t hard but it was somewhat confusing at times. Now we’ve done it once, it’s a piece of cake to repeat.

TUTORIAL VIDEO LINK

https://youtu.be/9oKIOEvLIZo

So here are the speed test results:

International Load Times, No CDN

PagePipe Blog homepage
398.2k page weight, 17 requests

Pingdom to San Francisco
590 millisecond
load time

Pingdom to Frankfurt
1.60 second
load time

Pingdom to London

1.93 second load time

Pingdom to Sao Paulo, Brazil
2.06 second load time

Pingdom to Tokyo
2.07 second load time

Pingdom to Sydney
2.28 second load time

PagePipe Store homepage – No CDN
193.9k page weight, 31 requests

Pingdom to San Francisco
730 millisecond
load time

Pingdom to Frankfurt
1.88 second
load time

Pingdom to London

1.81 second load time

Pingdom to Sao Paulo, Brazil
2.29 second load time

Pingdom to Tokyo
2.33 second load time

Pingdom to Sydney
2.98 second load time

Does Easy Digital Downloads and PayPal work with SSL only activated on the store domain?

Yes. Everything is working great. Cha-ching! Wanna buy an ebook?


NOTE

After migrating our store pages, https://pagepipe-ebooks.com/ didn’t show a green padlock in Firefox on the homepage. But it did for all other store pages. We figured it was a mixed-content error as defined at this link:

REFERENCE: https://developers.google.com/web/fundamentals/security/prevent-mixed-content/what-is-mixed-content

The homepage flashed a green padlock and then after page load switched the lock icon with a yellow triangle with an exclamation mark.

We tried two plugins first. We installed called “SSL Insecure Content Fixer.” and “Easy HTTPS (SSL) Redirection” Neither fixed anything.

The Solution

We identified “mixed content” using the Firefox addon or Chrome extension called Web Developer. This extension adds various web developer tools to the browser.

How to use Web Developer toolbar.
Click the web developer icon in your tool bar. Click the Images tab. Then click Display image paths. A popup shows the address of each image. All images should show “https” addresses. If you have any “http” addresses, these are causing the error. For the PagePipe store, we needed to remove image links back to the media library on vanilla PagePipe blog. That fixed it.

There is more to this story. After the 90-day period with Let’s Encrypt, we deliberately let the certificate expire. We wanted to see how much of a hassle this would be. It was a nightmare. In all fairness, Let’s Encrypt’s “expiry bot” did send a couple of warning emails, one 30-days before expiration and another 1-week later. This means the certificate really is transparent for 60-days and then you better start worrying about renewal.

READ the rest of the horror story now.