Why Google AMP is not the ultimate solution for mobile WordPress speed.

You would not need AMP tags for a normal website. You can have a very fast website without using AMP separate markup. – REFERENCE

Google’s ambitious AMP project (October 2015) speeds up the entire mobile web. Right!? It’s a WordPress speed miracle – wait! No it’s not. It’s another Google sham. It promises better SEO results in exchange for people surrendering control and information. Google’s great boon for mobile publishing fizzled.

Three examples of Google AMP hijacking URLs and valuable screen space:


 


 

Three examples of Google AMP hijacking URLs and valuable screen space.

Google, to speed up AMP, stores publisher’s pages and serves from Google. When a reader clicks an AMP link, the address bar displays www.google.com instead of the publisher’s Web address. Oops? Where’d that site branding go?

Google says articles served from its Internet network is four times faster. That’s right. But developers disagree. Engineering or “designing in” origin 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.

What do these wonderful plugins claim?

AMP Active installs: 500,000+
zip file size: 715k

 

AMP for WP – Accelerated Mobile Pages
zip file size: 7.5M

The Big Promise: AMP makes your website faster for mobile visitors. SEO pros claim Google prioritizes AMPs in search results. Feb. 24, 2016: Google integrated AMP listings into mobile search results. Big deal.

Really? But when we search on the phrase:

“Why Google AMP sucks”

We’re inundated with blog posts by developers. They say unexpected derogatory words about how AMP doesn’t help. They say it’s all a ploy by Google. These aren’t crackpots chiming in here. There are tech heavyweights who think AMP is bad for the free web. Why?

How to Setup Google AMP on WordPress Site (Using AMP Plugin) When you read the above post the propaganda sounds wonderful. Google AMP is the magic silver bullet curing all mobile speed problems. And there are two WordPress plugins helpers to get you set up. One authored and endorsed by Automattic, the  founders and owners of WordPress. What an amazing endorsement! (Question: What is Automattic doing in bed with Google?)

AMP hijacks the real URL of the page and provides no UI control to get back to the canonical URL. Consumers, publishers, sites and users are asking Google to give an opt out feature. AMP often loads broken links, takes longer to view, or may not format properly

When a user searches for an article on Google and clicks on an AMP link, it never leaves Google.com. Even if the AMP link is an external entity. Google rehosts pages from popular search destinations. But they truncate it and reformat it. It’s supposed to be helpful because it lets complex pages load faster, but it’s a pain because it frequently doesn’t format properly or they cut it off in an inconvenient place. You’ve got to waste time getting to the original page.

There’s no way to turn AMP off. If they’ve got an AMP mirror for a domain, they’ll give you those results instead of the actual page every time.

Smaller publishers have more to lose if they use AMP. For many, they think Google owns the small-guys story.

John Gruber at Daring Fireball says the following:

The Problem With AMP

The lock-in aspect makes no sense to me. Why would I want to cede control over my pages to Google? AMP pages do load fast, but if publishers want their web pages to load fast, they can just engineer them to load fast. Best answers I got were that it wasn’t really strategic — publishers are going with AMP just because their SEO people are telling them to, because Google features AMP pages in search results. I suppose that is a strategy, but ceding control over your content to Google isn’t a good one in the long term.

Wikipedia negative quotes about AMP (there aren’t any positive ones):

Some tech media outlets, including The Register have criticized AMP:

I feel this needs to be said very clearly: Google’s AMP is bad – bad in a potentially web-destroying way. Google AMP is bad news for how the web is built, it’s bad news for publishers of credible online content, and it’s bad news for consumers of that content. Google AMP is only good for one party: Google. Google, and possibly, purveyors of fake news… Pinboard founder Maciej Cegłowski already recreated the Google AMP demo page without the Google AMP JavaScript and, unsurprisingly, it’s faster than Google’s version… Anybody can cram an illegitimate idea into a web page and – so long as it’s encoded as AMP content – it’ll look like it’s from a legit new organization endorsed by Google.

Chris Coyier, cofounder of CodePen, writes that AMP would be better if it “was never used as search ranking factor (or anything that could be interpreted as such) by anybody.”

At AMP Conference, Gina Trapani described some aspects of AMP as being “scary to me.”

John Gruber (again) writes:

I’m on the record as being strongly opposed to AMP simply on the grounds of publication independence. I’d stand by that even if the implementation were great. But the implementation is not great — it’s terrible. Yes, AMP pages load fast, but you don’t need AMP for fast-loading web pages. […] It’s a deliberate effort by Google to break the open web.

Why is PagePipe against Google AMP?

[perfectpullquote align=”right” cite=”” link=”” color=”” class=”” size=””]Here’s a good offsite article about how Google AMP failed for Kinsta by actually impacting their SEO by a negative 59 percent drop in leads. Read it in a new tab.[/perfectpullquote]
Speed is a strategy not a band-aid. You build site and page quality in – not sprinkle it on afterwards. AMP serves Google’s purposes – not ordinary users. We’re surprised an AMP content blocker hasn’t shown up by now. Improving the web is a better answer than donating it to Google. AMP is for apathetic site creators. We can fix the problem without handing everything over to Google.


LONG but GOOD EXCERPT from:
PixelEnvy Written by Nick Heer.
“Given the assumption that any additional bandwidth offered to web developers will immediately be consumed, there seems to be just one possible solution, which is to reduce the amount of bytes that are transmitted. For some bizarre reason, this hasn’t happened on the main web, because it somehow makes more sense to create an exact copy of every page on their site that is expressly designed for speed. Welcome back, WAP — except, for some reason, this mobile-centric copy is entirely dependent on yet more bytes. This is the dumbfoundingly dumb premise of AMP.

Launched in February 2016, AMP is a collection of standard HTML elements and AMP-specific elements on a special ostensibly-lightweight page that needs an 80 kilobyte JavaScript file to load correctly. Let me explain: HTML5 allows custom elements like AMP’s <amp-img>, but will render them as <span> elements without any additional direction — provided, in AMP’s case, by its mandatory JavaScript file. This large script is also required by the AMP spec to be hotlinked from cdn.amp-project.org, which is a Google-owned domain. That makes an AMP website dependent on Google to display its basic markup, which is super weird for a platform as open as the web.

That belies the reason AMP has taken off. It isn’t necessarily because AMP pages are better for users, though that’s absolutely a consideration, but because Google wants it to be popular. When you search Google for anything remotely related to current events, you’ll see only AMP pages in the news carousel that sits above typical search results. You’ll also see AMP links crowding the first results page, too. Google has openly admitted that they promote AMP pages in their results and that the carousel is restricted to only AMP links on their mobile results page. They insist that this is because AMP pages are faster and, therefore, better for users, but that’s not a complete explanation for three reasons: AMP pages aren’t inherently faster than non-AMP pages, high-performing non-AMP pages are not mixed with AMP versions, and Google has a conflict of interest in promoting the format.

It seems ridiculous to argue that AMP pages aren’t actually faster than their plain HTML counterparts because it’s so easy to see these pages are actually very fast. And there’s a good reason for that. It isn’t that there’s some sort of special sauce that is being done with the AMP format, or some brilliant piece of programmatic rearchitecting. No, it’s just because AMP restricts the kinds of elements that can be used on a page and severely limits the scripts that can be used. That means that webpages can’t be littered with arbitrary and numerous tracking and advertiser scripts, and that, of course, leads to a dramatically faster page. A series of experiments by Tim Kadlec showed the effect of these limitations:

AMP’s biggest advantage isn’t the library — you can beat that on your own. It isn’t the AMP cache — you can get many of those optimizations through a good build script, and all of them through a decent CDN provider. That’s not to say there aren’t some really smart things happening in the AMP JS library or the cache — there are. It’s just not what makes the biggest difference from a performance perspective.

AMP’s biggest advantage is the restrictions it draws on how much stuff you can cram into a single page.

AMP’s restrictions mean less stuff. It’s a concession publishers are willing to make in exchange for the enhanced distribution Google provides, but that they hesitate to make for their canonical versions.

So: if you have a reasonably fast host and don’t litter your page with scripts, you, too, can have AMP-like results without creating a copy of your site dependent on Google and their slow crawl to gain control over the infrastructure of the web. But you can’t get into Google’s special promoted slots for AMP websites for reasons that are almost certainly driven by self-interest.”

REFERENCE


Below are 8 other offsite links worth checking out:

https://tech.slashdot.org/story/17/01/18/1455259/the-problem-with-google-amp


https://www.reddit.com/r/bigseo/comments/6751ne/google_amp_sucks/


https://daringfireball.net/linked/2017/05/20/gilbertson-amp


https://productforums.google.com/forum/#!topic/news/ixPneB4vpGk


Google AMP Is Not a Good Thing
https://news.ycombinator.com/item?id=13465467


https://www.theregister.co.uk/2017/05/19/open_source_insider_google_amp_bad_bad_bad/


http://www.osnews.com/story/29823/_Kill_Google_AMP_before_it_kills_the_web_


link: I decided to disable AMP on my site >


link : https://www.socpub.com/articles/chris-graham-why-google-amp-threat-open-web-15847


Google AMP in speed tests adds 406 milliseconds global loading to a website.

The AMP pages of my site handled by AMP For WP plugin are exceedingly slow, even though the normal version of the website is fast.

James McBride


 

The AMP version of my website is loading very slow. I checked it with the Google Speed Insights and it says that the server response time is 3 – 4 seconds for the AMP Pages. For the Desktop version of the site, the server response time is 0.3 seconds, so it’s not a hosting problem.

Cristian Florea

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.

Remove WordPress child themes for mobile speed.

WordPress released core version 4.7 in early December 2016. The default Twenty Seventeen theme included a new Customizer CSS editor. The new editor allows the removal of child themes and related plugins. This helps your site load a little faster – every little bit counts.

Before then, using child themes added custom code to WordPress themes. You edited CSS in a child theme with the WordPress file editor. It protected custom code from being overwritten by theme updates. Without a child theme, updating caused loss of code changes.

Since WordPress 4.7, the option to add custom CSS is in the WordPress Customizer. You can then remove child themes. But you can’t edit PHP or JavaScript files – only CSS.

The custom CSS editor is in Appearance > Customize. Then select the “Additional CSS” option from the Customizer menu. That opens up a live CSS editor — no refreshing. Preview your changes immediately as you type. The live preview feature speeds up web work. There’s no waiting for page refreshes to view each change.

The “Additional CSS” menu keeps the edits safe in the confines of the Customizer. Your changes aren’t seen by users until you press Save and Publish. You can only edit CSS (not PHP or JS).

Child themes allow JS and PHP modification. So this doesn’t mean the extinction of child themes. But for most, it’s an opportunity to squeek out a little more speed. We do extreme performance optimization. We favor using the Customizer over a child theme.

“Additional CSS” is inlined before the closing head tag. This means no extra HTTP requests to fetch the custom CSS. Inlining CSS into HTML header removes CSS render-blocking. It also eliminates an extra HTTP request — both great things for speed. “Additional CSS” also does code syntax highlighting and error checking. Nice.

A child theme requires an extra HTTP request – unless combining by concatenation. Read more about minification plugins.

“Additional CSS” isn’t cached. It’s downloaded, processed, and rendered by the browser with every page load. This sounds inefficient. But for small amounts of CSS, it’s negligible speed difference. A few dozen – or even a hundred lines – of CSS loads fast inlined. Even Google recommends inlining CSS. No need calling an external style sheet when CSS code is small.

“If the external CSS resources are small, you can insert those directly into the HTML document, which is called inlining. Inlining small CSS in this way allows the browser to proceed with rendering the page.” – Google

From our past experiments with hand-coded sites, we agree with Google. This technique produces the fastest loading pages. Eliminating a child theme – by inlining custom CSS – produces a small boost in mobile site performance.

So, theme updates won’t wash away custom CSS – but that’s true only up to a point. If you change your theme (rather than just updating the theme), all the code added in the “Additional CSS” area disappears. Then it’ll all be gone.

Tom Usborne, the developer at GeneratePress, has a free plugin called “Simple CSS.” It’s a nice CSS editor – complete with code syntax highlighting to help you. It keeps all additional CSS safe from any theme updates and replacements. It works with all themes but Simple CSS is included as a standard feature with GeneratePress premium theme. With this plugin, you can also apply CSS only to one specific page. Navigate to your page or post in the Dashboard and look for the “Simple CSS” metabox.

NOTE: Don’t confuse this GeneratePress’ plugin offering with Simple Custom CSS plugin: 300,000+ active installs, 204k zip file, all-time downloads: 1,336,559, retention rate: 22 percent (average).

★★★★★
Simple CSS

And it also opens up a new area in the Customizer where you can view your CSS changes live. This code saved by the plugin doesn’t disappear if the theme is changed.

Site owners can stop using child themes. Opportunities for CSS customization is in WordPress core.


Need to preserve your WordPress functions.php file changes besides the style.css file, here’s our tip use:

Code Snippets
Add code snippets to your site. No need to edit your theme’s functions.php file again!

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.

Plugin popularity is a barometer of bloat.

To “Outperform” means being faster loading with a focus on mobile-inherent wireless remote delays. Considerations for things like packet loss and radio latency. Things we don’t worry about much for desktop users.

From our tests so far, WordPress core adds two calls for “Gutenberg blocks” – even with Gutenberg deactivated with a plugin. Now we hate that waste and remove those two scripts. But if you compare the number of requests made by other pagebuilders, that’s nothing. We’ve seen Elementor activate 70 requests. It depends upon activated “widgets.”

Does that make Elementor a dog? No. It’s the poster child of pagebuilders. But that doesn’t make it good enough for extreme mobile speed. For users who don’t have a million visitors – and less than 60 to 70 percent mobile visitors per month – it doesn’t matter. Let them use Elementor. No pain.

For some site owners, bad speed creates cart abandonment and profit loss. Those guys have pain. They’re our audience. We sell info to developers who build sites for profit-oriented site owners — businesses. These guys are special.

Also, the fastest theme on the planet (for now) is Twenty-nineteen. They didn’t include Google fonts (the trend for speed) but used a mobile font stack in style.css. That knocked a couple 100 milliseconds off the load time (200 to 300ms). Of course, you can get the same speed from Twenty-seventeen – if you disable Google fonts with a plugin.

Twenty-nineteen loads in under 50 milliseconds. It’s biggest competitors for theme speed are GeneratePress and Astra. And a few other stripped down themes, like Tiny Hestia. But they’ll never have the longevity and protection that an Automattic-authored theme has. GeneratePress is one guy (Tom with an assistant). He croaks and the theme is gone.

