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!

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.