From our tests so far, Gutenberg keeps getting faster with each iteration. So they’re making speed a top priority. Time will tell.

If they stop in-house arguing about features, Gutenberg will be out in late 2020. Then it’s a full-bore pagebuilder. That’s what our intuition says. Meanwhile, new plugins add functionality to “blocks.” That makes them into stopgap pagebuilders with single-purpose, drag-and-drop functions. That’s good for speed.

Elementor is a multi-purpose Swiss-army knife plugin. Too much stuff. That’s not good for speed. They keep adding more and more to this plugin. It’s doubled in package size since they started. That’s not a good sign either. 1.1M > 2.3M

And last but not least, Elementor is a popular plugin with over 2 million installs. That is a barometer of bloat. Popularity and bloat go hand-in-hand toward slowness. Why? Inexplicable correlation. But our guess is prosperity produces code apathy.

Elementor is not bad. We’re building a “PagePipe” website for a guy in Denver right now. Are we worried? No. Because the client is on Pressidium ($25/mo for one site). They have a TTFB (time to first byte) with SSL handshaking of 700 milliseconds. Lots of headroom for speed.

A client in Arkansas also gets that same 700ms TTFB. That’s because we didn’t use SSL. And he’s on Godaddy ($8 per month two sites). Only $4/mo per site. Cheap.

The annual overhead differential is $300 versus $48. It only matters if you’re poor or care about reducing repeating rent costs. The client in Denver doesn’t care. But the guy in Arkansas does. He was paying $500 per year for hosting two websites on two different hosts. Now he pays $96.

You may think this insignificant. Especially for plump Americans. But 70 percent of PagePipe’s traffic is international. Some readers live on only a few dollars a day. In a third-world county, saving $100 per year for the same results is significant (food and shelter).

How to ruin mobile speed with aesthetics.

We hate waste. We’re unconventional thinkers and love creative problem solving. We take a different path to page speed improvements. Our odd ways make us smile.

We avoided CMS (WordPress) as long as we could. We handcoded using HTML, CSS, JavaScript snippets, with sprinklings of PHP. Why? Speed! We don’t consider ourselves coders. We’re not fascinated with it. Instead, we seek shortcut solutions. We’re natural advocates for WordPress plugins for non-coders.

As late adopters of WordPress, we balked and complained about WordPress slowness. But we accepted the challenge. We’ve proven it’s possible. But not without sacrifice of unproductive and expressive aesthetic features. There’s usually some *precious* but non-productive gadget or plugin destroying speed. It must be placed on the sacrificial altar to Mercury, the Roman God of Speed.

Our goal is to save the Internet from WordPress speed abuse.

Expressive aesthetic design in web-speak is often called “feature rich.” Feature rich and speed require a fine balancing act. Speed is a kindness to your users.

Yet more than speed, we’re concerned how UX affects profitability. Speed is the first barrier to good UX. Classic design aesthetic makes it so nothing distracts from the focus: the products or content. But too much classic aesthetic can be boring.

The Internet average page load time is 8 seconds. Way too slow. A site’s better than average when it meets the expectation of 2 seconds or better. Subsecond page loads are best for mobile. But that’s extreme performance optimization. We go into the red zone whenever we can.

This pullquote is an expressive design element.

Expressive design elements are intended to attract attention. But, they slow down site speed and make for a poorer user experience (UX). Specifically, anything that “moves” is expressive aesthetic. But it’s not limited to animation. If you get too much expressive aesthetic, you end up with visual noise and confusion.

What’s most important? When the user wonders what they should click next, you’ve failed. The hope is making sales – not noise. So these are the offenders: chat box features, sliders, disappearing Main Menus (make it persistent-on-scroll instead), popup surveys, animated product rollovers. And of course, poor hierarchy on the page (bad emphasis).

From our experimentation with human memory and boredom, users only tolerate 12 choices on a page. Then they feel overwhelmed and overloaded by cognitive burden. The more choices, the harder a buying decision.

Animation is more negative than positive for UX. It distracts most. The assumption is because humans are hardwired to snap visually to anything that moves out of fear, this instinct can be harnessed to direct attention.

Have you ever tried reading a page with a fly crawling on it? Annoying isn’t it.

Popups and sliders are intrusive. Flies! Even repulsive to user attention. They annoy. Users feel they’re manipulated by faddish, slow-loading gimmicks. We don’t care how effective the popup or slider plugin authors – and affiliates claim. Their opinion doesn’t count. It’s biased. No source credibility.

Free PDF download: 7 expert testimonials that sliders suck.

What-slider-is-the-fastest-loading?

When-to-use-a-responsive-slider-and-speed-tips.

Carousels and sliders address two mythical universal design problems:

1. “How do I fit more content into such little space?”

2. “Our committee can’t decide what content is the most important.”

These are seductive temptations for sliders caused by above-the-fold design delusion and myth. It demonstrates how design-by-committee sucks. Dilution of attention is the result.

What’s above-the-fold on mobile devices?

Get rid of sliders as a design crutch. This forces better content and design decisions. It lightens the page weight. What’s the most important content? How can you meaningfully and simply present one, single, most-important motivating idea?

You can’t emphasize everything. Emphasizing everything equals empathizing nothing – a marketing adage (E2=E0). If you attempt emphasizing more than one idea, you create cognitive and visual noise. Confusion, delay, or abandonment results.

The screen real estate is better used by a static image. Or even better – NO IMAGE AT ALL. State with non-moving text: who you are, what you do, and why it’s important to your audience. That’s your positioning statement or elevator pitch. Advertise it everywhere on your site.

Of course, these concepts really only matter if your home page gets traffic. If not much, then none of these tricks and strategy are significant.

So what are your 5 most trafficked pages? The ones that get 80 percent of traffic. Let’s look at those. Is the home page one of them? If not, then we don’t need to worry about it.

Get rid of:

  • Sliders.
  • Popup plugins.
  • Chat boxes.
  • Facebook.
  • Unprofitable products. (Reduce the site clutter).

Do Pareto efficiency analysis. Dump the duds. Unless these items listed above have quantifiable benefit and actually produce profits (not sales or traffic but real profits). Justify keeping them.

Facebook is often your worst non-productive site drag. 762k of assets loading for what purpose? Quantify how much Facebook *helps* your site profitability (not traffic numbers – quality not quantity). Then decide. Facebook usually takes traffic away from your site. Focus on profit – not artificial expectations.

There are other esoteric performance tweaks we do on our site. Like selective plugin activation – and dumping emojis, webfonts, and Font Awesome. Optimizing WooCommerce. But we’ve listed some low-hanging fruit above.

We make speed improvements for a $500 project fee. But read PagePipe and you can make the changes yourself (DIY). Save money.

Why you shouldn’t waste your time – and speed – writing SEO *rich* snippets.

We’re keeping this simple. Here are the real comparison of two Google listings of our blog post about PHP 7 and how it affects WordPress speed. Notice the difference in the snippet language.

First, we enter the posts exact title in the Google search field:

It’s the number one position naturally – because it’s an exact match. But notice the WordPress permalink underneath the link doesn’t match the post title. It gives more information scent for the user about the problem we’re addressing.

Your page tile and snippet don’t need to match. It’s better if they don’t. Publish more clues and cues for potential users and improve click-thru.

Information scent refers to the strength of relevant messaging throughout the customer journey as well as visual and textual cues that provide website visitors with hints on what information a site contains. – source

The snippet is selected by Google. It’s based on user search intent. Artificial intelligence drives the choice of snippet using an algorithm called RankBrain. It was introduced on OCTOBER 26TH, 2015. Long ago!

You should care about RankBrain because it’s an ever-increasing ranking factor.

RankBrain is part of Google’s core algorithm using unsupervised machine learning. Machines teach themselves from data inputs. RankBrain determines the most relevant results to your search engine queries. RankBrain’s used globally by Google. It sees relationships automatically. It makes educated guesses.

The guessed answer to a query improves as the computer learns what people are really looking for in searches. It builds a relational database of intent.

Search intent, also known as keyword intent, is the ultimate goal of the person using a search engine. Since people look for, process, and use search results differently based on their ultimate goal, understanding and optimizing for search intent is important for Google.

By leveraging keyword intent, advertisers not only increase site traffic, but also attract more qualified prospects. This creates more sales and generates more leads. It helps Google sell more ads!

Google uses RankBrain to select and construct featured snippet results from your page content – not from your handwritten rich snippet database. That’s right. Shock! Your snippet efforts are a waste of time. Stop writing them. Uninstall your slow-loading SEO plugin.

Snippets are history!

RankBrain does a better job of matching user queries with your web pages. This means you are no longer dependent on having all the keywords from the user query on your page content – or rich snippet.

So here’s the same page but with a new search phrase:

In this case, using the search phrase “PHP7 broken,” our same-post snippet is now pulled from a completely different part of our page. The results are better matched for keyword intent. Even if the keywords weren’t in the search phrase. Google guesses intent.

Notice the publication date is “7 days ago.” Fresh as a daisy! Read about how to keep content evergreen here.

Stop trying to defeat Google from doing a better job writing snippets. It’s their choice whether to use yours or not. Google has no obligation of compliance with your wishes or SEO manipulations. Google owns the web. They undo your wasteful snippet work in a blink.

Don’t try and save your snippets. They’re junk. Don’t install a different SEO plugin in some kind of salvage operation. They’re slow and obsolete.

Why Google Fonts affect content readability – and mobile speed.

When it comes to fonts, there are many web myths and unsaid facts. Especially concerning mobile speed.

The Google Fonts API serves the fonts listed in the Google Fonts directory. You cannot control Googles headers (including expiration headers). According to the Google Fonts FAQs, their font files are cached for a year. If so, why the PageSpeed Insights render blocking error?

 
Google’s CSS files associated with the font are only cached for 24 hours. Speed test expiration information shows this. That is how long browsers store the asset in the browser. Best practice is setting a 1-year expiration. Far futures expiry plugin controls this or you can hand code your .htaccess file on your server. We prefer the plugin.
 
Google calls its CSS files every time. This is for “font freshness” – updated versions. But that’s a Google smokescreen. Google says, “It’s for fast support of font changes.” Every font changes every day?
 
Daily updates? Really? It doesn’t churn that fast.
 
Ironically, Google Fonts fail Google’s own PageSpeed Test. It generates an error: “Eliminate render-blocking JavaScript and CSS in above-the-fold content.”
 
There is a plugin for hosting the fonts on your own web server (local). Not on Google servers (remote). Then you can do “far future expiration.”
 
 
and
 
 
We don’t use either plugin. We remove fonts. Some caching plugins allow “bundling” webfonts as an option, too. We’ve never seen those work yet.
 
Google, claims to encourage PageSpeed. But they don’t even cache their own fonts Why? A nice data collection opportunity for them. Wake up. It’s for their benefit – not you. There’s also a plugin to merge all font files into one – concatenation. This combines many webfonts into one request.
 
 
We’ve messed with this plugin and never can see it working in speed tests. So we’re not believers yet. But 6,000 other suckers believe.
 
It’s theoretical. When millions of websites all link to the same fonts, they are “ideally” cached. After loading the first font, it should appear “instantly” on all other later visited sites. But that isn’t true in all case or even in most cases. Google sees 1 CSS request per font family, per day, per user browser.
 
That request occurs most often on the most critical first impression. Those are visitor landing pages from the SERPS. Secondary pages don’t have the same visitor expectation for speed. So don’t decorate your main top10 pages. Keep those lean.
 
A single font request may take only 50 milliseconds. To put that in perspective, that’s the same speed as GeneratePress (free) theme.
 

“Web fonts are likely to enhance the performance, maintainability, and accessibility of your page” is a quote directly from Google.

 
That isn’t even a partial truth. Another Google deception. They aren’t that stupid to propose fonts improve site performance.
 
When you use a Google Font, you may load the entire set in the font family. Not a single style like “regular.” There may be many weights. This usually adds around 300 milliseconds to a critical first page (guesstimate). Now that doesn’t include delays caused by loading extra languages of the font set.
 
If you use an <i> tag (italic), which is quite common, that loads the italic font variant. Another 100 milliseconds wasted. If you call 10 font variants you produce a 1-second cumulative delay for fonts. That is very possible on branded sites (H1, H@, bold, italic, etc). Half the 2-second performance budget gone.
 

Google downplays the impact of their fonts on page load time. Especially for mobile phone users.

 
Font loading behavior varies depending on browser type. Some browsers only display text after font files load. Others will use the fallback font from the font stack and then refresh the page when the font is available. This behavior is the “flash of unstyled text,” or FOUT.
 
Websites include 3 fonts on average. These fonts are around 100K in size each. Fonts load after the HTML and CSS sources.
 
Staring at invisible text – or at font-swapping shifts – is unacceptable. The best option is giving up on custom fonts and relying on web-safe fonts. That’s our choice and preference.
 
We can’t describe the loss felt the day we threw our print type collection in the trash. It was something we loved. It was part of orchestrating the mood of a well-designed printed page. We let it go for a better mobile user experience. Gone but not forgotten.
 
Major content platforms (such as Wikipedia, Medium, WordPress and Github) use system fonts. They’re available for use on computer operating systems. This is a worthwhile strategy when styling is not a primary concern like small mobile phones. Not referring to tablets! On heavy-traffic mobile sites, traffic is 20-percent tablet visitors. The 80 percent bulk is small phone screens.
 

Blogs claim, “Great typography is crucial on the web” for readability, legibility and “well-crafted typographic design.”

 
Is well-crafted a must for brand recognition and the success of your message? We say credibility and readability trump branding. Frivolous branding requires special fonts. They’d do better paying attention to other readability details. Like not using small, squinty fonts or low-contrast gray colors.
 
Fast-loading mobile (modern?) font stacks look something like this in CSS:
 
body {
font-family: -apple-system,
BlinkMacSystemFont,
“Segoe UI”,
Roboto,
Oxygen-Sans,
Ubuntu,
Cantarell,
“Helvetica Neue”,
sans-serif;
}

Google says one thing. We say the opposite. What’s the truth?

 
We strip fonts unless a site already achieves under target speed goals. Then they’re ignored. But generally, we disable them. Site users are oblivious to the differences.
 
Trends in mobile include new speed themes like GeneratePress and Tiny Hestia. And the new Twenty-nineteen default theme. Out of the box they enable mobile font stacks defined in the style.css file. They don’t use Google Fonts. Fonts have a stigma for mobile. They consume unnecessary bandwidth and data limits.
 
Single-column, 350-pixel wide images or resized images are what’s served up. All that matters is legibility and readability. Creating any mood is from color choices. Color combinations recall memories. Memories have feelings associated with them. It’s a subconscious influence.
 
How much “mood or emotion” can you muster in a small 5.5-inch screen space? Be honest. Small blocks of color whizzing by with the flick of a thumb. That’s mobile user experience? More like roulette.
 
Stripped-down “speed themes” often don’t enable jQuery by default either. If you resist the temptation to install a slider, top-of-page button, or some other jQuery intensive plugin, you avoid the extra load. Themes did this in the past (like Susty, Frank and Sobe themes) but were seen as esoteric or fanatic and not well received. Now it’s a mainstream trend. The Herd wants extreme modifications because they suppose speed will save their site. Speed never compensates for poor content. Ever.
 
Discarding font baggage and jQuery are nuances for speed. They make for fast themes. But you can destroy that with a few popular plugins. Then the gain is minuscule by comparison. Dwarfed by thoughtless plugin abuse.
 

Fussing about choosing Google Fonts is wasteful.

 
Theme authors retrofitted speed change based on requests from users. The demand was high enough and thus offered the chance to sweeten the deal.
 
This means using Google Font usage is now seen as painful to speed and UX. And thus SEO. Big deal.
 
You don’t have to install a plugin to remove Google Fonts on these speed themes. The theme loads are transparent: meaning less than 50 millisecond load times. But if you buy the premium version, they’re no longer the fastest kid on the block. They don’t tell you that fact. The themes then are more average than special.

Human eyes have limitations. There’s a theme trend to use light-gray type on web pages. This is not good UX. But designers, who should know better, are setting bad examples. Black on white was the standard for many years. That color combination is fatiguing when reading a large block of text onscreen.

The recommendation is #333 dark-gray on white to reduce harsh contrast. But going lower contrast than #333 makes viewers squint to attempt reading text – even when the font size is 18px. We recommend using browser tools for checking font specifications including color and size. We use FontFinder for Firefox. There are equivalent tools for Google Chrome.

FontFinder type specification tool using Google Chrome.

 

“An article about how the web is becoming unreadable has been making the rounds. I feel like most designers already know that light gray text on a white background is a bad idea. The article focuses on text color but I think a more relevant issue is font weight – I’m seeing so many sites these days set body text in 100 and 200 weights which were not designed for body text use.” — Jeremiah Shoaf of TypeWolf

How the Web Became Unreadable
I thought my eyesight was beginning to go. It turns out, I’m suffering from design. by Kevin Marks

Look at these websites. They look fabulous indeed but how good is that if people can’t read them?

Light-gray text is fake minimalism.

“Minimalism in web design started as a backlash against decades of interfaces that increased the prominence of so many elements at once that they all clamored for attention and became visually overwhelming.

What’s great about minimalism is the principle of stripping out non-essential elements. In most cases, this is a best practice to follow.

When it becomes an issue is when there is lots of essential content on a page. Having a lot of content doesn’t suit the minimalist approach to design. So the designer’s compromise has become reducing the contrast of those elements so that, at a glance, the page still ‘looks’ minimal.

Yes, low contrast text does ‘look’ minimal, the same way a blurred photo on Instagram can ‘look’ retro. But you wouldn’t blur your website even if it were fashionable. Don’t lower your contrast, either.”Nielsen Norman Group

Easy reading helps learning and enjoyment, so what we write should be easy to understand. Readability is about ease of reader understanding. Text should be inviting. Text depends on content (vocabulary) and typography (font size, line height, and line length).

Readability Plugins for WordPress
An interesting article about web readability mentions several WordPress plugins that help assess the readability of body text. The one plugin we feel is most appropriate (because it’s lightweight) is: FD Word Statistics Plugin. It shows word and sentence counts at the bottom of the WordPress editor. Plus a readability analysis of the page or post currently being edited is shown using three different readability measurements. Those are the Gunning-Fog and the Flesch-Kincaid indexes. (Plus one labeled Flesch that we don’t care about).

Various factors to measure readability have been used, such as speed of perception, perceptibility at a distance, perceptibility in peripheral vision,  visibility, the reflex blink technique, rate of work (e.g., speed of reading), eye movements, and fatigue in reading.

Readability and legibility aren’t the same. Legibility is a measure of how easily individual letters or characters can be distinguished from each other.

The average adult reads at the 9th-grade level. It also shows that, for recreation, people read texts that are two grades below their actual reading level.

Four variables give the most reliable measure of web reading ease:

  • Words per sentence.
  • Average grade level of words.
  • Characters per word.
  • Sentences per paragraph.

Readability should be your number one goal. Someone in your company or organization should especially check graphics to ensure they’re readable. This means:

  • No “reverse” (white body text on a colored background, which is hard to read).
  • As few italics as possible (they’re hard to read).
  • Not too much boldface (ditto).
  • Not too much super-wide full-width copy (ditto).
  • No type above headlines (confusing).
  • No hard-to-read colors like light grays. There should be a 30% grayscale differential between text color and background color. We search for edges of letters for character recognition.

 


Measure onscreen font sizes in pixels using the Firefox browser tool: Font Finder or the Google Chrome browser tool: WhatFont.

6pt, 8px, 0.5em, 50% Sample text

7pt, 9px, 0.55em, 55% Sample text

7.5pt, 10px, 0.625em, 62.5%, x-small Sample text

8pt, 11px, 0.7em, 70% Sample text

9pt, 12px, 0.75em, 75% Sample text

10pt, 13px, 0.8em, 80%, small Sample text

10.5pt, 14px, 0.875em, 87.5% Sample text

11pt, 15px, 0.95em, 95% Sample text

12pt, 16px, 1em, 100%, medium Sample text

13pt, 17px, 1.05em, 105%, Sample text

13.5pt, 18px, 1.125em, 112.5%, large Sample text

14pt, 19px, 1.2em, 120% Sample text

14.5 pt, 20px, 1.25em, 125% Sample text

15pt, 21px, 1.3em, 130% Sample text

16pt, 22px, 1.4em, 140% Sample text

17pt, 23px, 1.45em, 145% Sample text

18pt, 24px, 1.5em, 150%, x-large Sample text

20pt, 26px, 1.6em, 160% Sample text

22pt, 29px, 1.8em, 180% Sample text

24pt, 32px, 2em, 200%, xx-large Sample text

26pt, 35px, 2.2em, 220% Sample text

27pt, 36px, 2.25em, 225% Sample text

28pt, 37px, 2.3em, 230% Sample text

29pt, 38px, 2.35em, 235% Sample text

30pt, 40px, 2.45em, 245% Sample text

32pt, 42px, 2.55em, 255% Sample text

34pt, 45px, 2.75em, 275% Sample text

36pt, 48px, 3em, 300% Sample text


Why image compression matters less than removing Google Fonts for speed improvement.

Facebook discussions go on and on about various “automatic” ways to optimize graphics. They assume oversized graphics are the only possible reason for web slowness.

Will automated image optimization solutions do a better job than a human? We mean better than optimizing each graphic by hand in a photo manipulation program. Machines can’t determine human quality perception. They can take a bad image – and make it much worse. Foolishness.

We’ve done our homework on image page weight (file sizes) and how it affects speed. Images may be 60 percent of page weight – but they aren’t 60 percent of page slow down. There isn’t as big of interdependence between speed and weight as site owners think. Only 10 percent of speed is image waste. The fastest sites on the web have no images. These generally load in under 600 milliseconds. Serious.

But that’s Spartan or Stoic discipline. Speed overkill. The site owner has 100-millisecond Time To First Byte (TTFB rare quality). And 400 milliseconds of SSL handshaking (best case). And then 100 milliseconds to cram in the actual page assets. Done. Less than 1 percent of websites are 1-second fast. How do they look? Boring.

The average page load time on the Internet is 8 seconds. Can you believe that? It’s proven 10 seconds is the end of human tolerance. Backbutton: Click! Gone.

Images load in parallel now on browsers. Fast. They are often no worry at all. Bigger worries are assets that request information from remote servers. You’ll achieve more effective optimization removing Google Fonts than tweaking images. Remove Google Fonts with a free no-setting plugin.

Or even better, a fast theme that uses a mobile system font stack in the CSS style code.

Removing fonts is a nicety for speed but not always essential. Image optimization isn’t a greater consideration than Google Font slow downs. We’re talking 100 to 300 millisecond gains is all. 300 milliseconds is still 15 percent of a 2-second performance budget. You don’t ignore that. But in some cases, we do.

The big exception for image failure is when total geniuses build websites. Pseudo-intellectuals think a 24-bit PNG is WAY better than a lossy JPG. Huge PNG images are then placed on every page as featured images. Horrific misjudgement.

We’ve seen pages drop from 12-second loads to 4-seconds. How? By converting the media library non-transparent PNGs into JPEGs. Is 4 seconds good enough speed? Not ever. But it’s better than average page load time.

Image resizing and compression plugins cost money based on usage. They don’t tell you that in the plugin description. Compressed images on a remote server return back to storage in your media library. The services aren’t free. The meter is running above a set quantity threshold. The exception is Imsanity plugin. (No typo on that odd name). Imsanity stops insanely huge image uploads like from digital cameras.

But Imsanity is still a dull person’s plugin. It’s for apathetic loafers who won’t optimize at all. We recommend using Imsanity as a safeguard against client foolishness. It’s not needed on our sites because we hand-optimize (like you do – right). But it’s our favorite plugin to prevent client sites from blowing up.

Most optimization plugins connect to a third-party server floating out in web cyberspace. Some need an API or account permission request. These remote server calls retard website speed whenever there’s activity.

If you keep images pretty small (dimensions or file size or both), all images load at the same time. Boom. 50 milliseconds. Larger images are a problem. Like full-screen desktop Retina size. Those need examination. They aren’t broken into smaller data packets causing delays. Small stuff is inconsequential for load time.

What things help image speed most? Proper image sizing. First. And second compression settings. But squeezing images to where they’re unrecognizable won’t payback benefits. There’s no reason today not to keep the quality compression setting high – 70 and up.

WordPress optimizes images already to a Photoshop quality of 50. That’s right. WordPress rebuilds and compresses images in the media library. That feature improves on-the-fly swapping when screen sizes are smaller. This is for built-in speed.

Do you need more compression than that? No. But it doesn’t compress original images. Just thumbs and medium sizes. Nor does it resize originals.

Some themes like Twenty-seventeen have built-in lazy-load for featured images (2000x1200px or bigger). 3,000 pixels square is the recommended starting size for Retina-ready images. That’s according to Retina 2X plugin instructions. It’s a good plugin if you must deliver Retina images. But that’s a huge and heavy image.

Lazy loading images improves perceived load time. But the same amount of data still goes through the pipe. This extra weight is detrimental for mobile speed. Why? Because of data consumption cost. Lazy loading doesn’t remove any extra data weight, it only delays it.

Lazy load does unpleasant things on occasions. Like loading a logo last that appears at the top of the page. This delayed load may cause Flash of Unstyled Text (FLOUT). That makes a page look broken for a second. This is not good UX. So on some sites, we don’t use lazy load. Or we may choose to disable it on key pages with a plugin like Plugin Logic for selective plugin activation. This is Plugin Surgery.

“So … if I’m optimizing in Photoshop, and then use a plugin will that optimize it even better?”

Pain is a great teacher. Try that trick. It won’t work.

If you compress images in Photoshop or Gimp, you don’t need further compression.

OTHER READING

How web design colors affect mobile speed.

Can studying Google Analytics web statistics influence design color choices? More ways than you might think. But first you have to know where you’re at. And where you’re going. You must know what is most important. What is valuable and what is not? To answer that you need objectives – goals for making good choices. Even for something as simple as colors.

You have a WordPress website. This imaginary site gets good traffic. Monthly, two percent of your new web traffic comes from Facebook. Almost nothing! Social media has failed. Everything reported is organic Google search results: 100-percent traditional. Imagine your information site receiving 20,000 unique visitors per month with 18,000 leaving in under 10 seconds. Most everyone plainly perceives they landed in the wrong place.

Perhaps the description underneath the Google search link misled them. Somehow, you didn’t serve the information they were hoping or expecting. They then reacted negatively by hitting the back button – and kept on searching. On the web, people’s behavior is impatient and intolerant.

Of your remaining new visitors, only 2,000 per month stay for 3 minutes to over 30 minutes. Those are the people who are engaged and interested. They read content because it’s perceived as relevant. They watch videos in hopes of getting answers to their problems. They may even do something beneficial like signup or buy.

What if Google Analytics tells us 60 to 70 percent of visitors use Apple iPhone and iPads? Those real numbers are whopping. The majority is mobile. Is that normal? Sometimes. It’s happening on many sites now.

Your imaginary home-page, load-time is under 4 seconds. That doesn’t seem so bad. But Google reports your most popular landing pages are averaging 6-seconds or more to load. That speed (slowness?) doubles into about 12 seconds on a mobile device. This wait is beyond the human 10-second threshold of pain. Attention wanders. That means viewer boredom, frustration, annoyance, and abandonment increases. Hmm? No wonder the bounce rate is high.

You have a big user experience problem affecting website profits. Speed is killing opportunity. Can color help solve this speed problem? Maybe.

Speed is primary to achieve mobile site goals. We have to get past that barrier and achieve an ideal 2-second load time. Yet, we need branding (decoration) that communicates to the right audience. Decoration adds page weight. Bloat occurs on overly decorated sites.

Alexa gives us demographic data that Google’s free service can’t provide. What if our marketing goal is to appeal to an all female audience? Not men. But Alexa indicates 40 percent of site visitors are male. Men are unqualified leads. How can we subtly tell men to get lost and not waste our time? How can we entice women to stick around? Can we filter sales leads with color? Can color be “weightless”? (Weightless meaning not adding any page weight or drag to the site).

OFFSITE REFERENCE: https://www.psychologytoday.com/us/blog/brain-babble/201504/when-it-comes-color-men-women-arent-seeing-eye-eye

An unconventional solution.

Women know when a female designs a website. If your audience is female dominant, you need the touch of a female designer. Men aren’t so perceptive.

The speed-and-decoration balance lies in one simple trick. We must discard photographic images – and all Jpegs for that matter. Instead, we must use solid-color, illustrative, PNG-image files. Not Jpeg format.

JPEG is the most widely used image type on the Internet. Of all websites, 70 percent use JPEG images. JPEG image compression exploits certain properties of our eyes. This allows for compression for smaller files. But they are rarely as small of files as illustrations.

We’ll demonstrate. 259k Jpeg vs 17k PNG.

Screenshot at 2016-08-08 20-08-40
Above: Typical banner Jpeg image, 400k, 1920px × 1280px, background image. Heavy for mobile bandwidth.

 

Above: Typical custom line-drawing header with reduced color numbers (hero-image substitute), 17k, 1100px × 259px. Much lighter. 17k vs 259k. Hmm? Which will load faster? Illustration always wins over photos for speed.

A PNG illustration banner or hero image consumes so few kilobytes because it’s visually simplistic. Visual complexity increases image file size. Therefore, consider using illustrations and graphics rather than detailed photographs.

But, you say, “They aren’t the same image! Is that a fair comparison?” Actually, yes, it is. Because they both communicate. An illustration is less complicated. It can focus the message with fewer details and fewer colors. This improves viewer attention. And speed!

What’s more important than speed for SEO? Writing good post titles!

Please remember relevant content is number one for SEO. Speed affects User Experience (UX). Good UX then influences metrics like dwell time, bounce rate, and click through. Google interprets those as user intent.

User intent is a major factor in search engine optimization and conversion optimization.

Speed affects page ranking less than 1 percent. But everyone hates a slow page. That’s not being hospitable or polite.

Speed is about kindness!

Common-sense tip number one: Good Titles.

Writing good titles for your WordPress posts should be obvious. But we’re always stunned at how many sites don’t use this simple tactic to improve Search Engine Optimization (SEO) and click through.

Page title is important. People choose to click your listing on the Search Engine Results Page (SERP) instead of nine other competitive page titles. A title arouses human curiosity. If it doesn’t, it’s a loser. The WordPress permalink is written for machines (search). It doesn’t need to match. Title is an important controllable indicator of relevant content in the search listings. This affects findability, too.

People read your article based on it’s title.

A good title reads like a headline. A plugin we used for  a year is a good teacher for writing better titles. Title Experiments is a free plugin available in the WordPress plugin repository. The plugin allows you to test multiple title variations for any post or page.

WP Title Experiments Free

Title Experiments relies on the old classic WordPress editor. It won’t be updated to support Gutenberg block editor added in WP 5.x. This is the author’s excuse to ditch the paid plugin. It’s plain he’s disappointed by the lack of plugin income. No enthusiasm to go on.

Our workaround is simple. Use the Classic Editor Plugin with the Classic Editor Addon. So even if your core version is 5.0+ and your running PHP 7.x, things still work.

Title Experiments is a helpful plugin. We learned a lot about what titles work and what doesn’t for user engagement. But the heavy plugin was a top contributors to site drag. So we removed it after our education on writing better headlines (page titles).

Title Experiments relies heavily on the old editor of WordPress and will not be updated to support Gutenberg (WPv5.0+).

This is an author’s excuse to ditch the plugin.

Every year we review the last 4 months of traffic and see what is performing and trending. We’ve found our worst performing posts always have a lame headline (title). Renaming the post is the best thing to try first. We also dump dead posts or consolidate posts. This has proven effective for three years now.

For example, a mere label such as Ferritin and Hypothyroidism could be rewritten for human interest.

“What are optimal ferritin levels for hypothyroidism?”

That makes people curious and they click. Questions are always good. And including the word “you” is beneficial. Answer the readers question, “What’s in it for me?”

Purging your site is wise and focuses your content. That’s good positioning strategy. It affects perception of your site credibility.

How to find out what you should be writing about?

Intuition is needed for what future content to add. Not just metric history evaluation. The best article to write probably isn’t even on your radar yet. Our best post ideas come from reader’s emails who have questions. When we’re done writing long answers, we convert the email into a post – or add to an existing post.

Analyzing your inquiries isn’t something Google Analytics can do. Except for one helpful thing:

If you go to Google Analytics > Behavior > Site content > View full report (down in the right hand corner), you’re shown the top 10 of xxx pages. In our case 378 pages, we then change the “show rows” to 400. You then can see all posts and pages by popularity. You will see some entries with the following format:

/?s=Beaver+builder

This line above originated from our WordPress search box. A human couldn’t find something they needed on our site. Important info. They wanted to know more about Beaver Builder pagebuilder plugin.

We don’t have a Beaver Builder article. Do we need one? Maybe.

Going to the top of the GA page, there is an Export function on the right. We download the entire set for whatever period we choose and import that into a spreadsheet.

Then we categorize and sort the “searches.” The results reveal what people were looking for. We then test by doing a Google Search on the terms with the name “PagePipe.” That reveals what kind of placement the search phrase gets in the rankings.

This influences what we write about based on reader’s questions we’re not answering. So far this is helpful. How else can you learn what you don’t know?

From our recent analysis, we generated the following preliminary titles for future posts:

  • Why don’t we write about good hosts? Why only the bad ones?
  • How does cookie consent compliance affect speed?
  • Measuring HTTPS/SSL drag with ByteCheck
  • Why we don’t review paid themes
  • Why we don’t recommend CDN
  • How to use Cache Enabler plugin for speed.
  • Is Imsanity plugin good for speed?
  • How to use Autoptimize plugin for speed.
  • Magnetic versus SSD hosting for speed
  • What is site-origin optimization?
  • Speeding up Astra theme
  • Speeding up WooCommerce sites
  • Why use twenty-seventeen theme instead of twenty-nineteen?

We then work on these article ideas one-by-one.

OTHER OFFSITE LINKS ABOUT WRITING GOOD TITLES
We Analyzed 912 Million Blog Posts. Here’s What We Learned About Content Marketing

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 pagebuilder (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

 

How large hero images affect mobile speed.

“Hero image” is a term used in web design for a specific type of web banner. A hero image is a large banner image, prominently placed on a web page, generally in the top, front and center.

A large hero image (usually a WordPress featured image) on a posts is irrelevant or generic if it doesn’t help move site visitors towards a conversion goal. There are only two critical performance metrics: sales lead generation and improved engagement (stickiness). Visitor engagement is indicated by click-through, page dwell time, and multiple visits. These are the inverse of high bounce rates. Information is no longer scarce – attention is scarce.

As content has grown increasingly abundant and immediately available, attention becomes the limiting factor in the consumption of information.

A high bounce rate means we’re attract the wrong people (traffic) – unqualified leads. The decision to leave a page is an impatient and intolerant “snap judgment” from interpreting subconscious relevance cues. These include typography, speed, readability, color usage, images, and symbols. These combined together are sometimes referred to as branding or design. In the end, it’s nothing more that a feeling of being in the right place.

If it takes the user too long to locate something, they will find it through another application. This is done, for instance, by creating filters to make sure the first content a viewer sees is relevant, of interest, or with the approval of demographics.

A large hero image is positioned in the most critical place to influence a visitor’s stay-or-go decision. It’s usually the first thing a  viewer sees. It becomes a critical device for attention and engagement. It’s our responsibility to make sure the hero image is relevant to the user – it’s not a job for the viewer. Otherwise the image becomes attention pollution.

What are you providing by serving up a large featured image? Is it merely a cue to content? Or graphic signage to make pages appear different and less boring? Does the use of a large image communicate a message worthy of the longer load time? It the page real estate wasted?

What is really needed are systems that excel at filtering out unimportant or irrelevant information.

Users have words and phrases in their mind that will cause them to click on a link. We call these trigger words or cues. They are essential to good navigation. Users want to get to a site’s content as quickly as possible. For this, they use information scent. Good information scent give clues and implications that they are hunting and searching in the right direction. They “feel” they will find the solution to their need or problem soon. This is also called findability.

Is herd mentality affecting hero image choices?

Just because your competitor is using stock hero images in the banner of every blog page doesn’t mean it’s a good thing. The herd majority is presently doing this page design treatment. It becomes invisible or transparent. It is ignored. Why?

Milestones during typical page loads:

2.5 seconds for the headline overlay to appear.

3.5 seconds for the background hero image to appear.

4.5 seconds all critical elements are on page.

6.5 seconds for the page to finish rendering. Note: Lazy loading Facebook “garbage / widgets” during that 4.5 to 6.5 seconds window is the most common delay. That’s what takes so long for complete rendering. Can you hear our contempt for Facebook’s speed apathy!?

Double those times for mobile screens.

When you place text on top of photographs, you usually ruin the image aesthetics and the text readability simultaneously. This happens and is bad practice – but part of popular WordPress theme rigidity.

The background image (hero image) is sometimes much bigger than needed for mobile because of the desire to conform to large-screen, retina-display standards. This poor image decision most likely is made by a designer concerned first about their portfolio. Not mobile experience. A mobile audience doesn’t use these kinds of screens – let alone can afford them.

We need to limit the number of page design elements that compete for visitor’s attention.

The size of a typical hero image on sites is around 1920 pixels x 1280 pixels and is scaled to size in the browser window. HTML code downsizing means the browser must calculating page space on the fly – a bad practice for speed. It causes a screen-rendering delay as “the machine” stops to think. And only a small portion of the big image is actually seen. The Jpeg image can weigh above 400k! Optimizing a little bit more might knockoff 100k easily. WebPagetest.org agrees with us about that image-optimization assessment. But the reduction to 300k is still too heavy for mobile page loads.

COMPARISON USING STOCK IMAGE

Typical page layout with hero image.

 

Actual size 400k background image. The whole image isn’t used.

Much of what determines where people invest their attention is below the level of pure reason. Indeed, research suggests that one of the most important factors for gaining and sustaining attention is engaging people’s emotions.

Mobile screens may be just 320 pixels wide.

One source of large, free hero images is Pexels.com. They have classy, professional photography. A typical Pexel image download is almost 700k page weight and 2682px x 1782px dimensions. Resizing and optimizing helps – but is still not good enough for mobile design.

The takeaway: The fastest image to load is – surprise – no image at all. Next best is a repetitive image that is already cached in the browser. But that can get pretty Spartan and boring. For information sites, textual content is more important than images – unless images illustrate or demonstrate a point.

Since Hero images frequently fill the whole screen, it forces users to scroll to find the point of your website. Hero images are frequently eye-candy and don’t have relevance to the article or blog post. It takes work and thought to find the right stock images. So, there is often a disconnect. Instead, using a call-to-action linked with an image would make more sense. Or even a large signup form. Publishing a positioning statement about “who we are, what we do, and why you should care” is good communications strategy and good ideas, too.

Large background images add a large amount of weight to a page for very little actual gain. Any user whose screen is generally smaller than 1024 pixels will absolutely not see the background image. Small screens simply don’t have the screen real estate to display content and background images. WordPress now attempts to load an appropriately sized “backup” image based on mobile screen size. But we aren’t seeing results in speed testing yet.

A video placeholder as a hero image is a creative technique by making it seem like the entire hero image background is a video that can be played. It’s just a static image that if you click on the “play” button you get a video Lightbox that starts playing a normal-sized video for you. The idea though is that the “play” button is the bull’s-eye of the top portion of the home page. The way it is placed makes you really want to click on it. Then the video sells you on the product or service.

Moving the header hero image down the page for lazy loading is wise, also. But is it still a hero image? We don’t know.

Better hero images do the following:

  • Answer customer questions.
  • Highlight your value proposition.
  • Make an announcement.
  • Feature a service or product line.
  • Include a built in CTA button.
  • Have consistent branding.
  • Reduce customization for limited resources.
  • Make our best promise that we can keep.

Good hero images contribute to the following feelings:

  • Immediacy – priority access, immediate delivery.
  • Personalization – tailored just for you. Personalization is one of the most important factors in viewers choice to attend to one piece of information over another.
  • Interpretation – support and guidance.
  • Authenticity – how can you be sure it is the real thing?
  • Accessibility – wherever, whenever.
  • Embodiment – books, live music.
  • Patronage – “paying simply because it feels good.”
  • Findability – “When there are millions of books, millions of songs, millions of films, millions of applications, millions of everything requesting our attention — and most of it free — being found is valuable.”

What kinds of images get immediate attention:

The factors most highly associated with getting attention, in rank order, are:

  • The message/image is personalized.
  • It evokes an emotional response.
  • It comes from a trustworthy or respected source.
  • It’s concise.

Messages/images that both evoked emotion and are personalized are more than twice as likely to be attended to as the messages without those attributes.

How Live Chat affects mobile speed.

Live support is a web service for communicating with text in real time with web visitors. Third-party live-support applications are commonly used to provide customers information. It’s also called live help or live chat.

People don’t want to chat … they want answers.

LiveChat helps you support customers in need of help. It allows you to increase your sales by engaging the right prospects at the right time as well as by generating a ton of new leads. – Source

Is that self-serving statement by LiveChat, LLC about “tons of new leads” true? Popular popup-style live-chat are often found on WordPress home pages and landing pages.

Does live chat really boost conversions? You’ll find plenty of affiliate articles answering, “Yes.” Promises, promises. Face it, live chat is an overhyped and overused fad to sell plugins and API services. Making money isn’t bad. Lying is.

Do you have live chat activated on your Home page? Are you really getting benefit from this heavy feature?

For example: Live chat heaviness typically is 9 requests and around 350k of page weight added. It may cost $17 per month or $180 annual overhead. Does live chat really contribute to profitability? It may be your heaviest web asset.

Site owners include wasteful live chat – even when it’s ridiculous presumption.

Sites using live chat often try saving money on a per-interaction basis. A chat agent handles three to six conversations at once – while a telephone agent handles just one.

Because you have cool technology doesn’t mean it provides a better user experience. Didn’t mother ever tell you, “Just because you *can* doesn’t mean you should?”

Live chat is bad when you’re using a free or low-quality chat provider. Your page loads slower. Or may not load at all during chat-provider downtime. Before-and-after speed measurement tell how bad the impact is on performance.

Chat technology takeover hasn’t lived up to the marketing gimmick hype.

Live chat on home pages and landing pages is intrusive. It interrupts the user experience in the same way popups do. It distracts attention from page content. Pages have content for a reason. There’s a message to deliver. Chat popups distract.

If users can’t find what they need, without the help of live chat, then there’s something wrong with your site. You need to fix it, not chuck another slow-loading gizmo on top of it.

Does live chat feel trustworthy? It reminds us of gimicky slick tricks. Herd mentality strikes again.

Live chat only works if there’s someone caring behind the software to respond to customers.

Some sites use live chat because their forms suck. Some think live chat is “better” than web forms. There must be something wrong with your form design. Fix your form before adding live chat.

Improve your forms instead:

  • Use form elements correctly.
  • Remove unnecessary fields.
  • Remove unnecessary clicks.
  • Improve mobile performance.
  • Stop using CAPTCHAs.
  • Take it easy on validation.
  • Stick to single columns.

We recommend not using live chat because it ruins UX and performance speed. It’s also indicative of sloppy marketing communications. Improve your content instead.

OFF-SITE LINK
New Research: 21% of Companies Fail to Respond to Live Chat Requests

Speeding up aggregator WordPress websites.

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 percent bounce rate typically. Top aggregator sites are getting as low as 25 precent 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).

No matter how much you try third-party Javascript is always the speed killer on aggregator sites. Third-party widgets include Facebook, Google GA, ad services, gravatars, Twitter, YouTube, Icegram, Doubleclick, popups, FontAwesome, etc.

“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: WordPress founder, August 2015

Aggregator sites use many third-party widgets.

There’s esoteric talk and proposals in the “website-performance” community to solve third-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 third-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.

Doing value analysis (cost-benefit) especially on Javascript and defining “how good is good enough” is determined by user engagement – and your whim. What is the conversion rate with and without the third-party scripts?

Most offsite (third-party) assets have mechanisms (alternatives) for better browser behavior. But each has to be examined based on your goals.

How can you see the impact ads have on your site? Log into your free GTmetrix account and under the URL field there will be an “Analysis Options” button. Check the “Adblock Plus” option. Your URL will be scanned with the ads blocked. You can also enable this option in the “Page Settings” button on the Report page sidebar.

Blocking ads is helpful if you want to see the impact the ads are having on your page load times.

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.

Suggested links:
http://apmblog.dynatrace.com/2011/12/20/third-party-content-management-applied/

https://www.soasta.com/blog/10-pro-tips-for-managing-the-performance-of-your-third-party-scripts/

We just reviewed an aggregator theme called “Bimber.” This PagePipe article might interest you >

When is a plugin too old to trust?

Today, PagePipe uses 70 plugins. About 30 not updated for over 1 year. Some for many years. We’re not embarrassed about that. It’s not a mistake.

Plugins listed in our ebooks are currently used on PagePipe. And also on client sites – except for Guerilla sticky bar. The plugin author removed it from the directory in recent times. Why? Because he became bored with it.

So the question is “Outdated? By what definition?”

What does outdated mean? Some think a warning like:

“This plugin hasn’t been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.”

Being orphaned or abandoned doesn’t mean “bad or rotten.”

These lonely plugins still work. And often for over a decade without complaints. That isn’t brokenness.

REFERENCE: http://pagepipe.com/information-scent-deciphering-the-wordpress-plugin-repository/

Above, we explain retention rate is more important than plugin popularity. Or even freshness.

But also in the article, we explain:

“Does 8 months since an update concern us? Not in the least. There are plugins that are 8-years old in the directory that work fine. Those “best if used by” freshness dates are silly. They throw people off with their arbitrary “expiration-date” warnings.”

WordPress places warnings when a plugin isn’t tested with recent versions. Does that mean it won’t work any more with new versions of WordPress? Nope.

WordPress’ motive is covering their legal behinds against liability and lawsuits. If a plugin didn’t work any more or presented security hazards, it’s removed fast. And some are. In particular, malicious plugins. They call those “take downs.” Plugin authors remove some because they didn’t get the market results they wanted. But generally plugins stay as long as there isn’t any noise about them. Retired or dead author’s plugins stay in the WordPress free directory.

No plugin is safe. Not paid (premium) plugins. Not obsolete plugins. And not recently updated plugins. A common plugin problem is automatic updates loading onto managed WordPress sites. Bugs in the new version mangle the site or causes conflicts.

It happens.

There’s no such thing as a risk-free plugin or theme. Even reckless WordPress messes up with their own Automattic-authored plugins.

We use Peanut Butter Bar plugin on various sites in place of the now-absent Guerrilla sticky bar.

We use “Remove Google Fonts References” plugin on PagePipe instead of “Remove Google fonts” plugin. Both work without problems. Both are several years old and work fine.

Good-old “Plugin Logic” is our secret, speed-weapon plugin. It’s used on every site we touch. SELECT.ME issue #11 talks about it. It’s an amazing plugin.

Want to keep a specific plugin from updating? We recommend “Block Specific Plugin Updates” plugin. There are times this is handy.

https://wordpress.org/plugins/block-specific-plugin-updates/

A plugin we use to track plugin age is “More Plugin Info” plugin
https://wordpress.org/plugins/more-plugin-info/

There’s plugin churning in the 55,000+ plugin database. Don’t let silly warnings discourage you. They aren’t for your protection. They’re protecting WordPress.

Don’t fear old plugins.

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.

FINAL WORKING RESULTS

 

The prototype page on Twenty-seventeen theme:

WP Engine ruins mobile-first speed strategy.

WP Engine is frequently recommended on blogs as the “Best Premium Shared Hosting for Advanced Bloggers.” Of course, blog authors sharing *trade secrets* get an affiliate-link kickback or commission. They make money touting others hosting services. No source credibility.

Many error thinking WP Engine must be better or even the best. It costs a lot. It’s recommended so often. They must be good because they have a good reputation, right?

That “feel-good” hosting is $420 per year. Yet, it’s the exact same terrible-speed quality you’d get elsewhere on cheap, shared hosting. For $5 (or less) month-to-month rent – only $60 annually – you’ll get the same perfectly-lousy server delay. That’s $360 dollars decreased difference every single year. Over 5 years, it’s $1,800 profit in your pocket. With the exact same speed results.

An unexceptionable, shared host may get the same poor TTFB (time-to-first-byte) of 1.5 to 1.7 seconds. That’s 1500 to 1700 milliseconds off our target 2000-millisecond performance budget. That leaves only 300 to 500 milliseconds. Short time to load WordPress core, the theme, all plugins, and third-party scripts and APIs – and images. Is it possible? Only if you use speed strategy.

You can’t be sloppy or apathetic.

So what hosting provider do we recommend? None! Why? Because hosting services cycle from better to worse with the host’s business whims. Without a crystal ball, we can’t predict odd behavior. One day a host provides mediocre to excellent speed. Six months later – with a simple ownership change – crammed overburdened servers slowdown. Your server turns into a dragging slug. Their hosting business suffers losses caused by poor services. They finally invest in better capacity. Speed then improves. Until the word is out, they’re doing better. Then the cycle repeats.

In one test, for a New York client, BlueHost crammed more than 2,000 domains on a single server.

That BlueHost squeeze strategy isn’t typical. Still, test for the number of shared domains using your URL at YouGetSignal. Test server TTFB at ByteCheck or BitCatcha. Warning: All bitcatcha.com’s recommendations are affiliate links. They promote hosts giving back the most. It’s all about money.

Blogs recommending WP Engine don’t examine the speed performance ramification. Let us tell you why WP Engine is bad news:

WP Engine’s hosting services have bad TTFB (time to first byte or server overhead). It costs $35 per month (or more). Do they specify TTFB in their sales pitches or online materials? No. Of course not. No one would use them if they knew the truth. So most hosts avoid publishing this important speed information. Is WP Engine the only one burying TTFB specifications? No. Is it a criminal cover-up plot? We hope not. It’s most likely a convenient sin of omission.

Every host avoids the server overhead delay topic. Why? Because TTFB  wanders and is often unpredictable. Or they may make excuses and declare with authority, “3-second TTFBs are normal.” iMotion Hosting makes that absurd statement. They’ve got to be kidding! But we’ve measured iMotion unstable server delays producing double that slow time.

Hosts don’t want you holding their feet to the fire. They don’t want that responsibility. Making server-overhead promises causes disappointing buyer’s remorse.

TTFB ignorance is bliss. Until you discover during real load-time testing how much it affects speed. Go ahead. Complain to the errant host. They’ll usually recommend (upsell) more expensive servers. They may suggest trying speed first-aid like CDNs and caching services.

The real cost-effective solution is building a fast site instead. Hosts won’t recommend this speed solution. They make less money if you build a fast strategic site.

One of WP Engines claims to fame is they’re *managed* WordPress hosting. What’s managed hosting and why is it bad for mobile speed?

Managed WordPress hosting is an “attendant” service. The host takes care of (manages) all technical aspects of running WordPress. This includes security, speed, WordPress updates, daily backups, website uptime, and scalability. All that costs money. Normally, people use automated plugins for these features. The less WordPress knowledge you have, the easier the motivation to buy these fantastic services.

So what? What’s the big deal? Sounds like they’re being nice and helpful. If they live up to their fantastic speed claims, there’s no quibble. But they don’t.

What they do is lock you out, the “advanced-blog” owner, of Cpanel access and lock each file so it can’t be rewritten. Who cares about that? They do. They don’t want anyone mucking about on their server.

You don’t buy more features. You buy less flexibility – and then pay more. It’s brilliant.

But flexibility is how you increase speed! The irony. WP Engine won’t let us help you speed up your WP Engine site.

One big strategy for speed is selective plugin activation. That only happens when speed plugins (or even hand coding) alter the server .htaccess file. That can’t happen with “managed” locked files. Unlocking and altering .htaccess may mean going through an FTP client. Just very messy, inconvenient and a royal pain in the butt. The chances of breaking something are not reduced but increased with “managed” hosting.

.htaccess is a configuration file for use on web servers running Apache. The .htaccess file is detected and executed first. It give the server rules of special exceptions. Even WordPress manipulates how Apache serves files via .htaccess – especially handling pretty permalinks.

.htaccess is used for speed functions. Such as:

  • Far-futures expiration.
  • Enabling Gzip.
  • Hot-link image protection.
  • Enabling keepalive.
  • Removing query strings.
  • Leveraging browser caching.
  • … and other speed tasks.

Our other complaint seem trivial, but for speed fanatics like us, it’s not: We can’t rollback the PHP version from 7.1 to 5.6. Why would anyone want to do that? 7.1 is faster loading. Well, it’s temporary for plugin testing.

Some old plugins, need old PHP. They won’t work on more modern PHP. Some even break your site.

A favorite old plugins is P3 Plugin Performance Profiler. We’ve written about it’s benefits before. There is no adequate alternative – yet. How much do we love this plugin? Well, we wanted a plugin author to change it to our specification – and make it compatible with PHP 7.x. How much would that cost? $10,000 dollars!

No surprise. We decided to stick with a simple workaround by dialing back the version to PHP 5.6. It’s simple to do – if you have Cpanel access. But with WP Engine shared hosting? No way. They don’t allow that. This barrier means we can’t quantify the worst offending plugins for site drag. There is an exception, if WP Engine screwed up and never advanced your version to PHP 7.1 –  inconsistency. We’ve seen it.

So we ask, if you’re an *advanced blogger*, why the heck are you using WP Engine who assumes users are idiots? We’re insulted.

Plugin tricks to personalize WordPress posts.

Why would anyone want to use a plugin to add a signature to the bottom of a post? It’s marketing communications touchy-feely stuff. The logical explanation isn’t that easy and not everyone “gets it.”

No one really explains the cosmic reason why signatures are “good” practice. So explaining from a marketing standpoint could be better. It seems so obvious to signature-plugin authors that they forget not everyone can see a benefit to an automatic signature.

It’s always been our recommendation for clients to add a personal signature on About pages — or what we sometimes label as Interview pages. The client always asks, “How come?”

These special pages with signatures (for us anyway) are in a FAQ format. For some reason, search engines think these are important pages. It could be the keyword “interview.”

Anyway, a signature (even a fake one – like a calligraphic script font) in blue ink on white background has a “feeling.” (Blue seems more pen like than black – again silly human memory stuff). It’s more intimate and experiential. It’s marketing voodoo. People consciously know you didn’t sign the screen – but they have a feeling of connectedness. They secretly wish you did sign each post.

Like a personal letter from a family member or friend, it’s subconscious psychological weirdness triggered by a scrawl onscreen. But it works. It’s endearing. It seems friendly. Perhaps because it appears handcrafted instead of by machine.

It definitely has to do with memories. Just like color combinations do. Or the smell of crayons. Or old songs on the radio. Why do those take us back in time? And make us smile or cry?

We could see creating a blog where we wanted that personal feeling on every page. Then we’d want a plugin so we didn’t always have to repeatedly place an image file at the end of each post.

Each post would then become a personal message to the reader (like a personality).

 

Above is an “interview” page we designed for a photographer. His signature is essentially his logotype and part of his branding. It’s at the top of the scrolled text. But most frequently, we put them at the page bottom. Here the signature almost serves as a caption for his photo.

His signature is quite distinctive. We humans can tell the difference in those small quirky details in a persons handwriting. We actual recognize the patterns and can say, “This note is from my cousin Bill. I’d recognize his sloppy handwriting anywhere.”

There are several ways to solve this automated signature problem. But not worth it if it adds one second to the load time. We didn’t do any speed tests.

We did a search on “Why put a personal signature on your WordPress blog?” and got a listing of various plugins and how to edit functions.php files that do this stuff. But no one explained why post signatures are a good idea.

https://wordpress.org/plugins/wp-post-signature/
156k download, Requires: 3.0 or higher, Compatible up to: 4.1.11, Last Updated: 1 year ago, Active Installs: 3,000+
Comments:
The screenshot of the controls looked overwhelming. It wasn’t clear if an image file is included or if it’s just text.

https://wordpress.org/plugins/sxss-signature/
179k download, Requires: 2.5 or higher, Compatible up to: 4.4.3, Last Updated: 3 months ago, Active Installs: 800+
Comments:
Has integration of TinyMCE. This allows the addition of copyright, links, images, or ads at the bottom of pages or posts.

https://wordpress.org/plugins/danixland-author-signature/
41k, Requires: 4.0 or higher, Compatible up to: 4.5.2, Last Updated: 2 months ago, Active Installs: 20+
Comments:
This plugin is brand new for 2016. The author said, “All I wanted was to be able to select an image for my user, and set the alignment and size for the displayed image inside the blog post.” He felt the other plugin offerings were too bloated. We agree. To add your signature image, go to your profile page in the WordPress dashboard and, at the bottom, you’ll find a new section for selecting an image using the standard WordPress media upload screen.

https://wordpress.org/plugins/ft-signature-manager/
4k, Requires: 2.5 or higherCompatible up to: 3.5.2, Last Updated: 3 years ago, Active Installs: 1,000+
Comment:
Appears old, abandoned and suspicious of calling offsite resource. It’s too small of file size. Did you ever think you’d hear us say that?) Too scary to use.

https://wordpress.org/plugins/dt-author-box/
69k, Requires: 3.1.2 or higher, Compatible up to: 3.6.1, Last Updated: 3 years ago, Active Installs: 1,000+
Comments:
From the WordPress plugins site: “for those who have multiple authors on a WordPress site and want to show author information at the bottom of every post for each author like a signature. This can include an image, a short bio, a link to the author’s website and their social profiles.” This is overkill for us.

Based on this quick information, the plugin to use seemed pretty obvious: Danix Author Signature. It was fast and easy and didn’t add any drag to our page loads.

author-signature-header
https://wordpress.org/plugins/danixland-author-signature/

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 http://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.

Speed optimization for mobile WordPress websites is our specialty.

Your plugin choices affect website speed. But how much plugins affect load time varies from a thousandth of a second – to seconds. A page load time of under 2 seconds is our goal. Half our performance budget is for a theme and plugins. It also includes cloud-based, widgets like Google Analytics, Google Fonts, and Facebook. The other one-second is for branding the site with images.

It’s a common myth that installing too many plugins slows down your site. It isn’t the quantity of plugins that matter – it’s the quality.

The WordPress Plugin Directory now has over 55,000 plugins to choose from. In error, many site owners think the most popular plugins are the wisest choice. This isn’t always true. In fact, from our testing the most-liked plugins are often the slowest loading plugins.

The number of active installs indicates “herd” popularity. The plugin download page tell us what this number is. Or you can click the View Details link on your WordPress dashboard page.

We have many choices of free WordPress plugins that add unique and sometimes esoteric functions. Our rule of thumb is selecting the plugin with the smallest-download package size. The compressed file size is in “k” (kilobytes) or in some cases, “M” (megabytes).

It’s best practice to add functionality into your theme using several small plugins. One fat Swiss-army knife plugin can cause what we call “site drag” – adding delays to your site. Some plugins add drag globally to your entire site even when they’re just used on one page.

For example, Contact Form 7 plugin has over a million installs. Site owners don’t realize this plugin adds three HTTP requests. And 28k page weight to every page on your site – yes, every single page. Even if the shortcode is only used on your contact page – or even not used at all. That may sound small – but in our book, where milliseconds add up to seconds, it isn’t.

For an unknown reason, WordPress doesn’t give compressed plugin size information. You don’t see this number until you actually download from your browser. A proper link would tell the size of a download. That’s good “web etiquette.” WordPress doesn’t think it’s important information (yet). Speed information isn’t high on their agenda. But it is on ours. Any site owner concerned about mobile user experience should pay attention.

When optimizing in a staging area, most online speed tools can’t access these test spaces. So we’ve build prototype pages offsite with the exact same plugins and theme. This helps us establish speed opportunities and pitfalls.

One site under test has 33 active plugins. A few of these plugins improve load time and site optimization. Others add functionality to a responsive, fast-loading theme. Others are for better security. In this case, the theme is “Accelerate.” It’s available at the free WordPress Theme Directory. Most of the default WordPress themes like Twenty-sixteen and Twenty-seventeen are fast loading. Others need speed testing.

Page load time with 33 plugins:
Pingdom to NY: 750 milliseconds.
WebPagetest.org: 1 second.

Tested on a cheap, shared, Linux server.

Learn More Plugin Speed Tricks

WordPress secretly grows your manual image optimization making image files slower for mobile speed.

That’s right. WordPress undoes your manual image optimization efforts. We use an offline image processor like Gimp or Photoshop for manual image production and optimization.

Few discover this hidden truth about WordPress automated image editing. It’s has an odd and strange ability to increase image files size slowing down speed. It only occurs if you use their photo editor to crop images. When it asks you to crop – “skip” it. That’s usually a better choice if the image is already sized. Uploaded originals are untouched when placed in the media library – unless you resize or crop such as an image thumbnail. Then things grow. Why? Who knows? WordPress looks the other way about this unreported speed problem.

Plainly, this upsizing strangeness isn’t a problem for most site owners or visitors. They don’t care. Otherwise, there would be millions screaming for a bug fix.

GIF is not an acceptable format for photos. JPEG is the better choice.

When you upload an image to the media library, WordPress core builds many mobile-size images for swapping on the fly. This is an attempt at a responsive mobile speed solution.

You as a site owner care more about image quality than the majority of your site users do. Image quality is way down the visitor-frustration list. Not significant. The number one complaint is slow loading pages being “the worst experience of a user’s day.”

Is Retina screen resolution important? There’s almost 1 billion active users of iPhone. And there are an estimated 300 million second-hand iPhone in use.

Retina display is a marketing term invented by Apple. Their primary goal is reducing eye strain when users read small type. Not improving image quality – a fortunate byproduct. It’s all about font-type readability.

There exist circumstances where images must be uncompromising. One is on portfolio sites. The other is with photography showing important product details. Both are instances where you’re selling something that depends upon good image representation. Images then are more important for buyer decision making. Product photo quality affects web profits. In all other cases, users aren’t discerning or are forgiving. They’d rather you build for speed and compromise in the image quality department.

Are you selling something on your site?

If you’re not selling, visitors only need to recognize what the color blob is. That is it. The caption is more important to users than photo quality. But often site owners neglect to use captions for better communications.

Building for Retina images is an exercise in futility.

When you *must* build for high-resolution Retina displays, there’s a superior way. Please read the article linked below. Remember to keep web goals in perspective. Some things don’t matter. Most web browsing today is on mobile devices. But mobile visitor expectation is low in many regards for type-font and image design. That doesn’t mean you’re justified in delivering garbage. But major image effort often has a puny return on investment.

REFERENCE: pagepipe.com/how-to-show-high-resolution-portfolio-images-on-mobile-screens/

In this article above, we recommend WP Retina 2X plugin. Try it. Test it. But only if Retina-screen compliance is critical.

This novel plugin creates many new alternate high-resolution versions of your images. Another plugin feature is automatic detection of Retina displays. It then loads the high-resolution version of an image rather than the regular one.

WP Retina 2x serves up src-set images which pull smaller sized images off the server – and theoretically decrease bandwidth. – Ian Rance

Only 4 percent of site owners who install WP Retina 2X keep it. That’s a low-retention rate. It wasn’t worth the Retina-resolution hassle even when this plugin made image decisions and production painless. So there’s lots of variable screen sizes. Big deal. Retina-image preparation does NOT have widespread adoption by web designers or developers. It’s perceived a production annoyance (or non-feature) delaying site launch – and project payment.

These three offsite links below may help you make decisions. You have a design choice. You can workaround or ignore Apple-mandated techno-specs. We won’t tell.

https://mediag.com/blog/popular-screen-resolutions-designing-for-all/

https://deviceatlas.com/blog/most-used-smartphone-screen-resolutions

http://screensiz.es/phone

For PagePipe’s site, the strategy is not using photography for large headers. We choose the alternative of building custom illustrations for reduced load-time speed. That means using 8-bit GIF and PNG with 2,000×1200 pixel images with reduced color palettes. Those files weigh just over 21 kilobytes.

Where we use featured JPEGs, they weigh under 200 kilobytes. It’s fortunate the big “hero” image is lazy loaded by the default theme.

But the fastest sites on earth have no images. Only a small number of site owners make that choice (about 10 percent).

PagePipe screengrabs are JPEGs. They’re optimized harder than WordPress recommends. WordPress saves images at a compression of 82 – which is the equal to a Photoshop 50. Why is this important? It makes the images pass the WebPagetest.org criteria – a real speed test owned by Google. It’s most used by professional performance engineers. Not Google PageSpeed Insights for commoners. PageSpeed insights doesn’t even measure page speed in milliseconds. It only produces a weird score. They let you kill yourself for a meaningless 100 A+ while your site still remains a slug.

pagepipe.com/quality-82-image-compression-change-for-wordpress/

We build all JPEG images to screen dimensions. We optimize offline with a 70-quality setting (or more when we can). We use free GIMP image processor. We avoid cropping online with WordPress. We save-for-web our 8-bit PNGs and GIFs with reduced color palettes.

We’ve only had one client request Retina-quality images. That’s Steve’s brother, Brad Teare. High-end art galleries using fiber-optic connections were his target market. Speed was a nonissue. But we built the portfolio for both large screen and small screen,  just in case. The galleries asked how he pulled it off. A great compliment. People’s curiosity sparks a speed question, “How did you do that cool magic trick?”

When we have a choice, we choose ignoring Retina specifications. And Retina’s been around for awhile. We may change our policy in the future. But we doubt it.

An unconventional optimization example.

The PagePipe “Start Here” page contains an animated GIF. It isn’t built to the recommended spec of 2000×1200 pixel dimension. Instead, it’s 1132×697 pixels. We let the browser stretch with math and mess with this image. This is bad practice. Dimension recalculation causes small speed delays. So why do it? Because not doing so would produce an even worse super-slow page. Abandoned by users clicking the back button.

We also ran the animated GIF through an online compressor squeezing it’s file size way down. This introduced tons of noise and artifacts into the animation. Do we care? No. Because it’s good enough for average users. It’s noticed by inspector-type personalities. But 80 percent of visitors (or more) are oblivious and unaware of best design practices.

Being perfect in-every-way has too high of cost in time and money. “How good is good enough” is a hard judgment call. Relax your tolerances and standard so you can work on what counts most.

RELATED PAGEPIPE ARTICLES

When speed won’t make any difference in your mobile SEO.

One of the biggest decisions is deciding what to not sell, who not to sell to, and what not to promise. Telling people who you’re not is just as important as telling them who you are.

You must have something of value to sell. This is called the value offer for other people. This is about some pain or anxiety visitors are trying to resolve. This is their motivation.

Creative positioning strategy is a short cut to buyer’s motivation.

An offer includes terms, warranty, delivery, price, incentives and more.

People won’t be instantly convinced you’re a credible source. Web visitors are suspicious of every website.

In Google-speak, motivation is “intent” or “relevance.” Search engines attempt to rank the content of your site for intent, relevance or credibility.

Relevance is often determined by how many people searching for a key phrase go to your site (click-thru).

So. Why aren’t you getting traffic? First, look at your first-page Google listing competitors. They’re big companies with tons of articles, authority and credibility. You have to outperform them.

Does your site appear on the first 20 pages of Google for your preferred search term. Or after ten pages do you still have nothing? Focus on what matters most to people (relevant topic).

If 33 percent of your blog traffic is funneling through an unrelated topic page, these people have no intention of buying services or products.  We recommend monetizing the page with a relevant paid download – or spin it off as a separate website – or else get rid of it.

Why get rid of a page creating 10,000 visitors a month? Because they aren’t qualified leads. It’s causing noise or dilution. Content pollution.

What’s a qualified lead?

A qualified lead (visitor) has money (budget), authority to buy, is ready to buy (timing), has the problem you can solve (need).

If a site bounce rate is 80 percent, those are people who don’t care and leave immediately. While we’ve seen worse, that isn’t goodness. Only 20 percent of people visiting stay and read something. The most they’ll read is a partial article. 80 percent leave instantly.

Maintaining an email list may not improve business profits. Selling an Amazon book may not increase business profits. They do increase “credibility” but they don’t increase profits.

Credibility consists of three components: trustworthiness, expertise, and enthusiasm. Credibility influences people or persuades them you can deliver what you promise. Remember they’re suspicious of all websites, not just yours.

Content is the user experience. What helps convince visitors you’re credible is how much content you’ve written related to solving their problem. That’s an “authority” goal of 50 articles. But if the articles don’t help them and are just fluffy, they won’t be convinced. “Fluffy” is referred to as thin content by Google. When you give away valuable information, visitors (and Google) are more prone to trust you more. The trust less if you charge for every little thing.

We dump 30 percent of PagePipe’s technical content each year. Typically the 30 to 40 least popular articles. Why? We revisit our core pages, homepage, etc. and improve how well they target our specific audience. We don’t want to dilute our best content with thin content. That makes it hard for people to decide what to read.

Our goal is selling:

  1. DIY ebooks.
  2. speed services.
  3. rebuild websites.

Our break even is incredibly low. We don’t use any paid plugins or themes and we host on a cheap, shared server ($70 to  $95 per year) with no paid services like CDN. We don’t advertise or monetize.

If you have no enthusiasm for your site topic, people will know. They will be unconvinced you’ll improve their life.

Will you produce valuable content for your audience? That’s more important than speed.

Mobile image optimization.


Image credit: Pixabay

Your Guide to Image Speed Optimization On Mobile

Have you been told you need to optimize your images for mobile? Worried that slow load times, or a bad mobile UX are hindering your sales and conversions? Here are some truths about optimizing your images for mobile — as well as some actionable tips and advice on how to make your mobile site perform better.

Compression & re-sizing is key

One of the most important thing you need to do to your images? Compress and resize them. This will not ruin the picture, as long as you strike a balance between file size and visual quality.

Compression helps improve website performance and speed because it essentially makes image file sizes smaller. Using a plugin like ShortPixel means you can retrofit your image library, even if you didn’t do anything to them when you first uploaded them.

Resizing is just as, if not more, essential than compression. Digital cameras often, very unhelpfully, create images that are very large. Take the pixels down and resize images down to a more reasonable size using a plug in like Imsanity (featured in our review here). Imsanity is actually also a viable (free) alternative to ShortPixel that is limited in its free version.

Image resizing is especially key on mobile — even though modern smartphones are powerful computers in their own right, large images that fill the screen will slow the mobile experience down. You may want to include less images across the board so as to not unnecessarily slow the user down.

Use (trusted) image optimizers

You can optimize pictures for web use by compressing them using Photoshop (not that tricky to do yourself), or you can use some trusted image optimizers that will help you scale the process.

The problem with image optimizers? A lot of them don’t work, and it can be hard to find the best in a bad bunch.

Luckily for you, we’ve gone ahead and tested them against some pretty tough (but fair) criteria. Here are some trusted ones that made the grade.

Ditch the extra plugin bloat

Got an image speed problem? There’s a plugin for that… Or is there?

Don’t jump off the cliff with other lemmings and immediately download fifteen ‘image optimization’ plugins — you will only end up bloating your site’s backend with unnecessary plugins. Third-party plugins are notorious for slowing sites down, and can be a security risk for cyber attacks like SQL injections.

You will also find that one bad-quality plugin can do the damage of a dozen. Bad plugins can actually load down every page on your site (site drag). Slightly counterintuitively, the more popular a plugin, the worse it may actually be for your site! It’s not about quantity — but about quality.

Not sure if a plugin is worth it? Always read plugin reviews, and check how the number of downloads compares with the number of active installs. You want plugins that have good retention rates — it shows they have longevity. Don’t be afraid to install older plugins — they can be pretty reliable, even if they’re not updated as frequently. (Though updates are a good sign — it shows a developer who cares about their product).

Choose the core plugins that you need, always keep them updated, and disable any old ones.

Don’t blindly trust tools

Automated speed tests are notoriously unreliable, and have been exploited by SEOs and digital agencies wanting to sell their digital services off the back of a ‘bad result’. This is often an elaborate hoax to get people to worry about their rankings and invest in SEO.

Everyone’s experience of the internet is vastly different, and few speed tests are able to accurately reflect device experience. So take their findings with a pinch of salt, and focus on the basics:

  1. Good hosting
  2. Compressed images
  3. Well pruned code and CSS files
  4. Essential plugins and features only.

Random spot-checks and usability testing are great ways of finding out more about your mobile experience.

User perception

Too often we forget that websites are the products of layered illusions — and it’s the user’s perception of what’s going on that really matters. This quote from Lora says it all:

“The perception of how fast your website loads is more important than how long it actually takes to load. User perception of speed will be based on how quickly they start to see content render on the page, how quickly it becomes interactive, and how smoothly the site scrolls.” – Designing with Performance by Lora Hogan, p19

Don’t just focus on speed insights that come from tools and backend code — focus on speed in-action. What the user sees is what matters, so focus any speed testing around their experience of the site.

Consider image UX

Come at your ‘image speed problem’ from a different angle, and ditch the images all together! Consider whether they were really needed in the first place.

Take the following three questions into account:

  • Is the image interrupting, rather than contributing to, the user journey?
  • Are images really adding value here?
  • Are the images making the site less, or more, accessible?

Modern designs often push big featured images and hero size images on us; but if they don’t actually achieve a tangible aim: what is the point? Many information blogs that focus purely on copy may not need them at all!

Try to avoid using huge ‘filler’ images on your mobile site — being concise with your imagery is far more important.

Ecommerce product images

When it comes to the sales funnel, product photography is key. So how can you ensure that product images are doing a good job of selling your products, without slowing your site down? A customer doing product research on their mobile isn’t going to thank you (or make a purchase) if the site won’t load.

  • Create product images in-house so that you can control the process, and don’t overdo photography for the sake of photography
  • Images don’t need to have loads of details and props — they can be simple and beautiful
  • The infinite scroll is often favored by users when they’re looking through a product catalogue fast — stick to small image thumbnails to enable this
  • Carousels are bad for conversions, not favored by users, and they look terrible on mobile. Try to avoid pointlessly rotating image carousels (but if you have to — go with these ones). And avoid them on the home page if you can…

Don’t lose sight of the bigger picture!

Yes, speed 100% matters, but don’t just focus on speed and forget about all the other crucial elements that go into a good website, like:

  • Usability
  • Coherence
  • Purpose
  • Accessibility
  • Aesthetics.

Speed is often a by-product of good web development and a good content management system that’s been properly managed and maintained. Don’t neglect ANY areas of your website if you want to make the most of it.

You need to be looking at the user journey, sales funnel, and the experience of using your pages — not just what the speed test tells you. Your users are the best judges of your website — so listen to them.


Victoria Greene is a content strategist and freelance writer, blogging at Victoriaecommerce. She’s proud to say that she’s built a few websites in her time, picking up a thing or two on good and bad web design on the way.

What to ignore in Pingdom and WebPageTest’s free speed testing.

Never trust speed test scores. Ever. Always measure improvement in milliseconds of load time.

How to interpret pingdom.com and webpagetest.org speed test results.

Definitions:

First byte or Time to First Byte (TTFB) – Delay between the first HTTP request from the web browser and the reception of the first byte of the web page by the browser. It’s recommended a time less than 200 ms. It’s a server delay. You can’t fix TTFB except by changing hosts or upgrading services. $$$

Load time – The web page is fully loaded, all the resources are fetched, parsed and executed. Pages must loaded within 4 seconds. We always shoot for 2 seconds but under 1 seconds loads gives us goosebumps. At 10 seconds, people are long gone.

Page size – The total size of assets loaded: CSS, JS, HTML + other (like scripts, images, ads, etc) Also called page weight and is expressed in “k” or “M” bytes.

Page score – The score calculated based on a number of factors: compression of the resources, enable/disable caching, CSS/HTML/JS minifying etc. Score is irrelevant.

UNDER 9-minute video:
https://www.sitepoint.com/video-understanding-webpagetest-org/

And this link helps:

Pingdom.com is for quick-and-dirty best-case scenarios. First test is unprimed cache and second test (click again) is primed (faster).

WebPagetest.org is for worst-case scenarios. It’s more reliable but takes longer to test.

Never evaluate with Google PageSpeed Insights. WordPress can’t pass their criteria. Google doesn’t even use that data for ranking anyway. They have people chasing their tails.

We code HTML, CSS, mess up PHP, and do zero Javascript, but PagePipe focuses on solving WordPress problems with non-coding solutions. In other words, strategy using plugins and themes. Not hacking PHP or .htaccess files. “No coding skills needed” is what WordPress is all about. We give plug-and-play features preference. No plugin settings? Great!

Most site owners and developers just don’t test plugins. They rely on popularity numbers. Moo! Herd mentality.

For example, iThemes Security and WordFence are both popular security plugins. That’s an immediate red flag that they’re slow. Why? It’s crazy. But the speed results for popular plugins always turn out slow in tests. Same for themes. People just go for the heavy plugins loaded with the most features. Overkill. The herd starts following the path thinking active installs must mean goodness. Nope.

Researching plugins on the 52,000 plugin directory is difficult and tedious. We’ll keep researching and testing plugins and themes for improving speed benefits for your sites.

The downside of paid, *premium* plugins.

PagePipe’s goal was adding various full-width images to our catalog page near the top. Not only the column width like with many sliders. We were testing how to put a slider in the featured-image slot. A paid slider plugin didn’t work as promised. After an update – the plugin author couldn’t upload the plugin via WordPress. They wanted either FTP or Cpanel access. We told them, “No way!”

The plugin company then issued us an expiring store credit. We told them that wasn’t good enough. We requested a reimbursement. We told the number of annual visitors we get on PagePipe. We said we’d be reporting our experience. We then got same-day reimbursement. We figured if they could rob us – we could blackmail them. Fair is fair. If you want to know who they are, email us.

Using heavy sliders (and light ones, too) on the home page are a disadvantage. They hog bandwidth and distract precious visitor attention. Appropriate slider usability is not a loss when applied on subpages. You must use selective activation to prevent site drag. If full of irrelevant stock images, you’ve done your site a disservice.

Web assets must add value or have purpose. Adding frivolous assets causing site drag (global loading) is nonsensical.

What’s appropriate slider usage? One good use is displaying a portfolio or a range of product images without links. Or a short, three-panel story is another. And then only if it *feels* right for UX. No links. No hover stops. Fades are best. Nothing whizzing, exploding, rotating, or hurried.

The goal is subtle implication there’s more than one product offering. You need a cue at the page top when the catalog content is much further down. It’s not a solo product page. It’s a catalog page. The slider is for page differentiation and visual cuing. The slider should not contain all product images. Only a representative sample to keep things light.

Usually it’s best not to use sliders for navigation. They aren’t effective (read reference). But we’ve put sliders on many sites for presentation. Even home pages. Why? For the same reason most do it: the client demanded it – and they write the checks. But we also insist the owner dump something to compensate for the extra slider weight. Something heavy like Facebook real-time counters – or a YouTube video – or Google Maps. It’s a negotiated speed deal.

Sliders are NOT dumb and evil. It’s how they’re used in design and communication methods. Site owners are often unaware of the global speed infraction.

Large images are dramatic and people like to look at pictures. Adding large images is deliberate for better UX. But where and when they should appear is the important question and how much they weigh. Is the home page sacred ground? Yes. Don’t bloat it. Build for for fastest page loads. But not always. Some sites get more traffic through other landing pages than the home page. If that’s the case, avoid sliders on those pages.

The inclination is putting the slider on your gateway page. Bad form!

Readable interesting text is always most important – not images. People want to read good text that solves a problem for them. Even if the problem is boredom. With a good picture, they still want something to read to understand why the picture is there. They want words. Even with art: a caption or title does wonders.

We made a moronic and impulsive $25-dollar slider-plugin buy. We got duped and had major buyers remorse. We got a refund only because we’re a technology publisher. We’ll never buy another plugin or theme again (maybe?). We learned a valuable lesson about paid-and-premium offers. Later, we found a free slider plugin (Master Slider).

Is Master Slider a *special* slider? No. (How they can advertise a slider as being SEO-friendly is beyond our understanding!) It’s what it doesn’t do that we like most. It doesn’t cause unnecessary page bloat. It adds 6 calls to the page.  We can live with that. Lots of slider plugins do that. We wanted to test drive this one.

The real kicker for speed is optimizing and limiting the number of images. For example, we intentionally compromised on slider image quality. Four images used (out of a dozen). They’re reduced to half the size – 991×595 pixels. The other large solo header images are 2000×1200 pixels (retina) recommended default size. The smaller slider images then dynamically-resize to fill the full-page width. There’s deliberate visual loss. The low-tech versions weigh around 40k to 80k. The large featured images on individual product pages vary from 150k to 250k.

Face it. Quality on moving images is a low-priority.

The final catalog page weight is 420k with 45 requests. Time to Europe on Pingdom, 1.84 seconds. to Australia, 1.7 seconds. We aren’t using minification on this page because it breaks the ecommerce features. That happens even with paid Woo-commerce. We’re using free Easy Digital Downloads plugin.

We’ll never succumb to purchase temptations again. Lesson learned. Until next time, anyway.

During these experiments, we realized the dangers of Twenty-seventeen Home featured image. It’s added via the customizer. This causes image loading on every single page and post. Even if it’s not visible (suppressed by CSS code). It’s still loaded on the backend. The original image was around 200k. So we tried coding solutions to defeat loading on any page but Home – to no avail. We then decided to junk the featured image. We added CSS code to color the background and added back our rocket logo. That workaround proved simpler and faster for speed.

We recommend using discrete free plugins to build site features.

How *good* is good enough for productive page speed?

How could we resist a list of select WordPress websites reported as “cool” – as in neat-o or spiffy? They described 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 the websites were done with WordPress. Oops! They note these errors 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. The Chrome browser extension equivalent is Page load time. As soon as you access a page, you’ll see the load time in the Firefox browser status bar. Is it a more scientific measurement? Not really. But it’s better than nothing and fast. We didn’t want to wait in line at Pingdom.com or WebPagetest.org.

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:

response-time
Viewer expectation of page load time.

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 often achievable on the web under excellent and pricey hosting conditions. Or use cheaper speed strategy and build a fast site – even on shared hosting.

A one-second page load, or page change when clicked, yields a seamless flow of thought. This meets an ideal criterion 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 die hard 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. Especially for Google’s mobile-first indexing. 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.”

Google’s hypocritical policies affecting mobile speed.

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.

READ more PagePipe: Fast sites don’t improve Google page rank

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:

READ more PagePipe: HTTPS / SSL and its negative impact on mobile speed.

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.

READ more PagePipe:  Why Google AMP is not the ultimate solution for mobile WordPress speed.

Are we done raking Google over the coals. No. We need to talk about Google PageSpeed Insights.

We don’t recommend Google’s PageSpeed Insight tools for mobile website benchmarking. Or even for desktop. We avoid this tool.

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.

READ more PagePipe: Google PageSpeed Hypocrisy

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.

BONUS BASH – Google Analytics isn’t good for speed either. Read our article: How does Google Analytics affect mobile page speed?

WPmudev uses deliberate speed bait to sell theme memberships.

Be forewarned, the blog post we review here is deliberate bait to sell wpmudev theme memberships. It’s the flawed article: 15 Great Mobile First WordPress Themes to Boost Your Site Performance by  Rachel McCollin. First published in 2016 but still relevant to what we teach about speed.

We found one potential winner in the bunch.

The first theme presented is one of wpmudev’s themes called “Upfront.” But you must be a paid member to download it. We don’t use paid themes. So it’s instantly off our evaluation list. All other themes on the reviewed blog page are free and available from the free WordPress Theme Directory.

We’re searching for web-speed treasure.
The article claims to focus only on theme’s with excellent site performance. As you will see, many of the WordPress themes recommended don’t match our selection methods or guidelines.

Page load time (speed) is especially critical for small-screen mobile websites. That’s because mobile must connect using slower, wireless bandwidths. Today, mobile websites are built using responsive WordPress themes. Responsive means the page content resizes to fit any screen – whether it be on a smartphone, tablet, or desktop. Old websites just for desktop viewing were built with fixed-width pages. That method no longer is in vogue.

We’ve found theme download file size is a big indicator of speed potential. A theme download file below 1M is most apt to create web pages loading in under 2 seconds. This delay is the longest site viewers are willing to wait without feeling frustrated, impatient, or bored. Load time affects the user experience (UX).

Let’s make a quick check of the suggested theme list.
How many match our speed criteria of being under a 1M zip file download? Remember that’s our quick, rule-of-thumb for selections. Fast WordPress sites load in under 2 seconds on cheap, shared hosting. Read more about our theme testing for under 1-second load times >

SUMMARY

Of the 15 recommended themes, only 7 might be fast. Only one speed theme is of particular interest – and we find it a great discovery. Who knows? Perhaps, the treasure we seek.

Comparison of download file weights (smallest first):

Winners
Graphy 356k
Twenty Sixteen 603k
Daniela 628k
Veggie Lite 682k
Silk Lite 787k
Altitude Lite 907k
Responsive 1M

Losers
Binge 1.1M
Responsive Mobile 1.4M
Sydney 2M
evolve 3.6M
Flower 4.6M

 

At 356k download, the Graphy theme has by far the greatest potential for a fast-loading WordPress theme. As an extra bonus, Graphy has nice, readable typography. Custom, non-browser-default fonts usually are not a speed asset. Only further testing will tell. The text font stack is: Lora, Georgia, serif. And the header font stack is: Bitter, Georgia, serif. Bitter is a slab serif font. These must be called from Google’s cloud font library. Font calls create delays.

We find that Graphy including Lora and Bitter fonts adds about 700 milliseconds to the load time. That is almost one-third of our performance budget. If we add images, it may be necessary to switch off the fonts with Remove Google Fonts References plugin.

The download file decompresses to 581.1k. This is quite small. We find that 161.4k of the file is a screengrab. This will not affect load time. Neither will the 142.3k of languages translation files. But we do see one speed offender we don’t like: Genericons.

We consider theme use of Genericons dead weight.
Genericons is 174.2k of the theme file size. How much drag is added depends upon how Genericons are used. Some themes activate Genericons HTTP requests (calls) even when the icon font isn’t even on any page. So further testing will reveal the cost of the theme author’s choice.

We do notice that Graphy uses an image icon instead of a Genericon for it’s ubiquitous, top-right search field – a magnifying glass icon. This is a good sign. It means it doesn’t call the heavier Genericon equivalent. Genericons may not be activated at all if not used by the site owner.

Sadly, Genericons in Graphy theme add about 35k to 45k page weight. No icons are shown on the page. That means we could deactivate it without any repercussions.

Graphy includes some nice customization features.
Graphy theme has an optional widgeted sidebar and 4 footer widgets. If the sidebar widget isn’t used the theme is single-column, full-width.

The footer width (columns) is automatically adjusted depending on how many footer widgets are used. If you do not use any, none will be displayed.

The theme has a few other extras not usually included in stripped-down, fast themes. You can upload an image logo. This logo can replace the site title and you can add border radius for spacing. You can also specify the link color and a second hover color.

Additionally, you can choose to display summary text – or alternatively, full text for posts. You can also hide or show the author or category. These selections are made with check boxes.

You can add a single custom header image.

Only one custom menu is available. That limit is only a minor negative.

Don’t trust WPmudev theme recommendations for speed.

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.

Which shared-server speed is worse? GoDaddy or Bluehost?

“Worst Web Hosting Companies” yields 16 million Google search results. Ironically, review sites not only tell you who they think are the worst – but then advertise acclaimed best hosting with affiliate links.

Those affiliate links pay kickbacks up to $100 – if a sale is made. Sweet! Let’s all put affiliate links on our sites – and get rich.

Maybe not.

Affiliate links often use link cloaking. Read more about that ploy (and speed) here. We think link cloaking is deceptive. It masks or hides where users are taken when selecting links.

There are no affiliate links on PagePipe. Hallelujah!

Be aware, any blog post recommending hosting – and free critiques – almost always makes affiliate money. So they’re biased or manipulative.

So what?

Despite the low credibility of review sites, we’re confident the negative reports of bad, lame hosts is mostly true. There’s commonality in the results. The worst-ranked hosts vary in list placement – but it’s usually the same hosts. Two are widely dispised and claimed to be THE worst: GoDaddy and Bluehost.

It doesn’t matter about technical reality. Being perceived as the worst  by many is sufficient judgement. [Note – We don’t think they’re that bad.]

Because we do NOT follow the herd, we deliberately selected GoDaddy for PagePipe’s hosting. Our goal is proving  origin-optimization efficiency. You can achieve fast speeds even on the worst cheap, shared hosting. Use discipline and care in your site design. We teach you how on PagePipe.

Economy hosts take in the unwashed masses. They appeal to some of the worst-case, non-technical users – the ones with no money and no training. And so these cheap hosts get bad reviews. That hasn’t slowed down their growth one iota.

We abhor their marketing ploys and lies to maximize profits. But this article isn’t about up-selling, bait-and-switch, or duping uneducated victims. We write about speed – not recommendations for hosting companies.

GoDaddy Inc. is a web-hosting company headquartered in Scottsdale, Arizona, USA. GoDaddy has around 8.5 million customers. Their annual net income is around 2 BILLION dollars. They clear 6-percent profit on those sales ($140 million approximately). They’re the biggest web host.

Bluehost is a web-hosting company owned by Endurance International Group. It’s one of the 20 largest web hosts. Bluehost hosts 1,248,507 websites on economy, shared servers. The company operates its servers in Provo, Utah, USA.

Why are we mentioning Bluehost since PagePipe is hosted on GoDaddy?

PayPal changed how it interacts with Easy Digital Downloads ecommerce plugin. This forced us to use HTTPS/SSL certification on our site store. Not for Google ranking – rather for the requirements of successful PayPal transactions. PayPal changed it’s rules in July 2018. I took us a while to figure out why automated ebook deliveries were failing. We got our money but customers didn’t get their ebooks for awhile. SSL compliance fixed the failures.

SSL adds 500 milliseconds of server handshaking to every page and post of your website. That’s 25 percent of our performance budget.

We use a 2-second performance budget. Adding SSL ruined our page load times. We use a speed trick of “offloading” the store using a separate GoDaddy domain on the same server. That domain name was secure-pagepipe-store.com. (Yeah. That domain tidbit is important later in our horror story.)

Originally, we tried GoDaddy’s expensive SSL certificate.

Next, we got a GoDaddy SSL refund and switched to Let’s Encrypt’s free SSL certificate.

This hassle wasn’t fun. But we were determined to figure things out. And we did it – eventually. Because of our curiosity, we ended up reloading and rebuilding our site several times. Why would we inflict so much pain on ourselves when SSL is free at other hosts?

We’re determined to stick with GoDaddy. The pain.

It’s notorious. GoDaddy cheap, shared hosting proves our point. You can get fast speeds even under the worst conditions. But not if you injudiciously throw SSL on your site. You must use speed strategy – or spend money.

Bad news. SSL overhead can’t be cached. We choose not spending money – and using creativity for speed instead. In this case, it meant dividing the site.

You may wonder if site-splitting is self-defeating behavior. In this case, it’s not. The assumption is you lose caching speed benefits when you switch users to the sister store site. One secure and one unsecure (insecure?) site. But BONUS, we can’t use caching with Easy Digital Download ecommerce pages anyway. Caching and minification mess up the EDD plugin functions.

PagePipe has very few store pages compared to many blog posts. Most people enter our site from organic search via the blog posts. They then wander the site reading other content – and ultimately visiting the store. The store is rarely the landing pages.

This division into two sites meant we successfully maintained minification and caching plug complications on the biggest site. And it’s at our front door (our blog) where speed expectation is highest. By the time someone enters the store, they’re curiosity is often high enough to endure a longer wait. In this new case, no waiting was required.

We stupidly wondered, “What would happen if we let our SSL certificate expire?”

We decided, “Let the 90-day period run out.”

Bad choice.

It was a nightmare. The needed GoDaddy server changes in the Cpanel SSL settings were obscure at best. The store was down during prime time: a Friday night and Saturday morning because of our repeated fumbling.

We got our “Welcome to Bluehost” email at 4:33 pm Pacific time Friday. They immediately started email spamming us to buy more web stuff.

At 4:51 pm Friday, Bluehost billing department deactivated our account. Suspended forever.

Why? They didn’t like the word “Secure” in the domain name. It was too “spammy.” They said we had to provide approved proof of government identification to restore the site.

Hmm? GoDaddy never cared about our domain name of “secure-pagepipe-store.com.” Why did Bluehost care? Different standards – we guess.

Undeterred, we setup a new Bluehost account for another $59 with the domain name “PagePipe-ebooks.com” We’re getting good at this now – no spam judgement call – and got the store working again in short order. Wonderfully, we never touched the blog with all this buffoonery.

We migrated the store one more time. It’s working now and with free SSL. Whew.

And now we don’t have to worry about 90-day expiration or renewals any more.

Bluehost over charged us about 72 dollars on secure-store-pagepipe.com during registration. We’re working to get the money back plus the $59 hosting fee. We’ll see if we just ate $136 dollars learning from an unfortunate web experiment (mistake?). The cost of our education! We deselected all those silly Bluehost registration options and still got billed for them anyway. You know, those ridiculous opt-out features including:

Codeguard Basic – $35.88 annually.
SiteLock Security – $23.88 annually.
Domain Privacy Protection -$11.88 (secure-store-pagepipe.com) annually.
Tax – $4.66
PagePipe was billed: $135.70 total. Bluehost notified us the next Wednesday by email the hosting plan was cancelled and a refund issued. But to allow 7 to 10 days for processing.

So why in the world are we leaving our store on Bluehost? To prove we can take a ruthless beating. And still produce a fast site on cruddy hosting even after being treated like garbage.

Why did we use Bluehost when we could have bought a 1-year certificate from GoDaddy for $70 dollars? Well. It’s the value of speed. We’d die for good speed. It’s all about speed achievement in unconventional ways. We want to learn why things work the way they do – and then find a better alternative.

So today, the new PagePipe-store with SSL loads times are:

International Load Times, No CDN

PagePipe Blog start-here page
http://pagepipe.com/best-page-speed-starter-resources/
424.6k page weight, 25 requests

Pingdom to San Francisco
1.43 seconds
load time

Pingdom to Frankfurt
3.27 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 homepage
https://pagepipe-ebooks.com/

No CDN, no minification, no caching. BlueHost
421.8k page weight, 35 requests

Pingdom to San Francisco
1.32 seconds
load time

Pingdom to Frankfurt
1.75 seconds
load time

Pingdom to London

1.79 seconds load time

Pingdom to Sao Paulo, Brazil
2.44 seconds load time

Pingdom to Tokyo
2.51 seconds load time

Pingdom to Sydney
2.95 seconds load time


WP Engine is frequently recommended on blogs as the “Best Premium Shared Hosting for Advanced Bloggers.” Of course, blog authors sharing *trade secrets* get an affiliate-link kickback or commission. They make money touting others hosting services. No source credibility.

Many error thinking WP Engine must be better or even the best. It costs a lot. It’s recommended so often. They must be good because they have a good reputation, right?

That “feel-good” hosting is $420 per year. Yet, it’s the exact same terrible-speed quality you’d get elsewhere on cheap, shared hosting. For $5 (or less) month-to-month rent – only $60 annually – you’ll get the same perfectly-lousy server delay. That’s $360 dollars decreased difference every single year. Over 5 years, it’s $1,800 profit in your pocket. With the exact same speed results.

An unexceptionable, shared host may get the same poor TTFB (time-to-first-byte) of 1.5 to 1.7 seconds. That’s 1500 to 1700 milliseconds off our target 2000-millisecond performance budget. That leaves only 300 to 500 milliseconds. Short time to load WordPress core, the theme, all plugins, and third-party scripts and APIs – and images. Is it possible? Only if you use speed strategy.

You can’t be sloppy or apathetic.

So what hosting provider do we recommend? None! Why? Because hosting services cycle from better to worse with the host’s business whims. Without a crystal ball, we can’t predict odd behavior. One day a host provides mediocre to excellent speed. Six months later – with a simple ownership change – crammed overburdened servers slowdown. Your server turns into a dragging slug. Their hosting business suffers losses caused by poor services. They finally invest in better capacity. Speed then improves. Until the word is out, they’re doing better. Then the cycle repeats.

In one test, for a New York client, BlueHost crammed more than 2,000 domains on a single server.

That BlueHost squeeze strategy isn’t typical. Still, test for the number of shared domains using your URL at YouGetSignal. Test server TTFB at ByteCheck or BitCatcha. Warning: All bitcatcha.com’s recommendations are affiliate links. They promote hosts giving back the most. It’s all about money.

Blogs recommending WP Engine don’t examine the speed performance ramification. Let us tell you why WP Engine is bad news:

WP Engine’s hosting services have bad TTFB (time to first byte or server overhead). It costs $35 per month (or more). Do they specify TTFB in their sales pitches or online materials? No. Of course not. No one would use them if they knew the truth. So most hosts avoid publishing this important speed information. Is WP Engine the only one burying TTFB specifications? No. Is it a criminal cover-up plot? We hope not. It’s most likely a convenient sin of omission.

Every host avoids the server overhead delay topic. Why? Because TTFB wanders and is often unpredictable. Or they may make excuses and declare with authority, “3-second TTFBs are normal.” iMotion Hosting makes that absurd statement. They’ve got to be kidding! But we’ve measured iMotion unstable server delays producing double that slow time.

Hosts don’t want you holding their feet to the fire. They don’t want that responsibility. Making server-overhead promises causes disappointing buyer’s remorse.

TTFB ignorance is bliss. Until you discover during real load-time testing how much it affects speed. Go ahead. Complain to the errant host. They’ll usually recommend (upsell) more expensive servers. They may suggest trying speed first-aid like CDNs and caching services.

The real cost-effective solution is building a fast site instead. Hosts won’t recommend this speed solution. They make less money if you build a fast strategic site.

One of WP Engines claims to fame is they’re *managed* WordPress hosting. What’s managed hosting and why is it bad for mobile speed?

Managed WordPress hosting is an “attendant” service. The host takes care of (manages) all technical aspects of running WordPress. This includes security, speed, WordPress updates, daily backups, website uptime, and scalability. All that costs money. Normally, people use automated plugins for these features. The less WordPress knowledge you have, the easier the motivation to buy these fantastic services.

So what? What’s the big deal? Sounds like they’re being nice and helpful. If they live up to their fantastic speed claims, there’s no quibble. But they don’t.

What they do is lock you out, the “advanced-blog” owner, of Cpanel access and lock each file so it can’t be rewritten. Who cares about that? They do. They don’t want anyone mucking about on their server.

You don’t buy more features. You buy less flexibility – and then pay more. It’s brilliant.

But flexibility is how you increase speed! The irony. WP Engine won’t let us help you speed up your WP Engine site.

One big strategy for speed is selective plugin activation. That only happens when speed plugins (or even hand coding) alter the server .htaccess file. That can’t happen with “managed” locked files. Unlocking and altering .htaccess may mean going through an FTP client. Just very messy, inconvenient and a royal pain in the butt. The chances of breaking something are not reduced but increased with “managed” hosting.

.htaccess is a configuration file for use on web servers running Apache. The .htaccess file is detected and executed first. It give the server rules of special exceptions. Even WordPress manipulates how Apache serves files via .htaccess – especially handling pretty permalinks.

.htaccess is used for speed functions. Such as:

  • Far-futures expiration.
  • Enabling Gzip.
  • Hot-link image protection.
  • Enabling keepalive.
  • Removing query strings.
  • Leveraging browser caching.
  • … and other speed tasks.

Our other complaint seem trivial, but for speed fanatics like us, it’s not: We can’t rollback the PHP version from 7.1 to 5.6. Why would anyone want to do that? 7.1 is faster loading. Well, it’s temporary for plugin testing.

Some old plugins, need old PHP. They won’t work on more modern PHP. Some even break your site.

A favorite old plugins is P3 Plugin Performance Profiler. We’ve written about it’s benefits before. There is no adequate alternative – yet. How much do we love this plugin? Well, we wanted a plugin author to change it to our specification – and make it compatible with PHP 7.x. How much would that cost? $10,000 dollars!

No surprise. We decided to stick with a simple workaround by dialing back the version to PHP 5.6. It’s simple to do – if you have Cpanel access. But with WP Engine shared hosting? No way. They don’t allow that. This barrier means we can’t quantify the worst offending plugins for site drag. There is an exception, if WP Engine screwed up and never advanced your version to PHP 7.1 – inconsistency. We’ve seen it.

So we ask, if you’re an *advanced blogger*, why the heck are you using WP Engine who assumes users are idiots? We’re insulted.