Best WordPress Performance Tuning


PagePipe speed services uncover real speed problems fast. And we discover unrealized speed potential, too. Many web problems aren’t necessarily the ones you suspect. It’s often something else. Learn the speed truth.

PagePipe’s speed techniques are counterculture and unconventional. We only focus on the 20 percent of site features that cause 80 percent of speed damage (Pareto’s Law). Speed is an area rampant with web myth, unproven plugin habits, and Google dogma. We challenge and test those misbehaviors.

Speed problems are more often from site owner’s whims and muses. You must stop adding unnecessary and unwanted features. Let go of ideas simultaneously ruining performance and profitability.

We help you make wise speed decisions. We show you how.

We like helping but … we’re not a bottomless pit of charity. We have limits. We can’t rescue a site if performance goals are unreasonable, unattainable, or impossible.

There’s no miracle speed performance without sacrificing something you love. If you’re in love with your site or how you do things now, you won’t like what we’ll tell you.

“Everyone wants to hear the truth about speed until Steve Teare opens his mouth.” – PagePipe staff

We don’t sell *curative placebos* that never speed up your site.


We cater to worst-case web performance scenarios. We optimize content at the origin on commodity hosting. Surrounding poorly optimized content with third-party CDN or caching services doesn’t guarantee success. Origin optimization is our first priority.


Cost-benefit analysis for page load speed is an important exercise. Are you committed to delivering the best performance possible to your readers? A site bloated with codes and scripts, especially external ones, can only load so fast … and there’s only so much that’ll speed it up. Loading only what readers need is the best performance enhancement. We help you determined that and optimize it.

Dumping whimsical or random stuff on your site ruins speed. Performance-fairy dust won’t magically deliver sub-second page load speeds. When your site has too much going on, it’s time for value analysis. Clean themes and the judicious use of plugins are key.

The single most effective solution to fix a slow site is keep what you need and jettison the rest. Don’t rush to use advanced components before taking care of basic needs.

We strip themes and WordPress to reduce WordPress bloat. We substitute poorly designed popular plugins with leaner alternatives to improve performance.

Pushing slow assets out to a CDN or caching service is a bad solution. That annual overhead is best spent on building a more optimized vital origin.

Slow-loading sites pull scripts from someone else’s network. These include advertising scripts, website analytics scripts, web fonts, and social sharing scripts from Facebook and Twitter. And more, of course.

These scripts are on very powerful networks and CDNs accessed by billions of users. They load slower than objects delivered from your site.

There’s NO magic potion to throw at third-party scripts. The only solution is a good ol’ cost-benefit analysis. If the profit benefits of third-party scripts outweigh their cost on your load time, fine. Keep them. If not, get rid of them. Is tiny ad profit slowing down your site?

We analyze your site and streamline it. We keep the objects you need. We consider with a skeptical eye those you merely want. And ditch what nobody uses – nor even sees.

Focus on the fundamentals – optimize your origin – before you look anywhere else.

WordPress is open source. People start with nothing more than a $5 website hosting plan. There’s a low-entry cost to the world of WordPress. It’s coupled with the availability of free WordPress themes and plugins. Many WordPress users feel entitled to get everything free of charge.

We’re advocates of free themes and free plugins for speed. And low-cost shared hosting. These are good enough when you build a strategic site with speed goals.

Are 60 to 70 percent of your traffic on smartphones and tablets?

The goal is often a desktop load time of under 2 seconds. This translates into around 4 seconds in a Starbucks parking lot.

The goal is improving user experience (UX) – not search engine optimization (SEO). The notion of speed improving SEO (page ranking) is a falsehood or web myth insinuated by Google. Tests show that speed affects SEO less than 1 percent.

People won’t tolerate a frustrating, slow-loading mobile website. They’ll leave. Many sites we build load in under 1 second. This is extreme optimization and the ideal. It’s not always achievable. Especially if a site has too many third-party scripts like:

  • Google fonts.
  • Google Analytics.
  • Facebook.
  • Email services.
  • Google Ads.

You need speed strategy and value analysis.

Speed is about user experience. Speed is an indicator of site-owner hospitality and website quality.

Load-time or page speed is NOT an influencing factor in Search Engine Optimization. That’s a myth and even a deception. Regurgitating web propaganda doesn’t enhance our credibility as a performance optimization company. Stop the speed myths.

The biggest players on the Internet make untrue statements about speed.

  • Hosting and CDN service providers falsely boasting stellar performance and security benefits. Providers like SiteGround, FastComet, GoDaddy, Cloudflare, and WP Engine – but there are many more. It’s a long list.

  • Deceptive online speed tests like Google PageSpeed Insights, Pingdom, GTMetrix, or We love these tests and use them. But they tell us to fix stupid things making no difference in speed – only scores. Better scores are meaningless. Wasteful.

  • Lazy authors and resellers of bloated, heavy themes like Divi (1-second load time). For comparison, a free default theme is often under 50-milliseconds load time. (WordPress core loads in around 100 milliseconds). Which theme do you think has the shortest shelf life?

  • Apathetic authors and resellers of plugins. Most plugins cause global loading on every page and post of your sluggish site. That’s site drag. Plugins then load scripts whether they’re used or not – everywhere. This is a hidden, unpublished speed liability. Good coders make plugins that don’t slow down pages. Who are the worst offenders? Oddly, the most popular plugins with millions of downloads. Plugins such as Yoast SEO, Contact Form 7, and Wordfence Security. The more *essential* the plugin the worse the site drag. Even popular paid SPEED plugins like WP Rocket slow down pages globally by 45.3 milliseconds. Plugin authors neglect mentioning site-drag specifications – a sin of omission.

  • And the big fish: Google experts claiming speed makes an absolute SEO difference.


Do these speed people lie? No. We don’t think so. Do they zealously exaggerate? Often. They’re caught up in a self-created technological tornado. It’s cognitive dissonance. That’s where you accept as truth what reinforces your existing belief – no matter how twisted. Not facts. Stories that amplify propaganda.

Trusting unsubstantiated web gossip is most absurd. But it happens every day. These self-proclaimed credibility sources can’t stop spinning. Some accept ivory-tower experts proclamations and ideology. Others follow The Blind Herd of fashionable web speed myths. And jump without questioning. Lemmings.

How can you know what’s speed truth or error? Is the pervasive problem of speed deception that terrible? Do you need to fix it? Yes. You do! Fight the urge to swallow what others tell you about speed. And even more, be suspicious of implications there’s a penalty for non-compliance. Don’t trust speed predator’s doom-and-gloom predictions. They want you afraid. Anxiety motivates sales of speed services and products.

WordPress performance optimization services brag about improving site speed. We’re sorry. 7-second to 4-second load times still aren’t good enough improvement. Yes, it sounds good. And it’s a measurable improvement.

But a 4-second page load is still a flop. Now, if it was 10 seconds reduced to 1 second – or even 2 seconds, we’d be mighty impressed. But 4 seconds isn’t best practice for user experience.

If someone claims speed improves SEO. They’re misinformed – or a snake-oil conman.

Scores don’t count – millisecond load times do!

Surprise! Google doesn’t really care about speed. They say they do, but reality says otherwise. They don’t walk the talk. Every web service they provide slows down web pages – Google Ads, Google Fonts, Google Maps, Google Analytics, Google reCaptcha, Google-mandated SSL certification, etc. Who are they kidding? Those are some of the worst speed culprits for slowing down the web.

Increasing your Google PageSpeed Insights test score from 50 to 86 is no guarantee of anything. Really. It’s not scoring that count. Anyone can trick a speed test score with trivial changes. Do speed scores affect SEO? You wish! There’s no compelling evidence.

Load time in milliseconds and page weight in kilobytes are what counts. Not a colorful green flag – or arbitrary numerical score. That applause is artificial and fabricated to help you feel good about vain efforts. Test performance criteria (the measuring stick) is based on “theoretical speed principles.” Those egghead opinions don’t make much difference in real-world user experience.

Load time in milliseconds and page weight in kilobytes are what count.

Where did these “speed scores” originate? Steve Souders coined the term web performance optimization in 2004. Souders worked at Yahoo on the Extreme Performance Team. He helped invent the Yslow speed test. How did his speed philosophies migrate to Google? They pirated him over to the dark side in 2008. There he helped determine the PageSpeed Insights criteria. Does he still work at Google? No. But his legacy of obsessive-compulsive speed doctrine lives on. He’s not evil. We like him. But he left a residue (scores) that’s still accepted as truth even though outdated and obsolete. The web moved on. Souders now works at SpeedCurve testing the interplay between performance and design.

Ivory tower is a state of privileged separation from real-world practicalities.

Guaranteeing SEO ranking based on an achieved Google PageSpeed score is ludicrous! Don’t be fooled. Speed affects Google page ranking less than 1 percent. What improves your SEO most is offering something people value. That’s relevant content and good user experience. Those things you can control. Unless you’re selling irrelevant rubbish. Then nothing you write is relevant. Nothing can save a valueless offer. Relevant content directly, and indirectly, move the SEO needle. Not hollow speed scores.


How much do promises of miracle speed cost? About $100. That’s the usual pond-bottom, scum-sucking price tag. What do you get for parting with your green Franklin? Well, it sounds technical and complicated. But the benefits listed are *coincidentally* identical to specifications for the paid WP Rocket plugin. Shocking. They install that plugin and enchantment – done. Results? Good score – maybe. Good speed? Not necessarily. They didn’t promise a load time, did they? Not for $100. Only a feeble irrelevant score.

Fix your site speed problem without shelling out for the recurring expense of annual plugin or theme rent.

You can install free alternative plugins instead. We test alternative plugins. They work. It won’t cost you anything to test them for yourself either.

But what if you don’t have the time or the technical mental energy to make these changes yourself? What if you’re too busy counting your money? Nice.

Hire us to help you. Not those other guys.

Hypocrisy! Didn’t we say not to spend money on speed parasites? But we’re not leeches or bloodsucking lampreys.

Not everyone’s fanatic about speed optimization. We’re busy people, too. We’re not operating a 100-percent charity organization to save the Internet. If you want us to repair or rebuild your site, we’ll oblige. But we want you to understand what exactly you’ll get and why it’s important first. We don’t sell boilerplate speed tricks you don’t need.

If you want to reduce your pain of making speed improvements, we’ll help. We’ll even teach you skills. Then you won’t need us again. Self-inflicted obsolescence. We recommend changes. You approve them. We then do it. We benchmark before-and-after improvements.


Why does SiteGround fail TTFB testing for WordPress sites?

How can SiteGround say on their home page:

“We’re honored to be a hosting provider recommended by – the most popular, community-driven sitebuilding software worldwide.”

Uh. They forgot to mention they pay for that endorsement.


“If you do decide to go with one of the hosts below and click through from this page, some will donate a portion of your fee back—so you can have a great host and support at the same time.”

Donate? Right. Whatever. Some? They mean all three.

WordPress only recommends three hosts, one is SiteGround. There are hundreds of better hosting companies. Self-serving affiliate advertising!

They say:

“[Host] Listing is completely arbitrary, but includes criteria like: contributions to,”

These are the same three we steer clear of for worst speed issues.

We recently evaluated a London-based site’s home page for speed opportunities. Load times on Pingdom were: 2.05 seconds, 1.95s, 1.85s for three consecutive readings. And on 2.86s, 2.6s, 3.27s. The site-owner Niel’s audience is predominantly on smartphones and tablets. Speed is important to them – and him.

We told Niel:

You are not sharing your server. Fast. But TTFB (time to first byte) is around 1.3s that is an “F” for fail. It’s your worst problem right now. Talk to your host and ask about TTFB specs.

We’ve written about TTFB specifications before in our article:

PagePipe: CloudFlare’s Bad TTFB >

The Time to First Byte (TTFB) is the time your browser spends waiting on the web server to send back the data.

Niel contacted SiteGround. He asked what was the deal with their bad TTFB. Here’s SiteGround’s response:

“The website is quite fast from my end. It loads for 1.35 seconds from my browser and for 2.25 from GTMetrix.

The TTFB time depends mostly of the type of website used. There is a difference. When you(r) website is a simple HTML site the browser just downloads the HTML code to the browser and the TTFB is very low. You will get an A there, however if you have a PHP application for website like WordPress or Joomla the TTFB is the time needed for the web server to compile the PHP code in index.php file to HTML code so this is why the websites built on top of PHP are slower.

For WordPress for instance when the index.php is compiled all plugins of WordPress are read by the web server as well so this why it is so slow.”

This is the best attempt we’ve seen from SiteGround explaining their lousy TTFB.

But we suspect the information isn’t really true. One potential reason they’re getting long TTFB delays is they use NGINX (EngineX) servers instead of Apache – just like Cloudflare.

We have seen erratic TTFB on SiteGround hosting. There are spikes when average load times are 12 to 26 seconds for pages that normally load in under 1 second. For one site we have under test, this slowdown happened 4 times in the last 30 days on SiteGround. And about the same frequency the month before. The slow times seem to occur every 5 to 6 days like a wave. Everything goes sour those days.

SiteGround can’t give any scientific explanation. Voodoo. They just reset the server cache. Then cherry-pick a test result that looks good – and report saying, “Look! We fixed it.”

Being consistently bad on magnetic drives is better than being occasionally great on SSD drives.

But we can do the exact same thing ourselves. The cache reset has nothing to do with it. It doesn’t fix anything.

SiteGround is saying they can’t perform well as long as you’re using WordPress. What?! They’re pointing the finger at WordPress. It could be true – but we doubt it. Here’s why: a large percentage of the Internet is using WordPress – 500 new WordPress sites are created every day! Surely SiteGround isn’t ignoring this? Do all their WordPress customers see this badness? If so they have a big, fat problem – not WordPress.

OFFSITE LINK: Falling Out Of Love With Siteground >

SiteGround isn’t being honest about their TTFB problems. Cognitive dissonance? If what they’re saying is true, wouldn’t the speeds be consistently bad instead of erratically bad?

You can find out your TTFB on: ByteCheck for free.

PagePipe is a WordPress site on cheap GoDaddy hosting and it loads in under 1 second. We get a predictable 500 millisecond TTFB from GoDaddy (with PHP version 5.4. TTFB is improved to 175 milliseconds since switching to PHP 7.1). As long as that “badness” never changes PagePipe loads in under 1 second. (Note: Yes. We host on magnetic GoDaddy drives. This is evidence of what is really possible using speed strategy).

Why doesn’t GoDaddy produce the same “PHP compilation delay” SiteGround is claiming? One difference is the shared GoDaddy server is Apache. PagePipe shares its server with 20 other domains. Niel and others on SiteGround share with no one! With Solid-state Disk Drives (SSD) even! Are SiteGround customers paying for fantasy speed? Hmm?

SiteGround claims the WordPress plugins are causing TTFB delays. They have to be kidding! PagePipe has 70 active plugins – and it’s not slow. That excuse is a smokescreen. A deflection away from the real problem which SiteGround isn’t disclosing. They need to own the problem, be transparent and responsible.

We smell a rat.

“I have been using SiteGround shared mid plan and the TTFB times are horrendous at least half the day and every day. I’m lucky in a sense at this point that my blog is small, theme is fast and it’s quite optimized. Even so, I’m giving strong thought to move to a (semi ) dedicated server in a month or so and not renew with them, even while acknowledging their outstanding customer support.” —author: Howard Milstein


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 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: 1.5M


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

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 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.

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, 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.”


Below are 8 other offsite links worth checking out:!topic/news/ixPneB4vpGk

Google AMP Is Not a Good Thing

link: I decided to disable AMP on my site >

link :

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


It’s google own services that drag the ratings down!

and it is especially annoying how they force us to use AMP!


You are so right. Run a page speed report on amp pages, you will get amp codes as the issue. How can Google be causing the problem and ask web owners to fix the problem?

Samuel Onyike


Load-time curse from Elementor pagebuilder temptation.

Because you like Elementor pagebuilder, does that mean you’re a speed fool? No. Lots of people like Elementor (3,000,000+). But it doesn’t match our speed *philosophy* because it causes bloat. Not because of plugin page weight or load time. Because of human psychology. The Herd can’t resist the temptation to create pagebuilder massive pages. It’s like a compulsive addiction. More is better is the assumption.

Elementor is the fastest and best of breed pagebuilder. But we don’t endorse pagebuilders!

For the computer to become “invisible,” you need 1-second page loads. That is when the user thinks they’re in control. That’s been the case with human-machine interaction for 30 to 40 years. Do any sites  achieve this transparency? Yes. But they’re only 1 percent of the Internet. Rare. It’s beyond the reach of most of our readers and costs big money to achieve.

All web hosts, theme authors, and plugin vendors make speed claims. Their proof to sell is vaporous. If there’s no anxiety, there’s no impetus to change. Our goal is saving the Internet from WordPress abuse. It’s never WordPress’ fault – or themes even. Most themes (Divi not included here) load in 50 milliseconds. It’s abuse that ruins websites. Overindulgence. We preach the evils of millisecond delays to get people to back off on design overkill.

Why do stripped down themes run faster? Because there aren’t options to fill with junk and bloat.

If you use a pagebuilder, use Elementor. But realize it may not future-proof your site. We have a suspicion WordPress will “break” all pagebuilders soon. On purpose? No. But they want to own that pagebuilder space.

We don’t use pagebuilders on principle. Mobile sites don’t usually need them with only one column of content. We find pagebuilders frustrating (slow). In the end, we get the same results (only faster) using discrete plugins and other workarounds.

We recommend using Elementor as long as you’re aware of potential traps. We steer clear of all pagebuilders.

SEO guys say speed directly affects SEO. It doesn’t. It affect UX. And UX indirectly affects bounce rate, dwell time, and return visits. That, in turn affects Google’s perceived user intent. Get used to waiting for page ranking!

We satisfy the quest for speed, image stimulation, and short attention spans.

For over a decade, we’ve studied balancing expressive aesthetics (aka branding) and mobile speed. It boils down to value analysis of all web assets: combination, simplification, elimination, standardization, and substitution. And if you don’t have firm goals, you can’t make wise choices.

Market positioning is a creative communication strategy. It serves as a shortcut to the buyers motive. Users won’t wade through junk trying to figure out why you are valuable or why they should care about what you do. They don’t have the patience. It’s a much more intolerant world. But the world’s always been intolerant of slow things.

Pagebuilders don’t cultivate essential or simple UX.

UX is about overcoming three critical things for quality-first impression (aka credibility):

1Speed being prime. Why? If you can’t get past this hurdle the user won’t hang around to even see your cool presentation. Pagebuilders make available enticing options to overload the page with expressive design aesthetic. Too many extras. There are no limitations.

2Next attractive aesthetics. We react emotionally and holistically to what we see and instantly determine if a site is “good” or “bad.” Based on design appearance, we decide to stay-or-go. Too much clutter or moving elements can repel. Is this overindulgence the pagebuilder plugin’s fault? No. It’s lack of discipline on the part of the real builder – the site owner or developer.

3And lastly, readability and findability (like navigation and text size, etc). Websites are about reading content (or skimming at the least). People are foraging for entertainment or problem solving. Pictures are nice. But it’s words that communicate to humans – and are also machine readable. OK. Pagebuilders don’t encourage you to put in the wrong words. But we needed to include this idea for basic UX completeness.

UX is that simple. Three helpful things – not thousands of tricks. And metrics (big data) are a tiny part of the evaluation. UX is about *feeling right* and being polite. What meter exists for measuring hospitality? Satisfaction surveys are tainted. Don’t waste time on focus groups either.

Short user attention spans want to click a button every 20 seconds.

Anyone can make a fast stripped down site. But can you make one that looks attractive? That’s the challenge. How good is good enough? Do pagebuilders help you reign in the desire to add more site features and functions? We don’t think so.

You merge simplicity, space, content, and colorful GIFs or PNGs. That breaks up huge content. It’s like orchestrating technology and design. Certain technology solutions bog down your site. Can you use faster-loading alternatives and still get the right feeling?

Just because you can do something doesn’t mean you should? You could make your text in the shape of a unicorn. Would that whimsical decoration help readability? No. “But my site is about unicorns.” Still no.

With a pagebuilder, you can add heavy parallax effects in many places. Parallax effects now and then, break monotony. They allow a few seconds before the next informational landslide. It adds visual relief to a heavy cognitive load – a time out. Or breathing room. But often the parallax image doesn’t reinforce the theme or goals. Then it’s a waste and mere eye candy. If you add heavy JPEGs then they better do some work to motivate sales.

Using anything but system fonts on mobile is a waste of bandwidth. Mobile screens need readable type more than decorative Google webfonts. Web designers don’t realize the utility of system fonts and fast loads are important. Pagebuilders allow the choice of many Google Fonts. It’s almost a peer pressure or habitual expectation to add fonts. There’s no warning of the speed consequences.

Hardcore PagePipe readers get 70-percent mobile audiences. Then speed pain becomes intense and the need to differentiate from the competition is high. You must build and test for mobile first (that old mantra) because if you don’t visitors have bad UX and bail out.

Fight waste. And resist faddish pagebuilder trends. Classic design still communicates best. What can you eliminate or offload and still function? What’s the minimum viable product – MVP?

To be creative, set limitations. That includes the idea of not being seduced by pagebuilder features.

Should I worry about Time to First Byte (TTFB) affects on page rank?

PagePipe homepage

If I use ByteCheck to run a test against PagePipe’s homepage, it returns the result of ~663 milliseconds TTFB.

ByteCheck TTFB test results for PagePipe homepage 663 milliseconds.

If using PageSpeed Insights which seems to be the go-to tool, it returns ~ 740 milliseconds.

PageSpeed Insights test of PagePipe homepage TTFB 740 milliseconds.

Is a TTFB difference of 77-milliseconds high?

That 77 millisecond deviation between different  measurement methods is common. Time to First Byte is server overhead. It’s affected by many things that slow down the server. Some servers fluctuate wildly: SiteGround hosting in particular. Some oddity is because of security and link checker plugins (server resource intensive).

All speed tests give different results. If you’re getting an offset of only 161ms, on two different tests, that’s amazing.

What we trust most is our desktop browser timer addon. And our eyes.

We don’t use a real stop watch. We use a browser load timer addon or extension.

Google doesn’t use PageSpeed Insights – or it’s criteria for page ranking. It’s not connected to their algorithm.

It’s a separate idealistic and ivory-tower test created by egghead scientists. It’s an inexplicably complex toy puzzle to solve.

A good score or bad score on PageSpeed Insights doesn’t the affect ranking in any way.

We’ve seen pages that load in 12 seconds get all “greens” and a high score. It is impossible to have WordPress pass the test with a 100. Yet, 1/3 of the internet is built with WordPress. What kind of test is that? A biased one.

The limit of human tolerance for machine delay is 10 seconds. A page that slow can still pass their test as “green.” Not always. But it deceived with trickery.

This silly speed test causes website-owner anxiety.

The only valid measurement is a browser timer (stopwatch). It’s only accurate for its geographic location. All speed tests are flawed. There are too many physical variables. Most use simulation. They don’t give absolute results but are instrumental in measuring incremental improvements. Relative measurements.

You cannot improve if you can’t measure. Cruddy machine measurements are better than no measurement.

Many things cause TTFB delays. Most variables are beyond the control of the site owner. Except one. Move your site to a different host and wait for their great TTFB to deteriorate. Will throwing money at the server problem make you more profit? Doubtful. The ROI is poor.

What affects page ranking is the user experience.

Speed is a primary blocker of a good user experience. Number 2 is aesthetics. User experience is how people *feel* when they use your site. Google can’t do the primary measurement of that *feeling*. But they can measure secondary things with machines like:

  • bounce rate
  • dwell time
  • return visits

These are indicators of inferred quality content that satisfies the user’s need. But if users don’t wait because of long delays to see the content, what good is the content if never viewed?

The bounce rate goes up. Credibility drops as an authority site.

Speed affects SEO indirectly over time. Not directly. Not instantly.

So, “If tools such as Google PageSpeed Insights return a metric of 95+ consistently, is this a leading indicator of a site that is performant?”

Performant means functioning well or as expected. This test is not an indicator of “performant.”

It doesn’t even mean “good enough.”

As mentioned, we’ve seen horrible slow sites fake out this test. We never use this test to check page speed. Nor do any other professionals we know. Paid optimizer services gladly guarantee a passing Google PageSpeed  score (an easy out). But not actual load time in milliseconds (real hard work). They know how to game the test. So do we.

But we’re not playing that Google game.

You are experiencing the frustration of the PageSpeed Insight test. It’s a gas-lighting ploy. Google makes you question your sanity.

I understand that Time to First Byte is a constraint or limitation that the server is experiencing or exhibiting.

I am assuming TTFB is a key indicator in improving page speed.

If a site is highly optimized and the server is the only remaining factor, I presume that this impacts page ranking. In reading through your articles though, it seems to indicate otherwise.

If tools such as Google Page Insights return a metric of 95+ consistently, is this a leading indicator of a site that is performant?

Should I avoid tools such as Pingdom, ByteCheck, GT Metrix, Google Pagespeed Insights if they’re not an accurate measure of speed?

We want to locate and correct speed issues. The waterfall many of these tests produce is most useful. You can examine what is being loaded. We can then do value analysis on the components.

Borrowed Industrial Concept
A manufacturing method is a value analysis to streamline processes and components. It includes:

  • substitution
  • elimination
  • combination
  • simplification
  • standardization

We use these methods to optimize websites.

“Value engineering began at General Electric Co. during World War II. Because of the war, there were shortages of skilled labour, raw materials, and component parts. Lawrence Miles, Jerry Leftow, and Harry Erlicher at G.E. looked for acceptable substitutes. They noticed that these substitutions often reduced costs, improved the product, or both. What started out as an accident of necessity was turned into a systematic process. They called their technique ‘value analysis’.”


Online speed tests are relative – not absolute. Using the same test, we watch (not measure) improvements from our site changes. Reducing requests is a false goal. It doesn’t always improve speed (load time) in milliseconds. In fact, often concatenation (minification plugins) break your site (unstylized HTML).

  • Relative changes on small numbers often look big.
  • Relative changes on big numbers often look small.
  • Absolute changes on small numbers often look small.
  • Absolute changes on big numbers often look big.
  • Explore both types of changes when looking at data.

A browser timer or stopwatch is a valid tool to measure speed for its location geographically. How does one measure for sites that have customers globally?

Good question. Again, you can only use approximation testing techniques. allows for selecting many different locations and browsers. also has a selection of geographic regions.

That is enough. It’s not accurate but results are repeatable. That means you can detect improvements from changes.

Assuming I’m on the right track, if speed is a primary blocker for a good user experience, is a stopwatch the only method of measuring it?

We rely on Pingdom most and second. Only because Pingdom gives faster results. Pingdom is a best-case scenario and is a worst-case scenario. Pingdom results are always faster. is always slower. Different methods of timing.

The browser timer is our acid test of the test. We trust it more.

You can learn about the differences between the two test above on our Site Tuning services page:


If yes, are tools such as the ones found in browsers that offer a measure of network speed also inaccurate and ineffective?

We have no evidence. Repeatable results are most important. If there is a conflict of results, I always trust the timer solution most.

If actual load time is the key determinant, what factors play a role?

Viewers hate slow pages.

Page weight is the total sum of all files creating a browser page. This is usually expressed in “k” (kilobytes). Page weight is an indicator of optimization and speed.

Page weight is key for mobile user experience. Mobile speed is 2X to 3X desktop speed. Much slower. The image shows the time tolerances of impatient visitors for browser response time.

If speed indirectly affects SEO over time, are the only factors content and design of a site (aesthetics)?

Borrowed Science Concept
Hurdle technology ensures poisons in food products are eliminated or controlled. Stuff like mold, bacteria, and fungi. For food products, hurdles are pH and water activity measurements. These approaches are hurdles the pathogen has to overcome for safe food production.

In the end, “how fast is fast enough” is human perception of waiting or impatience.


If the user leaves because the page is too slow, they never see the beautiful page. Or read the riveting content.

Speed is about hospitality and being polite.

The hurdles to detoxifying web user experience:

1. Bad speed
load time in milliseconds

2. Ugly aesthetics
first impression
halo bias in 50 milliseconds after page load

3. Poor content
readable and findable solutions

Your best return on investment always comes most from improving content.

The truest user experience is good content. You want to improve the profitability of your site: focus on content. Not aesthetic. Not speed. And not SEO gimmicks.

Good content is original, actionable, and answers a question. It’s sourced, unique, concise, correct grammar, and proper formatting.

9 Ingredients for great content:

  1. Create Original Content. Not deception.
  2. Always Focus On Creating Strong Headlines.
  3. Make Your Content Actionable.
  4. Be Able to Provide Answers.
  5. Be Accurate in Your Reporting and Sourcing of Information.
  6. Create Engaging and Thought-Provoking Content.
  7. Communicate Better by Adding Images and Video.
  8. Write Short and Pointed Content.
  9. Make Continual Updates to Your Website or Blog





The illusory superiority of Kinsta web speed hype.

Technobabble sounds like sophisticated language. But it’s incomprehensible techno-jargon. It conveys a false impression of meaningful scientific content. It’s deceptive, disingenuous, unfair, or nonsense. It’s a method of misleading with pure presumptuous rubbish. Meaningless technical language overwhelms and confuses the audience, masking the presenter’s dishonesty. It’s an indicator of propaganda.

Kinsta is a managed WordPress hosting provider founded in 2013. They say they’re obsessed with maximum speed performance. Hey! We’re obsessed with speed performance, too. We should be happy cousins. But we’re not. Why?

Because Kinsta expels technobabble. Spewing.

Technobabble bores us to distraction, frustration, and irritation. It smells funny.

Technobabble gives an impression the speaker knows things the audience doesn’t. Try decoding jargon. It’s then obvious it’s unclear, pretentious, and unacceptable. Even novice listeners detect careless technobabble as a sign of dishonesty and insincerity.

Technobabble doesn’t describe reality. The presenter picks things out or makes them up, to suit his purpose. Deceived by web myth, an innocent person repeats misinformation without intent to deceive others. A false manipulation or misrepresentation is perpetuated. Speed myth erupts from the mouths of supposed experts. Often with hidden agendas of secret or ulterior motives.

Ivory-tower pseudosciences within an industry convey confusing, misleading, or nonsensical ideas using technobabble. Multi-syllabic scientific jargon gives false impressions. It implies bold laboratory research and hard facts. Technobabble takes a simple concept and describes it in an overworked scientific manner. This masks its inherent simplicity.

Intentional technobabble convinces audiences the science explained is true. Even though it may not be. Serious people will accept a meaningless idea wrapped in enough impenetrable language.

So we sat through a 1-hour boring seminar on speed by Kinsta representative Brian Li. He spread many common speed untruths. We share the speed errors below. Keep reading:

Kinsta Speed Technobabble
by Brian Li

Here’s what Brian had to say about speed and Kinsta benefits in the free hour-long online seminar.

PHP version benefits are puny.

First Brian happily told us, “PHP 7 speeds up your site 3x.”

This is wrong. It speeds up the PHP code transfers. Your website also has a ton of other web assets that completely overwhelm this meager gain. Things like heavy images, offsite scripts, advertising, email automation, chat boxes, sliders, animation, videos, etc. These are where the speed problems lie. Not in speeding up PHP. That’s insignificant.


Database type? Does it matter? How much?

Brian told us “MariaDB is a faster alternative to MySQL database used by WordPress.” But didn’t tell us how much faster or how to get it. Only that if you buy Kinsta Hosting, you get it free. Well, it’s included in the price anyway. We suspect it’s not much help.

MariaDB shows an improved speed when compared to MySQL. MySQL exhibits a slower speed when compared to MariaDB. With the Memory storage engine of MariaDB, an INSERT statement can be completed 24% faster than in the standard MySQL. The memory storage engine of MySQL is slower compared to that MariaDB. – SOURCE

Speeding up the database by 25 percent is fine and dandy. But MariaDB doesn’t speed up your website by 25 percent. It’s the same gotcha as PHP gains. It doesn’t speed up the worst heavy assets like ads, third-party scripts, or image loading. Bragging about this is specsmanship.

Disk Drive Type and RAM are important? HDD vs SSD Brag

Bryan said, “SSD like Kinsta uses are better than magnetic drives.” Why? “Because read/write times are better and fetching is faster,” he says, “A fast server is better.”

This is true. But does it make a difference in real load time? Nope.

Specsmanship is the inappropriate use of specifications or measurement results to establish presumed superiority over competitors. Especially when no such superiority exists. We also call this vanity metrics.

Sorry. We’ve never seen server options make any difference in actual load time. Mechanical spinners give the same poor quality Time To First Byte as Solid State Drives. That’s right. In real-world comparisons, the gain is unnoticeable. Vaporous specsmanship.


Brian Li then talks about Kinsta’s Fast RAM and caching benefits. And mentions that virtual machines are better. At Kinsta, you get this trendy stuff even on the  starter plan. Wow! PHP 7, Maria DB, SSD, RAM, Virtuals. Sounds great! Doesn’t it?

Brian says, “These alone give solid performance.” You mean to tell us a garbage site with heavy theme and plugins will be fast with these toys. Sorry. Paying attention to origin optimization trumps this technobabble stuff always.

An eCommerce store on a cheap shared host with 1.7-second TTFB – can still, load in a 2-second performance budget. That’s right 300 milliseconds is the tiny headroom remaining to build the page. How? Don’t load fat popular security plugins like iThemes Security or WordFence. Or plugins like Yoast SEO or Google AMP.





Cool Kinsta Page Caching

Brian’s claim: “With Page Caching your site can handle 10X more traffic. But it breaks eCommerce, forums, and any interactive site.” That’s not very reassuring. And it doesn’t help non-cacheable cache. Let see? That would be third-party scripts like Google Analytics, Google Fonts, and Google Captcha. And many more.

Bryan is convinced NGINX and FastCGI on Kinsta do the world’s best caching. He claims we’ll see TTFB improve from 230 milliseconds to 138 milliseconds. Sorry guys. But that is only 92 milliseconds. Thanks, we’d gladly take those savings. But we can save 300 milliseconds by dumping Google Fonts with a plugin for Pete’s sake. Brian then tells us, “Fast TTFB is important for page ranking.” Yeah. We sort of agree. But it only makes less than a 1-percent difference in SEO.





Kinsta SSL and speed.

Bryan gets excited about a future *someday* when HTTP/2 is standard fare for hosts. But for today, it’s sort of geeky and beyond the reach of common site owners. Yeah. Sure. You can pay extra and have the future today. But is it essential to get speed? We don’t think so. He talks about HTTP/2 and HTTP/3 performance boosts. He recommends migration away from hosts that don’t provide it. Of course, his recommendation is his employer Kinsta. No bias here. Both require SSL certification. That forces you to be *secure.* He thinks that’s great for the web. We aren’t so impressed. You can learn more here:


Reducing server requests.

Then Bryan dives into concatenation and minification as if they are necessary. But he warns: “You might break your site.” Surprise! He then recommends customizing to rid conflicts. But sadly, he neglects telling us how that’s done. He notes that minification plugins don’t help HTTP/2 because of multiplexing. So why is he talking it about it? He just recommended HTTP/2 on Kinsta. We suppose he’s showing alternatives to Kinsta. He then recommends using Autoptimize or WP-Rocket plugins as helpers.

Here’s our free article on minification and concatenation:




Optimizing images in the media library.

Now the hour-long seminar takes a turn into saving load time reducing the page weight of heavy images. He says, “Using right format. JPEG not PNG for photos.” This is a basic truth and big error for novice website builders. But he doesn’t tell how to retrofit a media library polluted with fat PNG photographs.

He recommends using ShortPixel or Imagify plugins. Those aren’t our preferences but they work. He says to serve webP-formatted images to supported browsers. We rarely see much benefit from this Google-endorsed trick. It will reduce image sizes by 10 percent. But that isn’t significant because images load in parallel. Cloudflare Pro converts to webP. WebP is not supported by Apple. A downside is webP uses more disk space with duplicates. We never use webP format.

If you’ve botched your media library uploading huge PNG photographs instead of JPEGs, it can make a big difference when it’s fixed. Otherwise, image optimization doesn’t give as big of a speed boost as it used to. Why? Browsers are smarter about handling images fast. A lazy load plugin may solve many problems for you instead.

UPDATE: WordPress now incorporates lazy load in core.





Fonts and speed.

We’re a big advocate of using a system font stack instead of slow-loading Google Fonts or Adobe fonts. So is Bryan. So we agree on something. But Bryan doesn’t tell you how to do this magic.

Read our take on this best practice:




Disable WP Native Cron

This is a geeky thing to do. It was faddish for awhile after WordPress added the Heartbeat API. Have we ever done it? Yes. Some hosts can’t handle the extra server load. Bryan recommends pinging wp-cron.php with better frequency. High traffic sites are most affected. And of course, the reason he mentions this puny feature is it’s a default on Kinsta.

The better and cheaper solution is learning about Heartbeat plugins.

Repair Render Blocking Assets

Why do professed speed experts recommend rewriting code to eliminate the page blockage rendered by scripts? Bryan recommends it. This is so esoteric, time-consuming, and costly. Few plugins help. Always it involves custom work. But the payback is so small compared to getting rid of popular multi-function plugins like Yoast SEO or AMP or iTheme Security.  We’ve written about Async or Defer flag for JS loading. But we’ve found this more often than not breaks your site. Bryan also mentions inlining critical “above the fold” CSS styles. These are costly make-work projects invented by programmers and coders. Don’t go there! Have we ever done it? Yes. But we were building experimental pages loading in under 300 milliseconds. That is unnecessary overkill.


CDN the wonder band-aid – promising after-speed-damage repair.

Nothing makes us more rabid than speed gurus recommending CDN as a solution. This a weak excuse for building a cruddy bloated website. Bryan recommends CDN of course. But at least he mentions CDN may not help. CDN can slow down page load time. Bryan warns: “Don’t just slap CDN on by default.” We agree.
If you have a database problem, CDN won’t help. We steer clear of CDN with origin optimization. That means not being sloppy.


Tuning PHP and MySQL.

Now Bryan goes out on a speculative limb. He recommends Query Monitor plugin to identify slow components. This is a complicated plugin for professionals. He then tells us if we don’t know what to do “hire a developer” for solving problems. Absurd focusing on the wrong target. These need coding solutions. Ineffectiveness.

Is Kinsta expensive hosting?

You decide. Their pricing per month is here. Have we ever used them for client speed repairs? Yes. The sites were so broken we couldn’t migrate or backup. They contained obsolete WordPress versions and stale plugins. Absolute nightmares. Updates weren’t possible without breaking the site.  Kinsta moved those sites. They were then faster loading – but still, time-bombs waiting to explode. The site didn’t *get pretty* just being moved to a different expensive host like Kinsta. Postponing the inevitable implosion.

You can get under 2-second load times on shared hosting. Pocket the money you’d spend elsewhere.

Kinsta is not the only speed solution. Build a better site from the ground up. Don’t add unnecessary junk.

Is Kinsta a reliable source of speed information?

“If you do decide to go for cheap WordPress hosting, you should expect your site to go down from time to time (since at $10 per month, you’re most likely sharing a server with hundreds of other users). Also, expect that most issues won’t be resolved all that quickly. It’s just how the numbers work out.” – Kinsta

This quote is from an article written by Tom Zsomborgi. Tom is the Chief Financial Officer at Kinsta, a WordPress hosting platform.

Update: Our store is now hosted on Rochen. $4.95 per month. We aren’t an affiliate. Why did we leave BlueHost? For a better repeatable TTFB of 600 milliseconds.

We agree with Kinsta mostly. Their article about cheap hosting exaggerates some things. Like on BlueHost supposedly PagePipe’s store is the only domain on the server. They didn’t promise us that. Does that give us phenomenal speed – no. The TTFB is 1.7 seconds sometimes. That means PagePipe loads pages in under 300 milliseconds. And those are Easy Digital Downloads store pages. Every page reloads with an Ajax request! Boo.

And cheap hosts go down rarely. What do you expect for so little money? Most brag up times of 99 percent. And it’s often true. Some of our GoDaddy issues are resolved amazingly fast. And we mean hard technical problems. But we have a low expectation. We also think GoDaddy is a smuck for charging for SSL and privacy. Robbers. But we don’t buy that stuff from them.

Update: GoDaddy now offers free privacy. It formerly was $12 per year per domain.

We tested a client’s site on BlueHost with the same conditions as our store. He gets 500-millisecond load times – with a TTFB of 100 milliseconds. His SSL loads in 100 milliseconds. How? He has no clue. And neither do we. An Act of God. He pays the same as us. Go figure.

We’re not an advocate of cheap hosting. Whenever we can, we get clients on the most expensive host they can afford. It makes our life so much easier for obtaining speed. But not everyone can do expensive. And high price doesn’t translate into good always. We help resourceful site owners, too.

We walk the talk to show others how cheap-by-choice works. Severe self-imposed limitations.

It’s weird how good hosts and bad hosts are all bad and good at some time or another for speed. There is little consistency (repeatability) in performance between domains on the same hosting – pricey or cheap.

Now we have to consider this “cheap-hosting” article was published by Kinsta. Oh, they’re a host! They sell competing services. Would there be any bias against cheap hosts (since they’re not cheap)?


Have we ever put clients on Kinsta to solve speed problems? Yes. Do they always solve speed problems? Nope. Sometimes they make them worse. Go figure. We’ve found this to be true for every host. Variances. Fluctuations. Unpredictability. Voodoo. But we’re not paying for repeatability. We’re not relying on them to do a good job. We expect them to do a lousy job. We build accordingly with origin optimization. No tight tolerances.

The article’s testimonial is by Joe Hanley. He now hosts his site ( on Acquia Hosting – not Kinsta. The Acquia homepage opens in 8.83 seconds in our timed browser. Lots of clutter on screen. Wow! Can’t wait to sign up with them. Built for Drupal? What?!

We bet Joe moves his site a few more times. Four times just isn’t enough.

Doesn’t Kinsta specialize in WordPress – not Drupal? Odd testimonial choice. Oh, Joe’s a software developer. No wonder.

So yes, if you’re a novice web virgin, you’ll lose a lot of money on cheap hosting trying to make things better. All a waste.

Conclusion: All hosting sucks – at sometime, in some way.

Find out what your server TTFB really is.

No plugin trickery required for this Time To First Byte measurement magic.

Find out what your server’s TTFB really is.

Are you wondering, “What’s TTFB?” Read this first:


You can test TTFB with or

BUT … what if your theme and plugins are hammering the server and slowing things down? That’s not the servers fault.

Wouldn’t it be nice to find out what your servers TTFB really is without the core, theme, and plugin overhead load?

Here’s the trick:

1Download this Time To First Byte sample page.


INSTRUCTION: Right click the browser page and download as htm file. Or use this downloadable zip file. Decompress it before uploading to your media file..

This page is written in HTML code. It loads instantaneously. No WordPress core, plugin delays, or theme overhead is associated with it.

2Upload it to your WordPress media library. Yeah. You heard it right: The media library. No FTP or Cpanel skills required.

3 Copy the HTML file’s URL.

4 Paste the URL into the test field at

5 Copying and paste the HTML file URL (above).

6 The TTFB is labelled First Byte. It appears in the Performance Results – first column from the left. See red square.

We consider Time To First Byte as your minimum server overhead. An excellent TTFB measurement is 200 milliseconds. Typical TTFB is around 400ms to 500ms. And bad is anything over 1 second. In that worst case, plugins are repeatedly hammering server resources. That slows down the server. These are usually the heaviest and popular plugins. They are writing and reading data and creating databases. Plugins like SEO, security, broken-link checkers, backup, caching (examples: SuperCache, W3-Total Cache), dynamic site map generators, related posts, etc.

REFERENCE: common blacklisted plugins

REFERENCE: WIKI: time to first byte defined

How Kinsta PRETENDS It’s the Fastest WordPress Experience

Kinsta is a managed WordPress hosting powered by Google Cloud Platform. They’re located in Los Angles, California.

Kinsta’s Chief Marketing Officer is Brian Jackson. We think largeBrian’s a smart guy. We quote him often on PagePipe.

We’ve written two articles about Kinsta:

1REFERENCE: Is Kinsta a reliable source of speed information?

This article above roasts the thinking of Tom Zsomborgi, the Chief Financial Officer at Kinsta.

2REFERENCE: The illusory superiority of Kinsta web speed hype.

This article above condemns the thinking of Brian Li, the Website Content Manager at Kinsta. Especially his 1-hour free seminar about website performance.

Why do we *loathe* Kinsta so much? They brag about speed. So what? PagePipe brags about speed, too. Is the pot calling the kettle black?

OK. Let’s examine something. This article by Brian Li:

How Kinsta Designed the Fastest WordPress Hosting Experience

It is on Kinsta’s blog, a self-promotional article. How fast did the page open in our desktop Firefox browser? 3.01 seconds. Is that fast? Is it the fastest WordPress hosting experience? Not even close.


We don’t appreciate Kinsta’s bragging buffalo and technical mumbo-jumbo to entice new customers.

Here’s speed results for that Kinsta page (sharing the server with no other domains):

Time To First Byte: 199 milliseconds. Dang! That’s fast!

Load time: 8.091 seconds. That’s right over 8 SECONDS! Hey? Why so slow?

Requests: 121. That’s a lot. But we’ve seen worse.

Page weight: 3.7 megabytes (4.132 megabytes fully loaded). What the heck! That’s one above-normal heavy page. Like double the weight of average sites.

The average size of a website is 2 Mb for desktop and for mobile. – REFERENCE

So are Kinsta servers fast?

Yes. Looks like it with under 200-millisecond TTFB. And their page loads? Uh. So. Hey, who screwed up the page? Who loaded it down with heavy rubbish? Probably an unknowing web designer. Sloppy.

Does Kinsta understand speed and performance optimization like they claim? Really?

Credibility is trustworthiness, expertise, and leadership.

Kinsta Failure.

Kinsta provides a fast host server … but they can’t build fast page experiences.

For comparison, this page you’re reading right now is hosted on GoDaddy. One of the most despised, corporate, shared-hosting companies in the world. Can you get a fast load time on GoDaddy with cheap shared magnetic servers?

Let’s compare test results.

THIS PAGE (sharing the server with 28 other domains):

Time To First Byte: 621 milliseconds. Dang! That’s pretty slow!

Load time: 1.654 seconds. That’s right under 2 SECONDS! Hey? Why so fast?

Requests: 15. That’s not very many.

Page weight: 0.181 megabytes (0.182 megabytes fully loaded). Woah! That’s a super lightweight page. No wonder it’s so fast.

Speed Conclusion

Does a fast host server (like Kinsta) make your web pages fast?

Not really. Not if you mess the page up with junk. It requires site origin optimization. That’s performance strategy.

Price comparison

GoDaddy shared hosting plan: $3.99 per month – or $47.88 per year

Kinsta cheapest-hosting plan: $30 per month – or $360 per year.

In 10 years, you’ll have spent:
$3,600 with Kinsta for hosting.

You got money burning a hole in your pocket?

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.”
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 4,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 web 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 or system 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,
“Segoe UI”,
“Helvetica Neue”,

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 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 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 labelled 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

TOP100 plugins are slowest and most bloated.

If you search the phrase “Essential WordPress Plugins,” you’ll get about 7.4 million results. They all tend to regurgitate suggestions for the same old plugins. Copycat content. No wonder the identical plugins keep getting more installs. Even when better alternatives exist.

Toxic WordPress

Includes important tips for mobile speed without coding.


83 pp, 362k, 8.5 x 11 inches, PDF download.

Sorting and testing all the new plugins is too much work. So people don’t test. They assume. The assumption is “popularity” is good. For plugins, that is usually decided by looking at the number of active installs. Active installs is not a sign of quality or performance. It’s a standard of herd mentality.

Herd mentality, or mob mentality, describes how people are influenced by their peers to adopt certain behaviors. Examples of the herd mentality include nationalism, stock market trends, superstition, and home décor. —Wikipedia

To Engineer is Human by Henry 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+. By Sep. 2016, over 46,000+ free plugins in the repository. And today, over 55,000 plugins. It’s difficult to stay on top of that rapid rate of change. It’s staggering.

To make a fast decision, it’s plainly easier to select from the most popular plugins – and consider that good enough. There are over 55,000 free plugins in the repository. And this doesn’t count any of the plugins available on GitHub where authors refused to go through the WordPress red-tape of acceptance.

You can choose any plugin from the TOP100 and from our experience it will be the slowest and most bloated plugin in its class. For example: #1 Akismet: 52M installs, #2 Contact Form 7: 42M installs, #3 Yoast SEO: 33M installs, #5 Jetpack: 28M installs. These are all heavy plugins and either directly or indirectly affect load time. We see these plugins installed on most slow sites.

Plugin popularity is rarely an indicator of good value. People assume they must be good. At one time, they were either the-only-game-in-town or repaired or compensated for WordPress deficiencies that later became solved with new WordPress versions. So even though the need for “repair” was gone or obsolete, the herd kept installing out of habit and myth. It became de-facto standard best practice.

Many recommended “essential” plugins have negative speed repercussions.

Our rule of thumb is: the more popular a plugin is (active installs), the higher the probability it’s a slow loading plugin. Why? We don’t know exactly why this correlates. But it holds up in our speed testing.

It’s the quality –not quantity– of plugins that slows down a site. Speed testing free plugins and themes is our specialty. Millions of herd-mentality WordPress plugins slow down the Internet, waste web resources, – and use up your precious time. (our blog) has 53 active plugins. It loads in under a half second in the USA and about 1.2 seconds for Europe ( It can vary. That is using the cheapest, shared, old-magnetic GoDaddy hosting located in Arizona. No CDN. It will go even faster when GoDaddy updates to PHP 7.1 – but they’re running on outdated version 5.4. We share our server with 24 other domains. Why? We want to prove a point: You can use “speed strategy” rather than throwing money at load-time problems.

Our Mantra is avoid popular plugins. High number active installs means they’re the slowest.

We don’t know why “popular = bloated.” We speculate the plugin authors are content and apathetic to speed and quality. Popular plugins existed first and use old unoptimized coding techniques (obsolescence). They tend to get heavier with revisions instead of lighter (kludges).

The authors of old plugins don’t have competitive motivation to be lean for speed. This isn’t true for newer, less-installed, lighter plugins. Speed (load time) is now a desired feature we’re seeing more because of mobile devices. But fresh, fast plugins are not easy to find. There are 55,000+ plugins in the free directory. Wow! An ocean.

What is more characteristic of “goodness” is retention rate. That’s calculated by taking the active installs and dividing by the number of downloads for all time. A plugin with a retention of 20 percent is pretty good. If it’s 5 percent or less, it’s a danger sign. They were tried – and dumped.

Slow plugin’s download file size is a clue. Bigger files load slower. There are some exceptions – but they are few.

In our new Toxic WordPress, we present typical time-wasting herd plugins suggested on thousands of WordPress blogs. And we give you speed alternatives.

83 pp, 362k, 8.5 x 11 inches, PDF download.



… having read your book and browsed your site I had installed pretty much every plugin that you warn against using! I’ve spent I don’t know how much money buying plugins … I’ve reassessed the plugin functionality I actually need and struck a line through most that I had installed; the rest I think I can replicate with the lighter versions you’ve educated me about. … I am hugely grateful for the help and advice on your site and in your book: it’s great to know that good things are possible with WordPress on shared hosting!

—Jonathan Westwood, United Kingdom

Don’t be fooled. Learn how to identify the fastest themes.

We evaluated 35 theme candidates. All are available as free downloads from the WordPress theme repository. They came to our attention via email newsletters. Some are new and others are older but still popular. The alphabetical list is at the bottom of this page.

Here we report some theme trends that affect website speed and how to evaluate what is important.

Remember, our goal is a two-second, home-page load time using WordPress. The lighter the theme overhead the more headroom we have in our performance budget for adding things like images, forms, and other features.

There are certain cues and clues that help us evaluate a theme for speed potential (fast page load) – without installing it first. The download package size is number one on our list. Any theme download that is under 1M (zipped) usually is a sure bet for speed. But larger than that compressed file size doesn’t always mean a speed failure. You have to dig deeper by downloading the package and examining the contents. The 1M package size is a quick-and-dirty selection method.

A compressed theme package may contain many resources – or sometimes non-features. When we say non-features, we refer to fluffy bloat intended to deceptively entice website owners. Theme authors include these things to make the theme appear “feature rich.” But most features have a speed price.

Modern WordPress Speed Traps

When evaluating themes for speed, you need to consider the following:

  • Google Fonts (or worse the heavier Typekit) will slow down a website. It’s now rare to see a theme using fast-loading system fonts. Die-hards argue that most Google Fonts are now present in all browser cache. There is no way to prove this with present online testing tools. We estimate a 100 millisecond slow down uing Google Fonts instead of websafe fonts.
  • Fontawesome icon font – or an equivalent such as genericons or glyphicons. Icons are a popular inclusion. The downside is they load universally on all WordPress pages and posts whether the icons are used or not. How much this slows down a site depends on variables. We feel icon fonts are justified if you leverage them in your page design. But usually, it’s better to dequeue the font in the WordPress functions.php file and simply use icon PNG image files. If you remove the font files from your server using FTP or C-panel, you will end up slowing down the site even worse with 404 errors. Fontawesome can slow down a site by 500 milliseconds or more – 1 second delay isn’t uncommon. But how bad it really is depends. More typically, you’ll see delays of 100 to 200 milliseconds. There may be some improvement by using Better Font Awesome plugin and loading from their external CDN. We’ve played with this in tests and it has some potential for time-saving parallel loading.
  • Sliders are common additions now. When they are built into a theme, they may universally slow down all pages – even when they are only used on the Home page. How bad this delay is depends upon the slider. But for example, Nivoslider slows down all site pages by minimum of 200 milliseconds – even when no slider is present. The most popular in the 35-theme evaluation was Nivoslider (5 instances). Other sliders included: bxslider, OwlCarousel, Flexslider, Sldr, lightslider, and few custom ones. 19 of the 35 themes used sliders – that’s 54 percent. Over half. Sometimes, a better strategy is adding a standalone slider plugin and then selectively activating the plugin only on pages where it’s needed. The best plugin to do this is Plugin Logic.
  • Every theme includes a screenshot that serves as an icon in the WordPress theme control panel. These are rarely optimized images. In this evaluation, they vary from 100k to 2.5M Jpeg file sizes. The typical size is about 600k. This extra theme package weight doesn’t slow down the theme. But it’s an indicator of the theme author’s attention to speed details. A bloated screenshsot is simply benign, but wasteful, overkill.
  • It’s common for many themes to include sample or demo images. Like screenshots, these are rarely optimized images. 16 of our themes included header or slider images for easy setup. But they are extra baggage in the package. Worst case we had one theme with over 5M of Jpegs. But more typically, they were around 200k to 500k. These images are not intended to be used. They will be slow loading.
  • Theme packages may include language translations. These can add from 100k to 600k. But only 6 of our samples had these files. They don’t slow down a site. They just increase the package size.

The final proof is installing the themes and doing benchmarks. But, as noted above, there are things that can streamline our selection process before installation.

Fatness and popularity: Site owners prefer bloat.

The pressure to inflate theme package sizes is almost irresistible for theme authors. This is evidenced by the popularity of two examples: Zerif-lite (2.7M zip) 100,000 installs and Hueman (2.1M zip) 80,000 installs. And the incredible, 7M-download Enigma theme with 30,000 installs. Most themes are lucky if they get 10,000 installs. The fatter the more popular.

So if a theme is popular with the most installs, you can bet it’s a slow loading theme.

There’s a great article we recommend over at WP Rocket about choosing fast themes >

,MB,expanded,installs,fontawesome,header image
awesome.1.2.1,3.2,3.7,900,0.835,1280 fullscreen
dellow.,1.1,1.8,700,0.672,parallax 1920x1080px
faceblog.1.0.5,1.2,1.6,50,0.838,composite blocks
futura.1.5,0.484,1.6,500,,parallax 1920x1080px
simona.1.0.4,1.6,2.4,1000,1,1600 × 800 pixels



thumbnail of THEME-ME-10-v1.compressed
THEME.ME: What is the fastest free theme? There are 5,100 free themes in the WordPress theme directory. Of those, only 1,602 are responsive. All the rest are fixed-width junk. How did we sort the remaining 1,602 free responsive themes to find the fastest loading?


Twenty-seventeen Default Theme Tips Read our torture-test results of this popular free theme. Don’t get locked in for recurring *annual renewal* theme memberships. Save your money. The Twenty-seventeen Torture-tested Themes ebook contains honest and common-sense reporting and tips about mobile WordPress speed!

Potential downside of LiteSpeed Cache plugin

LiteSpeed Cache requires requires LiteSpeed-powered hosting (not Apache or NGINX).

LiteSpeed Cache for WordPress is a site acceleration plugin. It features a server-level cache and a collection of optimization features.

LiteSpeed claims advantages over common Apache servers. Here’s why we’re doubtful.

1It is up to six times faster than Apache. And 12 times faster than NGINX.

Does this make a difference in page load time? Not really. Real culprits slowing down websites are:

  • javascript
  • third-party APIs
  • advertising
  • email services
  • heavy images
  • etc

2It is three times faster than Apache in SSL.

Would we argue that a stereo performing above the range of human hearing is better? Braggadocio.

Does that mean it’s faster than not using SSL? We doubt it. But we’re being snarky. It’s a metric. But is it more significant than loading bad-choice images? Such as large PNG photographs on your site? Of course, not. It’s insignificant by comparison.

3With its LiteMage cache, LiteSpeed makes Magento pages run up to 75 times faster.

Wow! That sounds really good. But, what does that mean for WordPress users? Uh? Nothing. Magento is an e-commerce platform built on open-source technology. It’s a content-management-system alternative for WordPress and WooCommerce. Big deal. It’s not even part of the WordPress world.

4It increases PHP performance by 50 percent.

Is PHP performance – or lack thereof – significant? Not from our tests. Immeasurable.


So let’s talk about LiteSpeed benchmarks? What are they saying:

We tested HTTP/2 implementations from LiteSpeed Web Server, Nginx, and Apache, to see how they would compare when loading WordPress. LiteSpeed beat Nginx by up to 12X, and blew Apache out of the water by a whopping 84X! The best available WordPress cache plugins were used for each server: LSCache for LiteSpeed, FastCGI Cache for Nginx, and W3 Total Cache for Apache. – REFERENCE

They later mention those specs are on HTTP/2 servers. And they weren’t using cheap shared hosting. They used Vultr Cloud VM. That service costs extra money based on usage. Vultr’s cheapest cloud hosting plan is $5 per month.

What are they not comparing? They’re not comparing milliseconds of load time for a website. They’re talking about server processing requests per second. Not the same thing at all.

On common affordable everyday HTTP 1.1 servers, the results aren’t as shiny:

LiteSpeed Web Server performs 5X faster than Nginx and 28X faster than Apache when loading WordPress.

These specifications mimic what developers claimed about PHP version 7 when compared to PHP version 5. WordPress runs on PHP server-side language. Did that version update shave seconds or milliseconds off of WordPress page load times? No. It only increased server processing speed. The benefit wasn’t even measurable with standard speed tests. Hand-waving specsmanship. Pure hype.

Are these processing metrics a valid indicator of potential website speed improvement? Not for a minute.

Some speed considerations when using WordPress LiteSpeed Cache plugin:

1When plugins have multi-functions, they get heavy fast. LiteSpeed Cache plugin is no exception. Its file weighs 2 megabytes when decompressed. (Compared to 528k for Autoptimize plugin alternative.)

It’s better for speed to use “discrete” plugins (one function and few or no settings) rather than a multi-function plugin.

Autoptimize is a multi-function plugin, also. We use Autoptimize plugin sometimes – but not all the time. Why?


That’s right more plugins are better than less in the speed department. Only when using lightweight discreet plugins. One fat plugin like Yoast SEO – 150 to 250 milliseconds – negates all gains from discrete plugins.

Caching is a band-aid for inferior website design. Any page using origin-optimization strategy always loads faster. The complexity of many settings means the plugin isn’t dummy-proof.

Plug-and-play discrete plugins are more bulletproof. Caching often breaks site functions. As does minification (file concatenation). Because of fragility caused by complexity, we don’t always use a caching plugin. It’s herd mentality to always install a caching plugin. Especially popular ones like W3 Total Cache (1+ million active) and WP Super Cache (2+ million active). It’s better if you don’t use caching if you don’t get a significant gain. And we rarely do. Not with an optimized site built for speed.

2Using discrete plugins for individual features is faster. These plugins usually load in under 1 millisecond. LiteSpeed Cache adds 53 milliseconds of load time globally. That is on every page and post of your website. We call that site drag. We can install and activate over 53 discrete plugins in that same load time.

3The question-and-answer section of the LiteSpeed Cache website recommends third-party CDN workarounds. This is bad practice for speed. Again, it’s an after-the-fact repair band-aid. It doesn’t “fix” the sloppy site-origin problems. It masks the causes of real bloat. Apathy is the true cause of bloat.

4Using discrete plugins allows us to selectively activate or deactivate plugin functions on a page-by-page basis. This is always useful, especially on an e-commerce site. The store pages are dynamic. They often won’t work with caching plugins – or other plugins used for minification.

According to LiteSpeed developers, a single LiteSpeed server is capable of handling data equivalent to two Apache servers. We dislike LiteSpeed’s claim of “80 times faster.” Ridiculous vanity metric. Server execution time doesn’t translate into milliseconds of gain on a website. You can erroneously imply the same claim for PHP7 over PHP5. But change in server PHP versions doesn’t make a dent in poorly optimized images, ads, fonts, etc.

If LiteSpeed is free from your host, go for it. Use it. If you’re paying extra for it, think about what value you get and if it contributes to site profitability.

NOTE: Lightspeed was aggressively added to one of our sites by the hosts. That means they didn’t ask permission, they just added the Lightspeed plugin. That broke Easy Digital Downloads plugin checkout functions. Instant no sales. The solution? Because we knew they would just reinstall the plugin if we removed it, we used selective deactivation to turn off the Lightspeed Plugin on the checkout page. But that didn’t work. WE had to have the host deactivate LiteSpeed completely. There are workarounds with LiteSpeed for ecommerce.

LiteSpeed and eCommerce problems

Litespeed cache causes the WooCommerce shopping cart to be updated incorrectly. LiteSpeed requires a configuration tweak.

Is WooCommerce supported?

For some WooCommerce themes, the cart may not be updated correctly. LiteSpeed blog has a tutorial on how to detect this problem and fix it if necessary.

Then update your do-not-cache cookie list in LiteSpeed Cache plugin settings.

Find “Do Not Cache Cookies” in the LiteSpeed Cache > Cache > Excludes tab.


2:59 minutes
LiteSpeed Cache plugin – best settings for WordPress


48:33 minutes
Litespeed Cache Version 3 Tutorial 2020 – How To Setup Litespeed Cache Plugin – Litespeed Cache


Do Not Cache URIs – used to exclude pages from cache. (List pages that have contact forms, logged-in pages, or any checkouts. Although WooCommerce checkout is already excluded by default.)

It’s reported:
WooCommerce doesn’t want something cached (like, for instance, the Cart, My Account, and Checkout), LiteSpeed Cache will automatically respect that, and will not cache those pages. There’s no extra configuration required.

But LiteSpeed doesn’t recognize Easy Digital Downloads plugin transaction pages.

Web panic about Google Core Web Vitals baloney — & WebP image silliness.

Google hedges about speed policy like Core Web Vitals. Not every criteria Google preaches about speed makes a difference in the real world.


We agree with the article above by TorqueMag published on June 24, 2020. They talk about what really matters for SEO.

Especially this quote:

“Google’s primary goal has always been to match users to good content. Consequently, it should be every website’s aim to create it for them. The algorithm has been constantly moving away from artificial ways of inflating your SEO and towards promoting high-quality articles. But it’s more important than ever to focus on content.”

We do not believe Google (or bloggers who quote Google) when they say speed is an important ranking factor. No data confirms this. It affects ranking less than 1 percent. It’s a great way to create anxiety in site owners. Our PagePipe traffic volume continues to grow. This is because of the Core Web Vitals hubbub. Google attempting to quantify Page Experience is good for our business – but not yours.


“… the average time it takes to fully load a webpage is 10 seconds on desktop and 27 seconds on mobile.”


Is 27-seconds good enough? No, it’s horrible.

Google’s been being scary and bullying about speed for years with no teeth.

We make our living selling speed improvement.

Our page-speed goal is a 2000-millisecond load time. That’s right. Under 2 seconds.

Articles like this one (below) help feed the fear that sites are lacking:


“Core Web Vitals are not set in stone – which means they may change from year to year depending on what users expect out of a good web page experience.” — Search Engine Journal

WebPageTest is the industry standard for measuring site performance. The results are collected from real browsers running common operating systems.

Speed is about user experience (UX) not SEO. It’s about being polite to users. We don’t check speed with test scores. The only metric we use is milliseconds of load time as determined by

Here’s what we have to say about speed and SEO:



We haven’t found any advantage in using Next-Gen faddish image formats.

Next-Gen Image formats include:

  • JPEG 2000
  • WebP

They’re costly hand-waving at best. Getting 10-percent smaller image files does not increase speed by 10 percent. Images load in the browser in parallel. Well-optimized lossy JPEG images are still the best practice.



We’re not advocates of CDNs or server caching for speed repairs.

We solve speed problems using origin optimization. That means figuring out what needs to change about the basic strategy of a site. We don’t throw money at speed problems. We sell future speed strategy — not only repairs.

The way to proceed is to “think incrementally.” Rent a rowboat before you buy a yacht – just in case you get seasick.

Pick your slowest site affected most by bad speed. Let’s start there.


Let’s start with one site and a performance goal measurable in milliseconds.

Infinite Scroll plugins – and speed.

We’re testing the free Ajax Load More plugin. We’re not happy with the styling yet. But we’ll get that figured out.

We originally wanted an infinite scroll on PagePipe. But we couldn’t find a trustworthy and fast plugin then. We tested every plugin we could download from the WordPress plugin directory. And most plugins acted flaky, were slow, or didn’t work at all out-of-the-box. Ajax Load More plugin can be loaded on only the blog posts which is great. But we want to make sure it doesn’t do global loading (site drag) on all pages.

So now to get geeky and show you 2 desktop speed tests concerning this plugin:

1This test is a PagePipe blog post and has an infinite scroll feature on it. Notice item 9 in the waterfall. That is Ajax adding 754 milliseconds to the post’s load time. This is typical for Ajax. Note that TTFB is 1 second. Ajax calls affect server activity thus increasing TTFB, too. Fortunately, the rest of the page assets are ultralight. So the load time is 2.192 seconds. Not under our 2-second performance budget but close. Fortunately, much of Ajax appears to be lazy-loaded. But on mobile??


2Another geeky test in this demo: our testimonials page (normally very fast) where Ajax should not be loading because it’s a page — not a post. Repeat: Only posts are selected in the plugin controls.


Notice TTFB — same server — 664 milliseconds. Load time: 1.585 seconds.

Ajax for the plugin is NOT being loaded. This is a good plugin. It’s been built properly. It uses selective activation. Ajax is always bad for speed (WooCommerce uses it heavily globally). But if you going to use Ajax, only turn it on where it is needed. Don’t leave the lights on in empty rooms.

Someone who loves infinite scroll, Jon Dykstra:

One of my biggest wins this year was increasing time-on-site across my growing portfolio of niche sites. Gains: 58% to 330% increases. How? It’s so ridiculously simple. I added infinite scroll to individual posts on my sites. With infinite scroll, as visitors scroll to the end of an article, the next one (in the same category) comes into view. Because my content is so awesome they can’t resist and keep reading. The result: visitors stay and enjoy my sites much much longer. The benefit: I can’t say revenue increased but as far as I’m concerned, time-on-site is an important metric for any site. Any time I can increase it, I do. These gains are astronomical. –

And to be fair, someone who hates infinite scroll, Fatih Kadir Akin:

Footer is a very basic unit of web-page anatomy, just like a header. Sites keep some detailed information and links in the footer such as phone numbers, addresses, and help and support links. If users are searching for this detailed information, they mostly scroll down to find the footer. With infinite scrolls, users can have a hard time trying to find the footer. Infinite scroll makes finding the end of the page impossible. Not being able to reach the bottom of a website can make the user stressed (which is not great). –

Another good offsite link:

Dump livechat for page speed.

Remove third-party services like Hubspot, Jivo chat and Optinmonster. They are much more significant than font removal for speed improvement. They’re heavy and slow – and thus low-hanging fruit. Pareto’s law (80/20) of focusing on these assets gives a bigger return on investment.

Chat adds 1 to 10 seconds of page load time site wide.
So it gobbles up most of the performance budget.

Questions to ask yourself about chat:

  • Why do we need these plugins in the first place?
  • Do we know they get real results – or we hope they will?
  • If they get results, how significant is their contribution to profits?

Sometimes design compromise is a value call only you can make.

We’ve written about OptinMonster. We challenge the value of a feature with such an obvious poor user experience. It’s a distraction and intrusive. We’d like some serious fact-checking. Where are the scientific data purporting big improvements in signups from popups? Are these facts from monetized plugin affiliates? We bet audiences change their web behavior and ignore or dismiss popups. Some swear under their breath when unwanted screens pop up. They interrupt a search for problem-solving content.


Can you find ways to combine off-site services? For example, if you use Hubspot, they also have a chat function. Send one request instead of two for services. Value analysis is an industrial discipline using combination, simplification, elimination, standardization, and substitution.

When you do value analysis to make speed decisions, you’re being creative. Can you do “combination” of functions to lighten the load? That’s good problem-solving. If loading something heavy like Hubspot, see if you can get more mileage from it. Will it be lighter to use their livechat instead of adding another service like or Jivochat?

Do we have a recommendation for a lighter-loading live chat function?

Live chat is a bane for speed. We haven’t researched it much because it’s so awful. We think it’s going to die. Holler Box plugin has a “faux chat” function. We’ve found it a clever and fast alternative. But it’s not “live chat.”

Chat is very trendy and faddish right now. Much like sliders were in 2012. Both chat and sliders are bad for UX. Documented with user surveys and metrics, sliders prove inefficient. But chat hasn’t yet. It will be unpopular as people become blind from overexposure and poor results.


We have chat-insistent clients who gets no benefit in profitability. Their justification? They want chat to stay on their site because “everybody is doing it.” What did your mother teach you about peer pressure?

So look hard at the benefits (profit value) of these heavy non-features. Are there real numbers proving they contribute? Or just wishes and whims?


Providing chat service creates a customer expectation of no lag or wait time. Provide answers fast. If they’re lame or slow, then you create a negative user experience instead of a positive one. A negative is a liability.


REFERENCE: Overall performance comparison of the different chat widgets.

NameFCPJS TimeWeightChat displayed
Zoho Desk1.0s259ms67KB3.3s

Hotjar adds 497 milliseconds to mobile speed.

Just did a quick test. HotJar adds 500 milliseconds to your page load time – globally. THAT move blows 25 percent of the entire performance budget. You want to reconsider activating that plugin and API?

HotJar – an all-in-one analytics and feedback platform – provides heatmaps, visitor recordings, conversion funnels, form analytics, and more.

We find Hotjar often on commercial websites. Especially websites with speed problems.

What Alfredo Gutierrez of FunctionLabs says about the benefit of Hotjar:

Why user recording?

Hotjar allows us to literally see what people see, rather than guessing at what happens between pages.

Google Analytics shows the number of people who clickthrough or purchase, but Hotjar shows us friction.

It shows where someone scrolls to and between, what they see, and what happens when they do something.

This saved us numerous times. Here are two I recall:

– Android users would click on a button, which led them to bounce instead of go through to the next page. We didn’t test thoroughly enough, and turns out the email code would kick them out of the browser app entirely, and there was a bug where the back button wouldn’t work. iPhones would just pop up their Mail app, allow for the email to be sent, and immediately send the user back to the browser. We were about to stop Android traffic altogether because it didn’t seem like it was converting, but it was actually just an Android bug. So, we excluded Android from this particular funnel split test, and it converted again.

– We tested a new long-form sales letter. GA / Mixpanel showed low conversions on two of four variations. Policing that data with FullStory showed us that although the conversions were lower on the two, the users were much more engaged with certain page sections. We could’ve nixed the two variations and committed to a different hypothesis, but instead we took the section that saw a lot of interaction, and mixed it into the original variation. That resulted in a 27% bump in conversion.

Why does a small site / business need so much data recording?

My philosophy on this is that the smaller budget you got, the more data you need.

With our previous big business, we had so many media buys and so many transactions coming through, that we could ignore issues and still make a profit.

The smaller businesses have a much slimmer margin of error.

They’re also gun shy, and more demanding of information, even though traffic is about 3x more expensive now than it was 5 years ago. They want information after $1k adspend. They want to know which variation wins after 40 conversions.

They want to squeeze ‘insight’ from insignificant information.

So, user recording gives us a *direction* to go down, if we want to test something. Instead of a hunch, we can test something backed by something.

And when we do have a lot of information, it’s also a great policer of our assumptions.

Thanks, Alf, for sharing your knowledge about Hotjar benefits.

What others have to say about Hotjar and speed:

The one script Hotjar has you add to your site adds a tremendous 479k to the size of the fully loaded website. To put that into perspective, my site was only 1mb before adding the code. This means that hotjar is almost the same size as HALF OF MY WEBSITE!

Despite the asynchronous loading, you can feel that the website is sluggish when Hotjar is enabled.

So you have to ask yourself: “Do I value the data hotjar is providing over a faster website for my users?”

My website typically loads between 1.5 – 2.5 seconds without Hotjar, and up to 4 seconds with Hotjar – Andrew Curtin

“HotJar significantly reduced the loading speed of our website. This became a serious problem and we eventually had to remove it all together.” Patrick Eng, Marketing Technologist

“Snippet. Sounds small. Lightweight. Not a big deal, right? Well, wrong. One script alone adds just a tiny bit of extra to your load time, but scripts can really take a toll once they are combined.”

A lot of third party JavaScript means slow load times. The effects are cumulative. Be (very) conservative about embedding third party JavaScript – Janos Pasztor

“So for example, the Google Analytics Javascript is used by nearly two thirds of web sites within our sample; is 15KB in size; and takes 0.25 seconds to download on average, with 8.6% of the samples taking longer than 1 second. ” – Ari Weil

“Just like any JavaScript such as Google Analytics or tracking pixels… [Hotjar] is going to add load time to your website. There is no way of getting around that. Every script you add to your site, whether async or not, adds to your overall page weight.” –Brian Jackson

“Unfortunately neither you nor WP Rocket (nor any other caching plugin) can control the speed or performance of resources which are located on external servers (like Google, Hotjar or Facebook servers).” –Alice Orru

You insist you must have HotJar information? Fine. But after testing for 3 months, deactivate it. Test again in another six months if you must. Don’t just leave it sitting burning up speed. Give your site users a break.

Stressing out over outrageous humbug speed scores.

Can you fix 377 poor URLs – and get me some good green speed scores?

The majority of my blog visitors are on desktop browsers. Out of 700+ web pages – 377 are rated poor on speed tests. They all have vital problems related to site speed with *in the red* ratings.

My host won’t allow CDN.

For both mobile and desktop, I want fast load times – and high test scores (95+  in Google PageSpeed Insights).

I also want to serve WebP images and keep the existing theme and site builder.


You don’t need to spend $500 on our Plugin Surgery speed tuning services.

Improve your Top-10 most visited pages. Those changes affect the global site speed.

We don’t check speed with scores – or “greenness” – or big fat A’s. Our PagePipe speed strategy is unconventional and nonconformist.


The biggest reason to ignore speed scores is they don’t improve SEO or ranking. That’s governed by readable and desirable content. Are we preaching to the choir?

After relevant and quality content, what improves long-term SEO is user experience (UX). That is how a person feels when they use your website. Speed is a component in UX. So is readable content. Speed’s a hurdle or barrier. Some will never see your beautiful, clean site aesthetics – or read your riveting content. That’s a worst-case scenario. Visitors sense danger in their cynical and suspicious mind. Your slow page is a subliminal indicator of poor quality and apathy.

They assume your site is about to rob them – or steal their identity. Credibility is what overcomes those fears. Credibility is trustworthiness, expertise, and enthusiasm. But they won’t sit waiting. They need to feel it in an instant.

Speed then becomes a critical marketing differentiation. It’s how you feel when you walk into the lobby of a motel. Were you greeted at the entrance? Or did you wait while ringing a chime at the motel desk?

That’s *hospitality* and Hospitality Management is a career discipline. Speed is hospitality. You care enough to be present immediately. Instant attention.

So how bad is your speed? Is it above average? The internet norm is an 8-second page load. Ridiculous. What’s the longest people wait before 100-percent bailout? 10 seconds.

People are impatient. They won’t wait. Their expectation is 2 seconds on desktop and mobile. They begin bailing out at that point and all disappear by 10 seconds. That’s for the initial page they land on. After that, they’ll tolerate 3 seconds if they think they’ll find what they seek. That’s information scent. Speed is a strong precursory cue delivering *the right scent* — like with a motorized fan. No waiting for the yummy scent to waft through the internet.

Information scent REFERENCE:

So if scores don’t matter, what does?

The next erroneous assumption is “requests” are the best indicator of performance improvement. That metric isn’t valid either. A site with a ton of requests can load fast.

All that matters is milliseconds of load time first. And second, for mobile-users: page weight.

Do tests claim you have vital speed problems for mobile? Are you certain they are real problems that make a difference in profitability? Remember, scores are meaningless to us. Milliseconds load time is the metric. But even more than that is profit.

So let’s answer those speed questions:

1You can’t use CDN. That’s great. Not using CDN is a blessing in disguise.


2You want to use webP format? Why? WebP format only improves image page weights by 10 percent. Because of parallel image loading in browsers, this gain is insignificant. It’s not worth it. It doesn’t even translate into a 1 percent gain in speed (milliseconds).

3Not changing your theme or removing your pagebuilder is whimsical. It’s like saying, “Don’t do serious speed tuning – instead give me a speed miracle.” But you’re right, we charge for miracles. $500.

4What should you do instead? For better speed, get rid of the following popular heavy plugins or find substitutions:

Contact Form 7

Social Warfare
Is social media earning you money?

Alternative plugin:

All In One SEO Pack

Shortpixel Image Optimiser
FREE PDF in this article page:

Alternative Plugin Recommendation:

Now check the following for even more speed:

Substitute web fonts with a mobile system stack.

Load Google Analytics ID faster.

Remove Emojis.

Do you have a globally-loading Ajax library?

Should I Use Generatepress or Astra theme with Elementor for mobile speed.

“I was thinking of using a theme like GeneratePress – or Astra. They seem to be the fastest but, now I’m unsure.”

Free Elementor is 61 milliseconds and adding paid Elementor Pro delays another 71 milliseconds. That slows down every page by 132 milliseconds.

GeneratePress (22 milliseconds) and Astra (36 milliseconds) are plenty fast. But only when using the free versions. If you buy the GP Premium plugin you add an additional 70 milliseconds. Buying Astra Pro adds 50 milliseconds to the free version. The theme authors don’t tell you those speed details. But that’s still minor compared to the real problem.

Should I use GeneratePress or Astra theme with Elementor for mobile speed?

For comparison, WordPress core loads in 215 milliseconds. Five times slower than your speed theme.

A typical free, discrete, single-function, no-setting plugin loads in less than 0.5 to 2 millisecond.

25 percent of plugin speed overhead is often consumed by one plugin.

80 percent of total plugin load time is burned by your 5 heaviest plugins.

The average WordPress website has 25 plugins.

Of PagePipe’s 70 total plugins, 12 load in under 3 milliseconds each. And 29 of the 70 load in under 1 millisecond each.

There’s usually one big-fat plugin killing speed – like WooCommerce 262 milliseconds – or more. Or perhaps Yoast SEO Premium plugin loading in 240 milliseconds.

We repeat. These plugin speed problems are minor compared to the real problem:

Speed killers: Undisciplined, novice site owners.

They’re the real problem. And some professional developers are apathetic about quality, too. You can do anything and everything dreamed of with a pagebuilder. That should be good. Right? But start adding incremental features and soon the site is overweight and slow.  It’s not one slow thing – it’s everything. Egomania. Then site owners ask us, “Can you fix this Elementor speed problem?”

Sorry. It’s not Elementor’s fault. They didn’t make you put in all that web junk. They only tempted you.

WP Rocket is a $49 speed plugin with annual renewal (rent overhead). Most don’t realize WP Rocket caching plugin adds 109.1 milliseconds to global page loads. The irony.

Can you fix speed on a bloated Elementor site? The answer is probably “no.” Pagebuilder plugins can’t be selectively deactivated to reduce site heaviness. Not without white screening an entire site anyway. Discrete plugins can be selectively activated or deactivated on pages and posts. This is important for speed. It’s not the evil your pagebuilder does, it’s the goodness that got left out. It’s a sin of omission.

In fairness, Elementor doesn’t activate their widgets on pages where you don’t use it. But that’s not the same as selective activation. If you must use Elementor, don’t use it on your most-popular landing pages. Use good judgement for speed.

Desperate site owners throw money at speed problems. Usually by adding CDN, caching, or more expensive hosting. Things get costly. The speed investment is worse instead of better. Discarding whimsical features prevents speed waste.

How do I build a fast website from the start, without using a full-time developer?

What is the right decision about builder plugins?

Our speed advice is design without a pagebuilder whenever possible. Pagebuilder’s are slower, add more requests, and have a big learning-time commitment. But if you have no idea what you’re doing and are new to the game, go ahead – be a make-believe designer with a pagebuilder. It’s OK.

Pagebuilders are not the speed panacea you seek.

Will your pagebuilder site be slow? Most likely. The odds are high it’ll be slower than you ever dreamed. Why?

The answer: Because you own a rifle doesn’t make you a hunter. Just because you own a car doesn’t make you a racing champion. Owning a pagebuilder doesn’t make you a skilled web designer.

Using a pagebuilder doesn’t guarantee design quality. No surprise. There’s a pagebuilder learning curve. You still need to learn good universal design principles – aka best practices. It’s disappointing when your site is of low quality. You need a speed strategy before you start. Say, “No!” to dull, faddish fluff that doesn’t matter and adds no real value.

How do you design a website to be fast from the start? Building for speed is called “origin optimization.” It happens even before the project begins. It’s not an emergency, after-the-fact, speed repair. It’s strategic.

Here’s what to do for WordPress origin optimization:

1Get the best shared hosting you can afford. What’s best? Find a normal host allowing writing to the .htaccess file on your server. Special hosting – like WP Engine – won’t allow this. That ability is important for plugin speed tricks. Don’t choose SiteGround. Their wild TTFB fluctuates and is erratic. Their servers are worse than mediocre for TTFB.

2Choose a host with stable TTFB (time to first byte) on your server. Excellent is 200 to 300 milliseconds. Ordinary is 500 milliseconds and poor is around 1 second or longer. One way to find out is by testing the hosting company’s home page TTFB using That’s the best possible it will ever be. Do at least 6 tests. gets about 500 millisecond TTFB on GoDaddy (blog) and 1.7 millisecond TTFB on BlueHost (store). We host at these services to prove our point. You can get good-enough speed on cheap shared hosting.

3Do NOT install SSL certification  – unless you’re doing ecommerce. You don’t need SSL for simple email signups. SSL handshaking slows down your site globally by 500 milliseconds average. SSL does NOT improve your SEO. There’s no proof. But you can measure the heavy toll on speed.

4Don’t put an email signup API (like MailChimp services) on every page.
Have a single page with signup and use image or text links to that page. Use selective activation and only turn on your email plugin for that one signup page. Isolate the site drag.

5Use Twenty-seventeen default theme (48.4 milliseconds – after stripping Google Fonts). Live within its limitations. There are tons of articles online about how to customize Twenty-seventeen default theme. Why use it? Longevity. It’ll have an 8-year shelf-life. Don’t use Divi theme. It has a 1-second load time. Yes. That’s only the theme: Half your performance budget gone! Any theme is faster than Divi. Rather consider longevity a high value. Astra and GeneratePress are cool and fast. But they don’t have the potential longevity and risk-reduction of Automattic authorship.

NOTE: We’ve tested Twenty-nineteen theme for speed. While it is not as versatile as Twenty-seventeen, it loads in only 15 milliseconds. Dang fast.

Do NOT use free Cloudflare. It slows down your site with delays and 501 errors.

Thanks for your time and feedback. You are definitely right about speed inconsistencies with free Cloudflare!”, Portugal

Buy our ebooks.
Serious. Enjoy our research. Get the bundle and also buy “Toxic WordPress“.

When in doubt about some feature or frill, leave it out. What makes for a good website is content, not fancy things that move or animate. Like sliders, rotators, accordions, dropdowns, etc.

9Optimize your images with free “Imsanity” plugin. Other optimizer-plugin promises are seductive – and cost money. Don’t use free Smush plugin. Don’t use PNG format for photos. Use JPEG images and compress quality using your judgemental eye – and not a robot machine for a brain.

Can you survive without social media links? Do you have to have comments? Are you using Avatars (Gravatars)? These extras slow down your site and add little value.

Don’t use heavy, globally-loading plugins like Contact Form 7 plugin. Don’t use Yoast SEO plugin especially the paid version (or any SEO plugin). Don’t use a multi-function security plugin or any multi-function plugin. Stick with discrete plugins. Use more plugins – not less. Doubling the number of “good” discrete plugins will halve your load time. That’s right. 50 plugins are better than 25 if you choose the right plugins. Our ebooks are about this stuff. And the PagePipe blog is full of free plugin information. Buy both the “plugin alternative” bundle – and Toxic WordPress.

Paid Yoast SEO plugin is the speed equal to 250 discrete plugins. Bad site drag.

Accept that your learning journey requires frustration and failures. Nothing worth doing is easy. There’s a price. Pay your dues by investing in your brain power. “You” have future value.

BONUS TIP – If you use WooCommerce plugin, the best speed you’ll often achieve is 3- to 4-second load times. Reduce your expectations.

A conversation with Arisara Thitimoon about speed, Elementor, and Astra theme:

Arisara: Just purchased the bundle, I can’t wait to get into this!

Steve: Thanks for sharing your speed learning and web adventures. Also, thank you for caring about speed. It’s all about being kind to users and showing them you want to provide a good experience. They sense that when the site loads.

Arisara: First of all thank you so much. After days of researching why my site was !@#$%^*, I finally come across your article that helped me understand that a website built with bloated code is unfixable and is better off being built in a clean manner.

Steve: I wish more readers would realize this. I usually get requests to fix the impossible. Web miracles!

Arisara: What I do: I work on small projects $1000 to $2000 and so workflow speed plays a significant role in how much my hourly rate is effected. This is why I opt to use a pagebuilder (Elementor Pro). I use this in conjunction with Astra Pro and the combinations is damn near perfect for my type of projects.

Steve: This is a good combination. We’ve used it before and we’ll use it again on some client sites. But not all sites need these methods. Some can be simpler.

Arisara: But I’m not satisfied with performance … I’m learning that a pagebuilder needs to be used with respect and my goal is to master every little detail that allows to build a clean website that loads fast.

Steve: Value analysis is something we borrow from industrial manufacturing. It’s a discipline to improve profitability and efficiency. It consists of 5 things: combination, simplification, elimination, standardization, and substitution. It’s attention to details and creativity combined. Those use two different sides of the brain.

“Respect” is the keyword. If you use strategy, doing value analysis on features and functions, you’ll build a fast site. Assuming your host doesn’t have a TTFB of 2 seconds or more. But many shared hosts have TTFBs below 1 second. 200 to 500 milliseconds is ideal. You can find out by using and type in the URL of the host’s homepage. Their speed will never be better than that. And of course, avoiding SSL if you can.


Arisara: My speed goals is 2 – 3 seconds per page.

Steve: Good goals. This is the performance budget. Everything you add nibbles into that budget.

Arisara: My speed question: What is your advice to an Elementor user for building fast sites and avoiding bloated code and crazy amounts of HTTP requests?

Steve: I steer clear of pagebuilders when I build solo. But my colleague, Matt Stern, uses this combination often. Elementor makes my speed job more challenging. If it’s a WooCommerce site then we’re fortunate to get under 3-second load times with Elementor.

Here’s a free plugin to help you create or restore the look of your multi-column homepage without Elementor:

It is authored by Tom Usborne, the developer of GeneratePress. While it
is possible to handcode this “CSS3 grid,” the plugin simplifies
everything. No pagebuilder needed or extra paid addons. Much faster
loading solution.

Keep reading below for more ideas.

Arisara: So far in my research, I’ve learned to use Astra features as a first priority (so create headers and footers in Astra, set up typography, etc)

Steve: Yes. You are on target. Here’s a quote from Matt Stern, my collaborator:

Here’s what I like about Elementor and Astra, having used them on different projects.

Elementor benefits:

• Allows you to customize the entire theme (not just specific pages), this means you can use a drag-and-drop interface to customize your header, footer, blog layouts and more.

• Allows you near complete control of woo-commerce pages. See custom woo product page here: Again, you may not need this feature yet, but it will be a game changer if you decide to update your product pages.

• Leaves behind “clean code,” which can be reused if necessary. Divi leaves behind shortcodes which only apply to Divi and can’t be used elsewhere.

Astra benefits:

• Designed to be both customizable and fast. The fast part is an important consideration that many themes (even popular ones) seem to forget. One way Astra does this is by making some of its features modular. For example, if you don’t need to customize a particular aspect of a site, say the typography or the blog layout, you can turn “off” the customization for that specific part of your site, keeping your site leaner. See more here:

• Good Woo-Commerce customization “out of the box.” While Elementor allows for more in depth customization that take longer to implement, Astra has a nice set of options that are quick and easy to customize. was customized primarily with Astra and only used Elementor for certain pages.”

Stern Design

Steve: It takes good planning and cautious testing to not enqueue jQuery with a feature or plugin. Astra says their theme loads in under 500 milliseconds. But our real-world research shows it loads in less than 50 milliseconds! It’s WordPress core that adds the extra load time – about 300 milliseconds.

Arisara: Use custom CSS in my customizer to set default styling in elementor (btns, section padding, etc) so I don’t have to restyle every single element

Steve: Good job.

Arisara: Ditch the gimmicky features Elementor offers.

Steve: Amen. Try to avoid installing the Pro version if you can. Not only does it increase annual overhead $$$, but it doubles the load time of the free version.

Arisara: Reduce unneeded functionality like carousels, etc.

Yep. Sliders suck for UX and everything else that moves. Use static images instead.


Arisara: Disable fontawesome (got this from your article ).


Arisara: Optimize all images. I do this using Shortpixels site (everything on lossy).

Steve: ShortPixel plugin is good. But it isn’t always the best alternative. It adds 30 milliseconds of site drag to every page – if you keep it active. Resizing and compressing in a standalone image processor offline is always best (Gimp or Photoshop, etc.). Machines don’t make good decisions. One size doesn’t “fit all” in the image compression department. It requires a human eye.

REFERENCE: << about ShortPixel

Our preferred stopgap to prevent uploading oversized images is Imsanity plugin. It’s only necessary if you don’t control the media library.


Arisara: Avoid bloated plugins

Steve: Absolutely. Meaning avoid “popular” plugins.

Arisara: Don’t put complicated things in footers.

Steve: Good. Like email signups (MailChimp, etc). Use a central signup page and link to it instead.

Arisara: Disable any theme options / plugin / widgets that are not active.

Steve: Right.

Arisara: Reduce animations.

Steve: Mentioned that. No moving elements.

Arisara: Avoid all performance plugins (leave them till last).

Steve: Yes. And some speed plugins help scores – not milliseconds. Like minification, caching, etc.

Arisara: Don’t use a CDN (at least not right away).

Steve: CDNs are indicators the site wasn’t built for origin optimization.

Arisara: I’m probably barely scratching the surface. But if you have any tips, I would HIGHLY appreciate your expert opinion!

I’m really getting passionate about creating high quality designs and I’m prepared to invest the necessary time it takes to learn how to do it. So excited to read your ebooks.

Steve: Be patient. There ‘s a learning curve and new vocabulary. But I feel confident you’re a talented person and will be building “good stuff” soon.

Is there a reason we don’t like Astra for longevity?

Astra is a fast theme with 1 millon+ active installations. That seems remarkable. And it is.

We know the theme (without WP core included) loads in under 50 milliseconds. Much faster than advertised. Bless them!

If you buy the pro version, it doubles the load time. If you buy their pagebuilder (templates?), things get slower and slower.

How many people support this theme? 45 according to their about page. And they’ve been in business for many years. That all seems pretty good. But is it better than WordPress theme authorship for long-term updates? No one matches that. Especially for default themes. Astra is NOT bad – but they don’t have the strong future of WordPress / Automattic. WordPress has a market valuation of over 1 billion dollars.

We use Astra on client speed sites. But not on our own sites, we try and stick with customized default themes. Not everyone codes. We can write CSS and figure things out. So it’s OK for us – but not everyone.

We include Astra on our *list of goodness*. Along with GeneratePress – who is only one guy and an assistant. But Tom Usbourne only supports one theme and that’s it. We also recommend Tiny Hestia and Twenty-seventeen default theme with Google Fonts stripped. They’re all about the same speed as Astra.

If Tom gets run over by a bus, GeneratePress is dead, too.

If all of San Francisco, USA (Automattic’s headquarters) fell into the ocean, miraculously the WordPress torch (core) will be picked up by others around the globe and carried onward. That’s a harsh incident we hope never happens. But it demonstrates how bulletproof WordPress is today and tomorrow.

We don’t hesitate to use Astra on a client site. But rarely our own. Hmm? What does that say about out opinion?

WP Buff’s $2,898 Speed & Security slick deal.

This is a heads up.

We have no vendetta, grudge, or beef with WP Buffs.
They seem like nice people.

But, WP Buffs baited us with email offers to sign up for two juicy PDF downloads. Curiosity got the best of us. Does our advice – about free plugins and themes – address the exact same problems?

Both WP-Buffs ebooks are 7-pages, color, and A4 size. Nice graphics. They tell you the same stuff we do. But they left something out: the good information solving the problems listed. Oh, we see now. We buy their stuff and it’s supposed to solve all our problems. How much? Read on:

The biggest difference is the price of their recommended solutions. In PagePipe articles – we focus on free ways to get speed and security. Let’s examine the two WP-Buffs colorful downloads below:

  • “The 21-Step Checklist to Ensure a 99.9% Secure WordPress Website”

Example page


The promise: WP Buffs implies reading these PDFs makes your site 100% secure. They don’t mention it costs you $1,553 US dollars.

This is the checklist below. You add these features purchasing the three recommended paid plugins or paid services. WP Buffs then receives a sales commission or finders fee.

  • Daily Cloud Backups
  • Force Secure Passwords
  • Daily Malware Scan
  • SSL Certificate
  • Database Protection
  • Real-Time Monitoring
  • IP Blocking
  • Brute Force Protection
  • Install a Firewall
  • Custom Login URL
  • Daily Link Scan
  • Blocking Fake Google Crawlers
  • Comment Spam Filtering
  • Daily Plugin + Theme Scan
  • Authentication Keys + Salts
  • Daily Database Optimization
  • 2-Factor Authentication
  • File Permissions
  • DNS Change Alerts
  • Verify Trusted Sources
  • Manage Inactive Plugins

Note: These security features sound wonderful and amazing. They’re overkill. These practices are notorious for server overages and resource consumption. They slow down both TTFB (time to first byte) and page loads. Please, don’t do it! Save your hard-earned bucks.

WP Buffs publishes 3 affiliate links for you to click. WP Buffs earns a commission if people end up buying the advertised service or product. This sales tactic is also called revenue sharing. It’s a way to make a profit.

Their affiliate link solutions for security:

  1. iThemes Security Pro plugin.
    $588 per year annual rent.
  2. Malcare malware detection plugin
    $96 per year annual rent.
  3. WP Security Audit Log service
    $89 per year annual rent.

TOTAL recurring annual fees: $773 US


WP Buffs makes an offer to secure your personal website or a client site as an extra paid service. They ask you to set up an appointment call. The goal is to sell you a maintenance and service plan for $780-per-year annual rent.


You can get this for free doing it yourself.






$9.95 PagePipe ebook:

WP Buffs has affiliate links for managed WordPress hosting services on its website. We do not recommend any of the 6 they mention for speed. They’re expensive and you can get equal speeds for less elsewhere.

  • “The 12-Step Checklist to Achieve Loading Times Under 1 Second”

Example page


The promise: WP Buffs implies reading their PDFs makes your site load in under 1 second. They don’t mention it costs you $1,345 US dollars.

This is the checklist below. Add all these features by purchasing the three recommended paid plugins or paid services. WP Buffs then receives a sales commission or finders fee.

  • Optimize Images
  • Minify Javascript and CSS
  • Render-Blocking Resources
  • Leverage Browser Caching
  • Enable Compression
  • Reduce Server Response Time
  • Remove Query Strings
  • Optimize Mobile Experience
  • Combine Requests
  • Lazy Loading Images
  • Inline Critical CSS
  • CDN Support

Their affiliate link solutions for speed:

  1. WP Rocket
    $49 per year annual rent.
  2. WP Smush Pro
    $588 per year annual rent.
  3. Astra
    $708 per year annual rent.


You can get this for free doing it yourself.



$9.95 PagePipe ebook:

$9.95 PagePipe ebook:

We wanted to know how they achieve these cool things. But alas, they don’t tell you how – only what you should buy. To get the things done, you must hire them – or click on an affiliate link in the PDF.

Our delight fizzled. This is mere bait. No answers at all. Not knowledge – a mere sales pitch.


Their gold-standard metrics: PageSpeed scores. An absurdity we despise. It’s load time in milliseconds that count for us.

And some stuff they suggest is contradictory. Many ideas presented won’t make your site more secure or faster. At least, not without a fat price tag attached to it. Actionable recommendations are affiliate links to premium paid plugins or services. As speed engineers and web developers, we don’t appreciate this sales tactic.


It’s a fluffy self-promotion piece. Marketing hype. We wanted technical solutions. Dang, it! We’re disappointed. Same old hype from other blogs. We wanted to learn something new or clever. Sadness engulfs our speed souls.

So if you want to find out how to achieve these marvels for free start by reading PagePipe. Visitors often binge read our entire site content. Are you obsessed with speed? Join us.

CONCLUSION: Keep your money in your pocket. Learn how to use duplicate plugins that achieve the same WP Buffs goals for free.

Popular plugins slow down your server – and delay TTFB.

A site is in serious trouble. Seventeen of 33 plugins have package sizes above 100k compressed (gzip). The site’s pages slowly load in 29 to 47 seconds. All pages are dragging beyond belief.

Time To First Byte (TTFB) is a measurement of server delay. We call it server speed overhead. We subtract it from our performance budget. The budget is 2 seconds. Sadly, the TTFB for this site varies from 2 to 6 seconds. Do we have to change hosts?

Is this site bad?

Rotten! Horrific! One of the worst we’ve repaired. The client is on GoDaddy hosting. We use GoDaddy hosting. It’s never that bad. We ask GoDaddy to check the server. They say it’s fine and dandy. There are no other domains on the server. They claim junk code in the server htaccess file is slowing everything down. We check using:

HTaccess Editor

What we should see 10 lines of code in the HTaccess file contents. That’s the standard WordPress code (below).

Instead, we see 23,376 extra lines of code.

Where is this garbage coming from?

We clean out HTaccess. Then iThemes Security plugin puts all that junk right back instantly.

iThemes Security plugin is writing to the HTaccess file as if it were a wastebasket. Incredible confusion. Is it the plugins fault? Unlikely. It’s a slow and fat plugin but it isn’t that ugly. We guess an “operator error.”

Someone made settings for this plugin on overload. Why? Paranoia from being hacked and fear of getting hacked again with malware. A knee jerk overreaction into the red zone. Amazing security! We’ve written about this nasty speed-hog plugin before:


We run some tests ascertaining what other plugins slow things down on this errant site. But first let’s look at each plugin’s download size.

Plugin Name,zip file k,percent
iThemes Security Pro,3300,15.21%
WP Rocket,2400,11.06%
All In One SEO Pack,1500,6.91%
Better WordPress Google XML Sitemaps,1500,6.91%
Really Simple SSL,529,2.44%
Popups – WordPress Popup,438,2.02%
Sucuri Security,377,1.74%
Lazy Load by WP Rocket,341,1.57%
Polls CP,236,1.09%
Swift Mailer,230,1.06%
Custom Permalinks,193,0.89%
Contact Form 7,183,0.84%
WPFront Notification Bar,178,0.82%
iThemes Sync,157,0.72%
Post Expirator,97,0.45%
Akismet Anti-Spam,74,0.34%
Display Widgets,46,0.21%
Velvet Blues Update URLs,28,0.13%
Simple 301 Redirects – Bulk Uploader,26,0.12%
Classic Editor,19,0.09%
Contact Form CFDB7,15,0.07%
ETH Redirect to Latest Post,11,0.05%
Simple Banner,10,0.05%
Insert Headers and Footers,9,0.04%
Honeypot for Contact Form 7,8,0.04%
Simple 301 Redirects,5,0.02%
No Category Base (WPML),4,0.02%
Postman SMTP,2,0.01%
Total zip package file size,21696,

How much do popular plugins damage your site speed? We can guess by looking at their download zip folder size. Notice most of these below are huge megabyte zip file sizes.

There is a direct correlation between plugin popularity and slowness. The more popular the slower it is. They’re the bigger resource hogs on the server. They destroy good TTFB.



NAME, active installations,zip file wt
Contact Form 7,5+ million,181k
Yoast SEO,5+ million,3.1 MB
Akismet,5+ million,72.7 KB
WooCommerce,5+ million,7.2 MB
Jetpack,5+ million,7.6 MB
Elementor,4+ million,4.8 MB
Wordfence Security,3+ million,4.5 MB
Contact Form by WPForms,3+ million,4.3 MB
MonsterInsights Google Analytics Dashboard,2+ million,2.3 MB
UpdraftPlus,2+ million,6.6 MB
All in One SEO Pack,2+ million,1.2 MB


What are the load times of the plugins used on this site under test:


Theme Enfold Child,770.70,,
WP core,549.30,,
WP Rocket,124.00,13.19%,56.41%
iThemes Security Pro,98.50,10.48%,53.69%
All In One Seo Pack,81.60,8.68%,62.37%
Contact Form 7,79.90,8.50%,70.88%
Sucuri Scanner,26.40,2.81%,77.07%
Postman SMTP,26.30,2.80%,79.87%
Custom Permalinks,24.60,2.62%,85.12%
Bwp Google Xml Sitemaps,19.50,2.07%,87.20%
Popups WordPress Popup,17.50,1.86%,90.92%
Lazy Load by WP Rocket,15.70,1.67%,92.59%
Really Simple Ssl,15.20,1.62%,94.21%
Ithemes Sync,11.30,1.20%,95.41%
Simple Banner,8.70,0.93%,96.34%
WPFront Notification Bar,8.60,0.92%,97.25%
Akismet Anti-Spam,6.70,0.71%,97.97%
Polls CP,6.20,0.66%,98.63%
Post Expirator,6.10,0.65%,99.28%
Velvet Blues Update URLs,3.60,0.38%,100.13%
Contact Form Cfdb7,3.40,0.36%,100.49%
Classic Editor,2.00,0.21%,100.70%
Insert Headers And Footers,1.90,0.20%,100.90%
Eth Redirect To Latest Post,1.70,0.18%,101.09%
Display Widgets,1.40,0.15%,101.23%
Simple 301 Redirects,1.30,0.14%,101.37%
Swift Mailer,0.90,0.10%,101.47%
Simple 301 Redirects Addon Bulk Uploader,0.70,0.07%,101.54%
No Category Base (WPML),0.40,0.04%,101.59%
Contact Form 7 Honeypot,0.30,0.03%,101.62%
grand total theoretical site drag,2259.80,,


Notice that Enfold theme load time is nasty: 770 milliseconds. We’ve only seen one theme worse. Divi’s one second load time!

You can test TTFB with or

Many popular plugins often do calculations and file data on the server. These delays don’t show up in a speed test waterfall. Find out how fat plugins affect your site by checking server resource usage in server Cpanel. But one sure indicator is time to first byte gets unacceptable. A good TTFB is around 200 to 300 milliseconds. Average TTFB is 500 milliseconds. And bad news is anything over a second. This site is 6 seconds!

So what’s the alternative?

Use fast-loading discrete plugins instead. These are free single-purpose plugins that usually have no settings. They load in around 1 millisecond and the zip folder size is definitely under 100k – more like 10k. You only install the features you need. One plugin per feature. You don’t throw in the kitchen sink with over-engineering and gold plating.

But isn’t using many plugins worse than using one plugin? No. You could load 250 one-millisecond discrete plugins instead of Yoast SEO plugin. Think about it. You don’t need but a few lightweight plugins to duplicate the fat plugins features.

For example, the AMP plugin mentioned above doesn’t help mobile speed. Instead it slows down the page by 400 milliseconds because it’s so complicated. We suspect it also loads down the server. We don’t need to replace or substitute this plugin, we need to remove it. That’s right. Get rid of that Google-Dog plugin. It’s not helping anything.


We get busy removing the bad plugins and replacing them with discrete plugins. We trash the following plugins:

  • AMP
  • WP Rocket
  • Sucuri Scanner
  • Akismet
  • Lazy Load by WP Rocket
  • Optimus

What happens to speed?

Global page loads drop from 38.7 seconds average to 5.7 seconds.

We next pull the iThemes Security plugin and replace it with 4 discrete plugins.

Speed gets even better:

3.5 seconds average. 10 times faster page loads.

Can we make the pages load in under 2 seconds? Yes. But we need to remove the SEO plugin – and replace the theme and pagebuilder. That costs too much time, energy, and money for this client. So we postpone these recommendations until a future rebuild.

We now understand how popular plugins slowdown TTFB (server overhead). Hurrah! You won’t need to move from your hosting provider after all.

Some managed hosts blacklist plugins to prevent the installation of vulnerable and disruptive plugins. Disruptive means server resource hogs. These include WordPress Popular Posts, Broken Link Checker, and Google Sitemap Generator.

You may ask, “How do we reduce server activity during backup when the media library is super big?”

Good question because that can slow down TTFB, also.

We use three free plugins to reduce a server’s burden during backups:

We set site automatic backups to happen every week. We know if we lost one weeks worth of activity it wouldn’t damage us too much. Sad? Yes. But not ruined. That one-week interval reduces the amount of time the plugin is hitting on the server. (6.6M zip folder download).

UpDraftPlus takes into account server throttling and potential shutdowns. It doesn’t cause overruns of server resources. It sends packages in segments and waits for the server to recognize it’s not under attack or overload. Then it sends the next backup package (zip folders).

Set the weekly start time to a day when you know you have the least site traffic. On smaller sites, with few changes, we update monthly. Do you really need daily updates?

We retain two backup copies on remote cloud services (free Dropbox). But quarterly, we download a backup to our computer desktop for archiving. Don’t save backups to the same server you host on except for disposable copies. Be safe.

2Exclude Image Thumbnails From UpdraftPlus Backups
This small 1.6k plugin excludes WordPress generated image thumbnails from Updraft backups, saving space. The original, full-sized image is included in backups. If a restoration from backup is needed, a thumbnails plugin is used to regenerate thumbnails using the original, full-size images. The plugin works for all image formats. It includes both native and custom image sizes added by themes and plugins.

There are 4 WordPress default image sizes normally created by core: original, large, medium, and thumbnail. Every time an image is uploaded these are placed on the server. Server space is not an issue. Resource consumption during backup and restore is a potential problem. We’ve seen themes (like Enfold) automatically create up to 18 different thumbnail sizes whether they’re used on pages or not. This bloats the media library backup.

3Regenerate Thumbnails
Regenerate the thumbnails for your image uploads. Useful when changing their sizes or your theme. Regenerate all thumbnail sizes for one or more images uploaded to your Media Library. We keep it disabled and use it only when needed. (79.2k zip download).


PagePipe’s latest mobile speed strategy – and free plugin discoveries.


Mobile Speedsters – Join us. Freebie.

If you enjoy our caustic speed articles, you’ll love our pithy bi-monthly newsletter. Discover what matters most for mobile WordPress page speed. Fast load times require more than just installing a caching plugin – or CDN.

We’ll share with you our latest speed experiments and discoveries. Stay up-to-date with what matters for mobile WordPress page speed.



WooCommerce hurts speed. Freebie.

9 WooCommerce Speed Tips

1. Remove global SSL bloat.

2. Disable AJAX cart fragments.

3. Defeat minimum password strength.

4. Disable Auto-Embed script.

5. Avoid these cache problems.

6. Effective trust signaling.

7. Improve your call to action.

8. Relevant custom product photography.

9. Selective deactivation.

WooCommerce is a slow, lumbering beast. Discover 9 ways you can speed it up today.

Learn more and get your free WooComa download.


Yoast SEO plugin won’t save you. Freebie.

Our controversial free report challenges a commonly-held web belief. That’s the falsehood you need an SEO plugin (like Yoast) to succeed online. Discover why SEO plugins won’t save your business and what you can do instead.
And speed up your site!

Learn more and get your free Search.Me download.

Speed technology downloads.
With no-nonsense.
And no-spam-ever.


Google self-serving HTTPS security compliance destroys web speed.

Google edicts! We’re sick of them. The HTTPS speed penalty is incredible. To us, it’s horrible and appalling. There is a myth HTTPS / SSL Certification makes no increase in page delays. Our testing says otherwise. Read on.

“HTTPS sites also load significantly faster. In a test on HTTP vs, the unsecured version of the page loads 334% slower than HTTPS.” – A3 Creative Solutions

They have to be joking!

“HTTPS did have an impact on my page load times, however, the difference is negligible and I only noticed a 300-millisecond difference.” – Dean Hume

We’d sell our grandmother for 300-millisecond gains. Well, we’d dump Google Fonts anyway.

I need to make an apology … On Tuesday, I switched Blogging Wizard over to SSL (https). But in the process, I managed to crash the site completely… twice. Yep, twice”. – Adam

The quotes above reveal the foolishness of many people about site security and speed. HTTPS / SSL server handshaking creates an initial stall in making Internet connections. There’s a slow delay before anything starts to render on your visitor’s browser screen. This delay is measured in Time-to-First-Byte information (aka TTFB).

DISCLAIMER: HTTPS/SSL is constantly improving. Please test your host’s – or potential host’s – server. The best-case is their homepage. Use that URL with to see what’s happening.

The SSL delay is specified in the waterfall diagram of the Time-to-First-Byte measurement. Time to first byte is a measurement of server overhead or delay. SSL delays on quality hosts now are as short as 50 milliseconds. But not all hosts are equal.

PS- Notice ByteCheck doesn’t use SSL on their test site. That implies how they feel about SSL.

The HTTPS overhead (delay) is NOT due to the encryption. The overhead is due to the SSL handshakes. An extra time-to-first-byte delay of about 400 to 500 milliseconds is common. Sites that were under 100 milliseconds TTFB are now over 500 milliseconds TTFB. When your performance budget is 2 seconds, that’s 25 percent waste.

HTTPS is slower because it does double the work. A normal HTTP request does a “2-leg” delay for network connections. This a round-trip request and response. With HTTPS, you have 4-legs (2 round trips). It’s 100 milliseconds to travel between the client and the server. That means your first HTTPS request is up to 500 milliseconds.

HTTPS handshake overhead appears in Time-to-First-Byte information (TTFB). Common TTFB ranges from under 100 milliseconds (best-case) to over 1.5 seconds (worst case). But, of course, with HTTPS it’s worse.

Roundtrip, wireless 3G connections can be 500 milliseconds or more. The extra trips double delays to 1 second or more. This is a big, negative impact on mobile performance. Very bad news.

And to make matters worse for return visitors – and clickthrough to other web pages – HTTPS can’t be cached. It slows every single page always.

To put those times in perspective, a free WordPress theme loads in under only 50 milliseconds.


SSL by Default Usage Statistics

[Note: Click that All Internet stat button.]

Big companies are the most compliant. Why? We suggest SEO PARANOIA. Fear of Google. Yep. Google has too much power. But you already knew that.

Don’t make the switch to HTTPS only for SEO purposes. It’s a resource-intensive process and there’s no strong correlation between the two. No benefit.

This hardly means everyone is using HTTPS.

Google announced using HTTPS as a “lightweight” ranking signal in search algorithms. Google stated if all factors are exactly equal, HTTPS will act as a tiebreaker in search engine results. That was in mid-2014.

Google didn’t get significant compliance after 2 years. So, they incentivized moving from HTTP to HTTPS. Google Chrome browsers started shaming unencrypted HTTP websites. How? With a little “shield icon” in the Chrome address bar. See the chart below.

How Google scarlet-letter shaming looks today:

This “not secure” warning appears only if form fields need populating. No form on the page? Then no scary warning.

So how do we get around not having SSL warning on PagePipe blog? We don’t use forms. We use text email links and protect them from spammers with this plugin:

Email Address Encoder

Doesn’t not using SSL Certification affect our SEO? Not in the least. Google said if everything on two sites is equal then SSL tips the scale for ranking. When are two sites ever exactly the same in Google’s 200-factor PageRank algorithm? (Factors are also known as signals). NEVER!

According to Google, HTTPS only acts as a “tiebreaker”.

Google Speed-Irony Strikes Again

We admit we love the irony of testing TTFB on Google’s homepage with online testing tool:

Please note: ByteCheck is an HTTP site – not an HTTPS site. They know the price. Shown above 407-millisecond delay on a Google page. Yes. Even Google’s homepage for search has this delay. Incredible! Recently their homepage SSL delay is down to about 200 milliseconds. But really? That still isn’t goodness.

Google’s TTFB for its HTTPS-information page is 407 milliseconds. Oops! It could have been less than 100 milliseconds – if they left HTTPS off the site. Is there a monetary or even information transaction on this page? Nope. Sheer waste of speed. Especially for mobile users.

Let’s look at a few more examples:

This site formerly changed hosts to avoid a 1.5-millisecond TTFB. The new host had a TTFB of fewer than 100 milliseconds. Bravo! But today, after the site owner added SSL Certification, TTFB is 533 milliseconds. We ask: In this case, how much additional TTFB delay is caused by HTTPS / SSL Certification? Does he need SSL? No. He just has email signups. No monetary transactions!

459 milliseconds wasted!

That’s the same as adding a video or podcast player to every single page and post on the site.

If you botch installing HTTPS, you can end up with duplicate content issues. You’ll have both HTTP and HTTPS versions of your page getting indexed. Different versions of the same page might also show up in search engine results. This will confuse your visitors and lead to negative user experience. HTTPS has no effect on search rankings. Producing quality, relevant content is still the most important SEO tactic.

To correct HTTPS problems, you have to do 301 redirects for every page and post of your site. Bummer! It takes time for Google to re-index your website and a certain drop in rankings will most likely happen.

“Don’t make the switch to HTTPS solely for SEO purposes. It’s a resource-intensive process and there isn’t a strong correlation between the two.” – Neil Patel

There is no point in serving a blog over HTTPS when you have no sensitive data exchanged. Why on earth would Google force you to do it? Why would you favor a secure blog over a non-secure blog, if you don’t exchange any sensitive data anyway?

“My recent profile of my homepage, HTTP vs HTTPS, the average load times were 1.5s and 4.5s, respectively. When looking at the connection details, the big slow down factor was the extra round trips due to the SSL handshake. Mobile browsers over 3G were even worse. The numbers were 5s and 9s, respectively.” – Clint Pachl

Do site owners realize the contradictory nature of Google edicts about speed?

Google’s claim: To help you stay safe on the web, Chrome requires websites to use certificates from trusted organizations. –

The argument is that the website owner is assured they’re going to the right website owned by the right party. In a perfect world, this would be correct. In the world we live in though, it’s incorrect. Not because the certificate doesn’t verify the owner – it does. If a website housing a phishing page has verified HTTPS, it will show the user the lovely padlock or “secure”. Deception!

HTTPS isn’t going to stop the spying of anything. The average user doesn’t care. HTTPS isn’t stopping websites from getting hacked. Nor the distribution of malware or keeping website owners safe.

Let’s be honest – No one looks at site seals. As we progress forward the Green padlock does not mean you can Trust a website or its Databases, Frontend, UI, or its back-end. HTTPS is not a SOLUTION to “hey my website is safe and secure now.” – Source


You can get an SSL certificate for free. Blog posts debate the value of a free SSL Certificate. But, the costs can shoot up to $1,499 per year if you opt for an SSL certificate from a provider like Symantec. You don’t have to provide corporate documentation to get SSL Certification. The authorization may be a simple email. Confirm the email inquiry, and you’re accepted as the authorized domain holder. Can free TLS certificates provided by Let’s Encrypt still be hacked? Absolutely. Anyone can get an SSL certificate – including hackers. They can set up a site to harvest information.

SSL Certificates aren’t justifiable for small business owners with limited budgets. Are you a blog owner that only asks for email info from your visitors? You’re better off spending your limited budget somewhere else.

But what if you’re using secure PayPal as a payment gateway? Why do you have to wear the derogatory “Scarlet Letter” on your site’s address bar? Why does a site that’s collecting zero information from anyone need an SSL certificate? It makes no sense at all. If your website doesn’t have financial transactions, why do you need an SSL certificate?

PayPal requires SSL Certification for transactions.

If you have small, lightweight, 1M page weights or less, stick with HTTP. It’s all you need.

It’s often implied (pure lies?) HTTPS secures your website. It won’t. SSL Certification doesn’t make a website impervious to hackers. Labeling a site as secure because it has SSL is wrong. In error, users think they’re using a secure site when in reality it’s not better than before.

Let’s Encrypt has reportedly issued over 14,000 certificates to domains that impersonate PayPal. – source

What HTTPS will do is deliver the intended good or bad information securely. We repeat “good or bad” information. HTTPS is indifferent to what’s transmitted. Infected websites distribute malware. HTTPS doesn’t do anything to ensure thee displayed information’s integrity. HTTPS will also deliver manipulated information to unsuspecting website visitors. Installing a Secure Socket Layer certificate prevents man-in-the-middle attacks. That’s it. It doesn’t warn of evil.

SSL certificates are there only to ensure message confidentiality, but not server identity. … You couldn’t trust SSL for owner identity before Let’s Encrypt either, nothing has changed. – source

An encrypted HTTPS connection doesn’t stop attackers from hacking a website or server. It won’t stop an attacker from exploiting software vulnerabilities. They can still do brute force access. Or cause Distributed Denial of Services (DDOS) attacks.

The problem with making something freely available to anyone that wants to use it, something like free certificates, is that in short order you can be sure that there will be some unsavory characters wanting to use it. As you’d expect this was exactly the case and the bad guys very quickly started encrypting their websites too. This is a testament to just how easy and painless Let’s Encrypt have made the process of obtaining certificates. – source

Encrypting information over HTTPS can be a good thing for some users – but not all users.

If you need speed – and don’t have critical confidential information – forget HTTPS and SSL Certification. Stick with the cheaper and faster HTTP.

PagePipe’s blog TTFB is 208 to 441 milliseconds on cheap shared GoDaddy hosting. No $79 HTTP / SSL Certificate delays added to global load times. Our bookstore sales are handled using secure PayPal transactions on a Rochen server (675-millisecond TTFB with free SSL activated).


Google still says TTFB – time to first byte – should be 200 milliseconds or less. But even Google’s homepage can’t follow that “specification” anymore. Speed tests give a red flag with slower TTFB. Google’s homepage slowed down. Google flunks its own test.

SSL compliance is only to the advantage of hosting providers. They charge for SSL services or faster TTFB. No one else benefits. We don’t care what they say about improved data security. SSL is false security. You can study that for yourself. Those with technical savvy know HTTPS is as vulnerable to tricksters and hackers. Perhaps more so.

Who wants improved data security? Google? Not improved site security – improved DATA security. Why? Because they’re in the “data collection and analysis” business. They need clean data. Not fake data. Fake data would destroy Google’s pristine credibility – and a source of profits.

QWith the improvements in browser throughput etc that comes with http/2 vs http/1.1, aren’t visitors likely to see significantly faster load times for https sites that include many small file downloads etc?

A: Is your host an HTTP/2 provider? How much does it cost? If so, then don’t worry about it. It’s encrypted already. But most of the world can’t afford the extra cost of HTTP/2. And it’s not available everywhere – yet. Note: Most HTTP sites have no need for encryption of any sort.

QAren’t there security benefits for encrypting traffic between the visitor and the server?

A: This is a vaporous web myth. Perpetuating it makes hosts millions of dollars selling little padlock “secure” badges. How does Google benefit – since they are the ones cramming this down our throats by blackmail? The idea of SSL making the web safer is ridiculous. There’s no reward.

QThe Chrome browser updates show all non-https sites as “insecure.” Doesn’t this have an impact on user perception even when there is no sensitive data exchanged?

A: Without question. Google Chrome shames site owners into compliance. This is absolute blackmail by Google to change the Internet for their gain. How deep is our disdain? Defeating. We can’t believe the world is caving into this.

We care so much about the mobile speed penalty, we’re distraught. “Why try? It’s futile.” We’re David. They’re Goliath.

“Undoubtedly, Google loves its users and therefore, is coming up with every possible way to make us feel secure here on the Internet.” – Source

Baloney! Propaganda! Note all the SSL buttons on this source above are “go” links – in other words, affiliate links. The author gets a kickback selling SSL certificates! How credible are these sources?

Is the Internet going crazy? Completely!

Google doesn’t do things without getting something back. So what is it? What gives with the Google hypocrisy? It’s not madness. It’s logic.

Google keeps data collected from free Google Font users, free Google Maps users, free Google Analytics, etc, etc. Google’s secret motivation for SSL is about “clean and pure data” – not your safety. It’s always collected free data to make money. Google contradicts its own speed policies to make SSL compliance happen. Don’t be fooled. It’s not altruism. Eavesdropping conspiracy? Nah! Google wouldn’t do that. Would they? That would be like Russian’s trying to fiddle with American elections. Too Big Brother. Orwellian snooping?

But if site data is encrypted, Google can’t be accused by anyone of illegal spying. Convenient. It’s then legal instead.

Google isn’t spying on users. It’s monitoring user activities with their consent. Whenever you use Google products, you’re presented with the terms and conditions. Users accept this before proceeding to use Google products. Users are accepting paying with their data instead of paying with money. Google keeps track of all possible data. Except for sensitive details like credit card and banking details – and now with SSL, they can prove it. Right?

Legal spying is called data collection, not spying.

‘Secure’ in Chrome Browser Does Not Mean ‘Safe’

Other than verifying the domain owner actually owns the website, the certificate authority is not required to do anything else. SECURE does not mean that the domain is “Trusted”, “Safe”, “Not malicious” or anything else. Many Phishing sites have a valid certificate issued by LetsEncrypt and appear as ‘Secure’ in the Chrome browser.

Cybercriminals slap an SSL certificate on their website and fool users into believing they’re safe. Because, let’s be honest, the average internet user has no idea what connection security is, much less what to look for. Too many people believe Secure = Safe. – Source

1.4 Million new Phishing Websites are Created Every Month

Our benevolent blog host, GoDaddy, emailed and then called by phone saying Google made the *big* Chrome change. We needed to switch to SSL right away. Emergency! And that had a price tag. We refused to pay the $69.00 dollars minimum per domain per year. Few of our domains “need” SSL.

GoDaddy has 17 million customers. Do the math.

GoDaddy loves customers drinking the Google Kool-aid.

More about the misinformation.

We have 17 separate experimental domains on GoDaddy. That SSL price tag (tax) is a potential $1,173 per year. Most site owners are ignorant about what’s needed and trust GoDaddy to make recommendations and decisions. In our phone call, GoDaddy said, “As you know, Google now requires SSL.” As if to say, “It’s not our fault we have to ding you, it’s Google.” Credit card, please?

We’re digging in our heels. We loathe the pure absurdity of Herd Mentality.

A few extra thoughts

When someone tells us the sky is falling (you must have SSL), we always go, “Huh? We guess we missed that emergency.” Most of these events seem concocted and man-made. Exaggerated to cause a sense of panic. When we research the root cause, there exists a knee-jerk backlash overreaction to some anxiety-producing change. That “scare” grew disproportionately into a “web myth” – and then dogma.

This goes especially for promises of SSL security, SEO ranking, and performance speed. People are ripped off buying “promises of instant success and wealth.”

These panics – and ignorance – sell fear for profit, not actual results of helpful productivity. Scams prevail. In the case of SSL, we’re talking billions of dollars to fight a boogie man.

Panic gets people to act. So we approach these web mandates (propaganda?) with skepticism. We also don’t like bullies telling us there’s only one way to do things. Their way! Philosophical absolutism is rarely the real truth.

Why is Google so rabid about SSL shaming? They could just be flexing muscles to test their influence. They claim to favor web security. But they know SSL is full of holes and provides an opportunity for false user trust. Google says they also value and promote page speed. But SSL drags all sites. Even Google knows that’s horrible.

What’s PagePipe’s thoughts on SSL being pushed by Google + Chrome to become a “standard” for all sites – even without eCommerce on pages? Do you think certification might bring any disadvantage in trust and user behavior?

Surprise! We propose Google is self-serving. Forcing SSL certification is not altruistic or charitable. They have clandestine purposes to protect themselves from lawsuits. Everything Google recommends slows down the web including:

  • Google AMP
  • Google noCaptcha
  • Google Analytics
  • Google fonts
  • Google Maps
  • and, of course, Google Ads!

We haven’t seen any SEO advantages or disadvantages on our blog. PagePipe’s store must have SSL so PayPal will play nice with Easy Digital Downloads plugin. That’s the only reason – technical and artificial.

As far as trust goes, no first-time visitor trusts a website. They’re anxious and suspicious. They assume any site is a potential deception, ripoff, or scam. Things producing credibility are:

  • trustworthiness
  • expertise
  • enthusiasm

Credibility affects SEO more than speed or SSL.

Good content brings people interested in your site. You don’t want traffic that isn’t qualified. It’s a waste of server resources and speed. Low bounce rate and long dwell time metrics show visitor motivation and intent.

Trust isn’t about a little padlock in the corner of your screen. Its absence looks scary to site owners – not visitors. It takes more than Google endorsement to gain visitor trust. Any scammer can get a “Let’s Encrypt” Certificate for free. Do you trust Google? They don’t trust you.

Unless you are transferring sensitive information, blogs do NOT need to support SSL for any technical reason. Blogs, like this one, primarily transfer plain-text data in the form of words and paragraphs. Encryption provides almost no security benefit for most blogs. – source


If you have a blog with no products, no memberships, no nothing except blog posts, and maybe a contact form, SSL would be a waste of time, effort, and money. Any possible benefit from Google would be too minuscule to count. – source


… if you get a phone call from GoDaddy claiming that Google [will] punish your website unless you purchase SSL certificates from them, this is GoDaddy’s way of instilling fear in webmasters in order to sell their own products. – source


Ignore Google’s whimsical 200 SEO signals – including speed!

You’ll weep when you read Google’s 200 Ranking Factors: The Complete List (2018). Because it’s so sad? No. Because it’s so overwhelming. It an encyclopedic explanation of Search Engine Optimization (SEO). The article makes SEO sound so complex and mysterious – and confusing. It implies little nitpick details make a big difference. It’s anxiety producing.

But still, we recommend reading the whole thing anyway. Some people may then try gaming all silly 200 SEO factors. Don’t go there!

Will these “tricks” help more than writing good content?

Absolutely not.

SEO fiddling is a waste of time.

Be calm. Good page ranking is within your reach if you:

  1. Write about topics people want to read.

  2. Write content in an interesting way that keeps visitors reading more.

  3. You make text readable. What’s readable? Readability is the appearance or perception text may be easy to consume. That mean placing subhead and captions for skim readers. Use short words, short sentences, and short paragraphs. Then they will spend more time after skimming content cues and clues.

The article doesn’t reveal the hierarchy of ranking factors. What matters most is the summary list at the very end. Many will never make it there. It requires a lot of boring scrolling to arrive at the real pithy basics.

The author presents a shortlist at the end. These are the real fundamentals of what counts. They’re the most important Google ranking factors (or signals) according to the SEO article. But they aren’t explained in plain English. So we’ll attempt translating some more.

Here’s his list with our commentary:

  • Referring domains
    This is other websites linking to yours. It’s them choosing to advertise your site’s valuable content for free. Again, relevant content is good writing about interesting things. So get rid of your dud articles and uninteresting posts. Don’t make site-noise diluting “user attention.” That’s simple positioning strategy 101. Referring domains is the biggest influence on SEO. If you game inbound links with a link farm or purchased backlinks – there’s bad news. When Google gets wise to your ploy, they’ll punish you. Even blacklist your site. That sharp retaliation indicates the significance of this “ranking factor.” No mercy.

  • Organic click-through-rate
    Organic means Google non-paid listing. CTR is the percentage of *impressions* resulting in a “listing click” for a website. What’s an impression? That’s the number of times your listing (page title) gets viewed on the search engine page. You can view a page of 10 listings. If your your page title is chosen – bingo – that’s a “click.” If you own most of the 10 first-page listings, that’s called page dominance. When a searching reader suspects finding relevant content on your site, that’s information scent. What affects visitor suspicion or cues most? 1) The page title. 2) The “snippet” constructed by Google RankBrain, and 3) your publication date (freshness) if indicated. Publication dates are changed in WordPress for freshening up evergreen content. The snippet refers to a description extracted from page content.

  • Domain authority
    The only thing controllable here is the longevity of your domain name. That’s right – the date when you registered your name. You can buy an old domain name that’s in use and re-purpose it. Gaming the system. But then it’s back to writing good relevant content as the main influence of authority. Serve up user-valued information.

  • Mobile usability
    Mobile-first ranking is only two things: responsive screens and fast speed. And avoiding certain stupid web practices anyway. Like interstitial ads. Google AMP and Mobile Applications aren’t mentioned as good tricks. Praise the Lord!

  • Dwell time
    This is also called engagement. It’s time spent reading or consuming your wonderful page content. What helps with engagement? Good writing and interesting images. And suggesting relevant articles to keep people on your site reading more once there.

  • Total number of backlinks
    You can’t game or cheat backlinks without penalty. See the first item “Domain authority.”

  • Content quality
    Isn’t this about writing quality? Learned skills. Writing stuff people want to read.

  • On-page SEO
    A page title is a solid suggestion. This is an interesting and attention-getting headline. But it also needs to contain your keywords (positioning statement). Example: Yoast SEO plugin affects mobile WordPress speed. Then change it into a question: How does Yoast SEO affect mobile WordPress speed? or 10 ways Yoast SEO ruins mobile WordPress speed. Use good headline writing styles developed during the direct-mail years of graphic design.


  1. Outbound links are a relevancy signal.
    PagePipe uses outbound links (resources) for credibility enhancement. Readers appreciate offsite links. How do we know? Feedback! They tell us in emails. And they see it as courageous. Because we might be sending them away from our site for good. Risk taking or confidence our content is good enough. But most often, they return to our tab.
  2. Internal links are good (of course you reference your other written material – duh. Common sense).
  3. Speed affects repeat visits – is that a surprise?
  4. Use synonyms for keywords – another “shocking” suggestion.
  5. Use ALT and title tags with keywords on image file names.
  6. Longer content ranks higher. Increase average dwell time by writing long, engaging content that keeps people reading. If you love your site topic or focus this shouldn’t be a burden. If you don’t have a fascination about your chosen field, you’d better quit now.

Isn’t “on-page SEO” obvious best practices and common sense for writing?

Here’s the bottom line:


That includes readability – not mentioned anywhere in the article or list. Make words look fun, easy, or interesting to read is a goal affecting SEO. Or at least, get out of the way of reading the words like fast speed or responsive sites remove barriers.

On websites, transparent features mean being invisible or undetectable. Speed is transparent when it’s fast. No one notices a fast page. But everyone hates a slow one. The best speed is instant page changes when clicked. Good speed is a transparent feature differentiating a site from competitors.

It’s our opinion, social sharing doesn’t affect page rank directly. But in general, it takes traffic away from your site – and when there the seduced visitor never returns. Social rarely brings quality visitors. Social 1) slows down your pages, 2) causes link clutter, 3) and takes people away. Is that helpful?

We ask clients if they quantify how much profit is because of social media. They can never answer that question. Why? Because it’s immeasurable. They’re following the web herd. All paid themes come with social links built-in. So that feature must be good. Right? Themes sometimes have heavy sliders, too. Uh.  Not good. Theme authors include every feature trying to please everyone.

In another article, the author recommends using “2018” “best” “guide” and “review” in titles. Make the title an “H1” tag. WordPress already does this.

Your SEO mission: learn writing skills.

Content IS the user experience.

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 your optimal ferritin levels if you have 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:


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.

We Analyzed 912 Million Blog Posts. Here’s What We Learned About Content Marketing

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.

WordPress speed sins: Betrayal, Deception, Hypocrisy


We’re talking violation of trust or confidence – low ethical business and technological shoddiness. Even two-faced, double-standards.

What do we mean? An example is WordPress – or any other WordPress-support vendor – professing standards such as backward compatibility of themes and plugins. For plugins, betrayal may mean abandonment or built-in security vulnerabilities. But for speed optimization, the betrayal is unpublished specifications of negative global plugin loading. We call this liability: site drag. Authors don’t talk about it. Taboo. Most plugins add page weight to all your pages and posts. But good, fast plugins don’t

The most classic example of site drag is a popular plugin called Contact Form 7. But it’s only one of many popular plugins causing global site drag. Contact Form 7 is installed on more than 5 million websites. Contact Form 7 adds 40 milliseconds of load time to every page of your website – even if the plugin shortcode is not installed anywhere.

Is 40 milliseconds really that bad? Well, good plugins load in less than 1 millisecond. To neglect mentioning this 40X speed abomination is atrocious. You could load 40 single-function plugins instead. Many site owners think the weight is limited to their contact page where the form appears. Sorry. It’s on every page and post. Does this speed abuse appear in any plugin documentation such as the plugin file? Nope. Hidden liability. Speed sin of omission.

The 15-year standard of WordPress backwards compatibility is discarded with Core version 5.0 – when Gutenberg editor was introduced. This is a form of betrayal. WordPress claims v5.0 causes dysfunction or obsolesce for 15 percent of existing 55,000+ plugins. A complete reversal of past policy protecting plugin authors and site owners from disaster.

Breaking millions of existing websites seems collateral damage to Matt Mullenweg, founder of WordPress. Why would he do this lunacy? Greed and power? Why does he want to crush WIX, Weebly, and SquareSpace, their purported competitors, with such ferocity? Are they losing market share to these puny companies? No. It’s extremist fanaticism fueled by an obsession for future world dominion. It’s motivated by secret fear of loss of market position.

It’s wasteful effort.

WordPress often risks offending and alienating millions of loyal users. Will this cause market blowback? Will there be unintended adverse results of a deaf-eared dictatorial decision? Probably.

A similar occurrence happened when the creators of Linux Ubuntu thought they’d bully unwanted user interface changes onto their open-source product. What happened?

Ubuntu forked into Linux Mint. Mint listened and kept the old Graphic User Interface. Mint-feature decisions are based on user requests or needs. Ubuntu tried forcing the new GUI down the throats of users. There was a revolt.

It took almost a decade before Ubuntu admitted they were wrong and returned to the old GUI. Will they ever mend the divided market? Doubtful. WordPress’ Gutenberg change is equally negative, even hostile, and the “New Coke” (version 5+ with Gutenberg editor) will be rejected by many.

A fork splits the community, or users abandon WordPress for competitor CMS (like WIX, Weebly, and SquareSpace). WordPress may inadvertently make the situation worse for themselves.

Isn’t “other CMS” where WordPress doesn’t want people to go? The irony.


This is convenient exclusion or avoidance of unvarnished truth about WordPress core, themes, and plugin. It includes fake speed criteria from unrealistic online tests. Scores DO NOT impact performance. They waste site owner time and resources.

Since there’s no walled-garden regulation of open-source WordPress-related product, offerings are Pollyanna, unrealistic, Utopian, or sugar-coated Disneyland fantasy. This WordPress world is run by idealistic cowboys.

The unspoken objective is motivating WordPress site owners to use or buy a product or service – whether it’s needed or not. Selectively omitting negative specifications – or insinuating false benefits – runs rampant.  Often the disguised propaganda is showy, flamboyant, or dramatic sales hype. Including laughable claims of SEO benefits like Google first-page #1 ranking.

Exaggerating benefits – or extravagant promotion is hype. Over-enthusiastic, rampaging followers or intense rabid fans present hype as truth. This reinforces the disillusion they’re real authorities or *thought leaders.* They forcefully perpetuate web myths using social platforms such as Facebook Groups, blogs and forums.

False advertising is a crime. It’s the publishing, broadcasting, or publicly distributing of advertisement containing untrue, misleading, or deceptive representations. These statements are made knowingly or with recklessly intention to promote the sale of products or services.

For example, many *performance* themes and plugins are represented to improve speed. A beautiful demo is shown. But with testing, you’ll discover it’s a trick. The product demo has unreported behind-the-scenes extra services and speed additives sprinkled on it. The result is buyer remorse – and usually no refund – perhaps a store credit, if you’re lucky.


The Ivory Tower is separation from real-world facts and practicalities. It reeks of privilege. We challenge the credentials of cynical academia, secret affiliates, herd popularity, or scheming speedcraft.

These are men and women preaching and setting themselves up as evangelists or experts to get gain and praise. They don’t seek the welfare of others.

They teach but they can’t “do.”

Eliminate SEO plugin waste.

There’s no WordPress dipstick to check SEO levels.

If you’ve seen a reduction in page rank, the estimated time for Google purge is 6 months after correction. Yoast SEO has a plugin-addition fix (extra plugin) to accelerate correction with Google. We doubt anyone needs it. But who know what the truth is since there is no “future history” to analyze?

Can you switch to another plugin without disrupting SEO? No one can promise SEO performance. And if they do, they’re selling a wish. But switching SEO plugins is apparently less of a risk than past Yoast weirdness. So migration is possible to another SEO plugin.

Some ideas from those affected by the Yoast 2018 bug is Yoast enhanced page-rank was artificial fragility at best. It set users up for disappointment. Removing the Yoast “benefits” reduced the site ranking to it’s real position. There is no proof. But it’s like saying, “You can cheat but eventually all tricks will be ineffective or eliminated.” There is a plugin to help migrate the Yoast SEO database when changing to select alternative SEO plugins. The next most popular plugin after Yoast is All in One SEO Pack.


We’ve documenting why not to use Yoast SEO plugin. No SEO plugin provides provable benefit. Have you ever seen benchmarks ranking improvement? We haven’t. How do you measure SEO reduction caused by competition or change in market needs? Impossible. It’s about consumer behavior.

Ensure your content is based on intent and what users want to find when they search. That’s the bottom line.

SEO is now controlled by a machine learning algorithm called RankBrain. RankBrain is smarter at identifying patterns and penalizes unscrupulous actors attempting to game Google.

RankBrain is an algorithm learning artificial intelligence system (AI), used by Google since October 2015. It helps Google process search results and provide more relevant search results for users. RankBrain is the third most important factor in the ranking algorithm after links and content. RankBrain interprets the relationships between words. I suspect it has more importance to Google than we know.

RankBrain allowed Google to speed up the algorithmic testing for keyword categories. They now choose the best content for any particular keyword search. This means old methods of gaming rankings with false signals are less and less effective. The highest quality content from a human perspective is being ranked higher by Google.

Content frequency, recency and relevance were previously rewarded with good ranking. This isn’t the case anymore. Search engine users and search engines are now trying to find amazing content with great value.

Gaming with plugins has negative, detrimental value for future SEO.

Why WPmudev WP-Checkup is worthless drivel for speed.

Incsub, LLC (aka WPMU DEV) have the art of producing customer fear down to a science. For example, you can take their WP-Checkup for free, once in a 24-hour period. Their speed-test is scary but nonetheless wimpy at best. We’ve written about other SEO and Security portions of that test. Read about it.

But in this article, we focus only on speed. Our performance score was a 96/100. But these scores are meaningless. There are 10 speed parameters. Here they are:

1Remove render blocking. 24/100
The test identified one offending file on PagePipe. It’s a CSS file loaded by a plugin called Add Search to Menu. We used to like this plugin. The test told us none of the above-the-fold content could be render until this CSS file got out of the way. Now from experience, we know above-the-fold rendering blocks are a deceptive waste of time. It’s pure crock. They gave us a red-alert alarm on this little thing. Why? Instilling fear.

Where is the fold on a mobile device anyway?

WordPress almost always fails render-blocking tests. Does Google punish your SEO for your failure? No. They don’t use any concocted speed parameters from PageSpeed Insights for their secret algorithm. They only use Time to First Byte (TTFB). That’s a function of your server responsivity. It has nothing to do with website design – or site performance optimization. Fast TTFB is something you buy from a hosting provider.

People ask us, “Should I rewrite my code or use plugins to remedy render blocking?” The answer is: no. It doesn’t make any difference in speed or SEO. So forget it. More than likely you’ll end up breaking your site over nothing. You’ll see a white screen of death – or a page of unstylized CSS. Not worth the grief.

Remember: This wasteful test doesn’t tell you how fast your site loads in milliseconds. That’s what counts. Not some silly score. Go test on Pingdom. Milliseconds count, not that 99 “A” score.

No signs of slowing down on PagePipe from the nasty render-blocking warning. False alarm.

2Minify CSS. 85/100
The test said we should minify a theme file: twentyseventeen/style.css to save 3.9k in page weight. Almost 4k. So much! We know how to minify with online minification tools using copy and paste. We could do that hassle – and maybe we will. But really. Is this significant? They gave us a yellow alarm on this one. Grrr!

3Minify JavaScript: 91/100
Minifying JavaScript will frequently break your site. It’s not the minification – but concatenation that’s the problem. Read more about it here. The gain from minification is rarely significant. We always try it. But if it breaks anything, we discard attempts right away. Why? Because the gain in milliseconds is so small. In fact, there’s usually no change in speed on an optimized site.

Anyway, this test said we could reduce two theme-related files by 1.9k. Almost 2k. Wow! We’d risk breaking our site for that? I don’t think so. And we’ve tried minification. It breaks our ecommerce plugin for selling books. No thank you.

Enable compression: 100/100
This refers to Gzip compression. It’s probably already activated on your server by default. If not, a simple, free plugin can switch it on. Learn more about Gzip compression here.

Prioritize visible content: 100/100
Boy-oh-boy! What a relief since we didn’t even try. This is another bogus and silly parameter. Makes no difference whatsoever.

Optimize images: 100/100
Read more about image optimization with plugins here. And for goodness sakes, don’t use the WP Smush free plugin. It doesn’t do any significant good.

Minify HTML: 100/100
Interesting result. We’re not minifying HTML with a plugin. Again minification is not a big deal. Small gains – if any.

8Improve server response time: 100/100
This is Time to First Byte (TTFB). The only way you can improve it is switching to a different hosting provider. Our TTFB is 176 milliseconds on magnetic, shared, cheap GoDaddy hosting. That’s fast because we don’t use HTTPS/SSL certification on the blog which slows down TTFB by up to an additional 500 milliseconds. We don’t need it. All our transactions are via PayPal on And we don’t use signup forms for anything but email addresses. Read more about how HTTPS/SSL slows down your site.

9Avoid landing page redirects: 100/100
We’ve heard some people have problems with redirects. We don’t. It’s a simple matter of using the right settings in WordPress. And the Redirection plugin for changes. This is a silly thing to check in a speed test.

Leverage browser caching: 100/100
We use two caching plugins:  Cache Enabler. Only repeat visitors benefit from browser caching. First time visitors are the bulk of your traffic – usually new visitors are around 60 to 80 percent. So caching doesn’t help everyone. Sometimes there’s no speed benefit at all. You have to test using millisecond comparisons.

Conclusion: Avoid this lame test at WPmudev.

Cloudflare hype for DNS speed is pure B.S.

“CloudFlare has released a new privacy-focused DNS service that runs on IP They supposedly rotate logs every 24 hours and don’t store anything long-term. Seems cool, but I wish it did security filtering as well.” Link

This Link told us who the real benefactors are: is a partnership between Cloudflare and APNIC. The speed project is at a research phase. Just like Google AMP has been for years. Both are ideas or concepts under test. DNS services launched April 1, 2018.

APNIC is the Regional Internet Registry administering IP addresses for the Asia Pacific.

Many think PagePipe is technocratic. That’s anyone who thinks technology will save the future world. That’s a bad assumption. Ironically, we’re safety-seeking, risk-adverse late adopters. Or even laggards – when it comes to technology changes. That’s because “new” often means “buggy” – or worse a ticking time bomb. But our attention is now on this method.

What’s the downside of Cloudflare’s claims of reducing site speed by 54 milliseconds? No one knows yet. We’re optimistic skeptics. But we usually wait and see how things work for Guinea-pig innovators. We find it odd that Cloudflare brags about saving 54 milliseconds while at the same time boasting about how they converted the biggest chunk of early adopters to SSL certification. Using SSL/HTTPS slows down every site by 400 to 500 milliseconds. Speed hypocrisy!

Some international service providers are blocking Why? That’s yet to be revealed. doesn’t work in many countries because it’s blocked. What? Why would it be deliberately blocked? And in some cases, it’s not blocked but slowed down. Again, why? Odd mysteries to solve. is plainly not a panacea … yet. Or maybe ever.

Cloudflare CDN publishes deceptive time-to-first-byte (TTFB) speed specifications. Because Cloudflare uses marketing weasel words, our level of trust is low.

Cloudflare is getting free PR and press. Proof of concept really lies in user testing. That’s where they’re at today. Testing on users. We wouldn’t adopt this technology. Our intuition says there will be revealed a hidden downside – or that this service makes little to no difference.

Cloudflare has low source credibility. They  promote something for nothing often with a speed-gotcha embedded. From our experience and our clients, using Cloudlflare services increases site fragility.

Other elements have greater impact than Cloudflare speed claims – like TTFB, SSL, heavy plugins, page builders, webfonts, email APIs, video, etc.

The gain is the equivalent of disabling a related-posts widget plugin. Maybe.

So we’re watching and waiting. Benchmarking Cloudflare services against Google’s – and others like Quad9 and OpenDNS is the norm. Who is using those services? Geeks? Multi-billion dollar corporations? Certainly not non-programmers using shared hosting. None that we’ve ever seen anyway. We’re talking a difference of a millisecond per parallel-loaded request. Is this significant? Probably not. is a distraction from speed fundamentals making a real performance difference.

If makes a difference, it indicates the web page under test had too many calls (requests) in the first place. A bloated page always benefits most when optimized. How fast would the page be if built properly? Where do these DNS calls show up in speed testing? They don’t. They are smothered in the TTFB.

They aren’t giving us real benefits yet in language understandable to normal website owners. They’re using GeekSpeak.

For example, if a site has 24 calls. How much difference does using a special DNS make in real-world speed results? 24 milliseconds? We doubt it.

Why not eliminate 200 milliseconds by getting rid of a plugin like Social Warfare and stop linking to Facebook?

This DNS trick is misguiding site owners from true solutions: discipline, Pareto-based measurement, and value analysis of website components.


Speed miracles to improve your site’s mobile health.

Our suggestions for radical site surgery:

1Use a theme that’s fast loading. And we don’t mean “mediocre” fast. We mean faster than greased lightening. Built and tested for speed. Don’t believe theme author’s speed bluster. Test it – or don’t buy it. If you must use a page builder, we recommend Elementor (with caution) – or wait (forever?) and see what Gutenberg offers.

We prefer a free theme because they’re not loaded with features. Paid themes are usually gold-plated and over-engineered with non-features. Free speed theme recommendations include: Basic theme, Tiny Hestia, Astra, GeneratePress, and Twenty-seventeen default theme. Many don’t activate code baggage like jQuery or Font Awesome. You can strip them of anything lacking substance.

WARNING: The pro (premium paid) versions of the above speed themes double theme page weight. This is not super significant. But we find it annoying. They brag about the free version’s speed then don’t publish the additional drag added by the premium version. That’s an advertising sin of omission. So if you’re really into extreme speed (1-second or less load time on a shared host), use the free theme without the premium extras. That takes creativity.

Creativity is the inverse of dollars. C=1/$

Do you think these insignificant improvements? Think again. Speed theme authors are deliberate in removing non-features for mobile speed benefits. It’s unconventional and bold. If pages weigh 5 megabytes to 3 megabytes – or even 2 megabytes, they’re doomed to fail for mobile user experience. The goal is superb quality pages weighing 100k to 500k.

Add features using discrete plugins.
Not multipurpose plugins like Jetpack or Yoast SEO. This means also living within the theme limitations. Keep It Simple, Stupid. The KISS principle.

3Install proven fast-loading plugins. Avoid popular plugins like Yoast SEO and Contact Form 7 and many others. This includes WP Rocket, which functions great, but adds drag. Yep. 32-milliseconds of site drag to every page. Yes – believe it – a caching plugin slowing things down while speeding things up – oddity. We build WP Rocket’s features with free discrete plugins. It takes at least 4 plugin – but adds only 4 milliseconds to load time instead.

Discrete plugins allow activating features where most needed – instead of globally.

The Facebook *like box* is another common slow down as it has been known to easily add 40+ HTTP requests (as seen below). On a clients site we saw that it added 700 KB to the overall page weight, which is not good! – Source

Find ways to either not use Facebook or using it in a limited way. Reduce the load as much as possible. Is Facebook making you money? Be honest. Or do you dream it might?

5Abandon the grandeur of Google fonts. If they’re in the theme you choose, disable them with a plugin. Even though they only add 100 to 300 milliseconds. On a fast mobile site that’s a 30-percent loss. Google Fonts are stinky bad for mobile.

6Don’t use HTTPS/SSL certification. Don’t give into Google’s social pressure. SSL adds 400 to 500 milliseconds to your TTFB (time-to-first-byte) server overhead. Wasteful. Don’t be weak. Go ahead test Google’s home page speed. It used to be under 100 milliseconds. With self-imposed SSL edicts, Google speed sucks now. They can’t even match their own PageSpeed Insights recommendation of a TTFB below 200 milliseconds. Ouch. Embarrassing.

There are more non-surgical extras for speed we place into the fine-tuning, tweaking basket.

Do you suppose examining your site that images are the biggest problem? They’re not. It’s rarely the case any more. The two biggest factors are usually theme-related and Facebook. Even worse than much-hated, third-party ads – but barely. PS- We optimize your image library for speed.

We don’t hate Facebook because we’re demure introverts and antisocial. We despise Facebook for what they did to speed innocents. Dirtbag destroyers of velocity. Apathetic.

Thanks for trusting us to help improve your site’s mobile health.

Let’s go – faster.

Is choosing the right theme for Elementor important?

There are several themes proven to work great with Elementor. But it’s not the theme’s fault if your site is slow. Is there a best theme?

The three best themes for Elementor users.


Most of the people we know use GeneratePress with Elementor because it’s built for speed. Here are some key speed features:


No WordPress theme has gotten more Elementor-related hype than Astra. Judging by the comments on Elementor groups, you’d think  Astra is the leading theme. But when we’ve seen surveys counting actual users, Astra comes in below GeneratePress. Astra contains speed potential. But a novice overloads this theme like any other. It’s lightweight (less than 50K on the frontend). We tested that spec and it’s true. Astra has the potential for *unparalleled* speed as the authors claim.


Regardless of the theme, every website needs help to reach the greatest speed. Find out the basics of what you need to know: Start here.


The Hello theme is from the same team that created Elementor. You might think that means it would be best for working with Elementor, but you would be wrong. The Hello theme has been around for years. It didn’t get much traction until recently when they released the theme to the free WordPress repository. Lots of people jumped on it right away. But many of these people realized that Hello was not the answer for them. Why? Hello is so barren of features that it’s unusable for anyone who isn’t proficient in CSS. Another sticking point is the fact that Hello requires Elementor Pro ($49 annual rent). It won’t work with just the free version of Elementor.

Regardless of the theme, every website needs help to reach the most speed potential. Find out the basics of what you need to know: Start here.

Which is best?

Unless you’re good with CSS, Hello is a non-starter. Hello fails to take part in the race. The others are both great themes, are fast, and have good support from their developers. And they work great with the free and the Pro version of Elementor. They also have premium features available at reasonable prices.

But premium will double the theme page weight – and slow down your site. They forget to tell you that.

For example, Elementor boasts they replace 17 plugins with Elementor widgets. They claim this saves you money and improves speed. But the 17 plugins they claim to replace, we would never add these features to any website. They cause slowdowns or poor UX:

  • Maintenance Mode/Coming Soon
  • Popup Builders
  • Motion Effects
  • Forms
  • Media Carousel
  • Countdowns
  • Email Marketing Services
  • Image Gallery
  • Pricing Tables
  • Testimonial Carousels
  • Google Maps
  • Social Icons
  • Header & Footer
  • Facebook Embed
  • Tabs
  • Accordion
  • Slides

As a  final insult, Elementor says 20 plugins is the largest number of plugins you should have on any website. That is hokum. We often have 50 to 70 plugins and our pages load in under 1 second on cheap hosting. The average number of plugins on WordPress sites is 25.

What about speed?

What will ruin the speed for your site is not the theme – unless it’s a slow one like Divi. It’s all the junk you add to it. It’s designer apathy that ruins speed.

Keeping themes fast requires site owner self-discipline.

Surprise! We don’t recommend Elementor.


We’re sharing speed numbers from a recent test. We built a fast Elementor page using our origin optimization recommendations. Then we built the same page without Elementor – and threw in an extra-large featured header image.

What should you use instead? A responsive grid column plugin. But only if you need columns.

Mobile users only need one-column pages!

What theme did we use for this Elementor test?

Automattic introduced the Twenty-seventeen default free theme way back in the fall of 2016. It loads in about 25 milliseconds. But only after stripping the theme and WordPress core of unnecessary features.


That’s right. It’s not even on the popular speed theme list above. Do we use this theme? Yes. Why? Because it won’t retire. It’ll be maintained for 10 years. That’s based on the historical performance of past default WordPress themes. Longevity. It won’t disappear soon. And it’s free. No pro or premium version to pay rent every year!

What do the pages look like for comparison?

ABOVE: With Elementor. Click to enlarge.

And below without Elementor:

After without Elementor

Do we remove or recommend removing Elementor? That may sound  like a piffle. But when TTFB on a slow server (like BlueHost) is 1.7 seconds, you only have 300 milliseconds left to load everything. That’s achievable but it’s a speed miracle. Gaining extra overhead to pad your web performance budget is a relief.

So the new version 2.9.7 of Elementor is 1M lighter than the rollback version (2.8.5) when decompressed. Elementor trimmed down the newest files. This is unusual. The newer version removes 1MB of Javascript. Both versions still claim 30 widgets.

Both test pages loaded in 1 second (+/- 30 ms) using

On Pingdom:

page weight 314k, 549ms, 18 requests without Elementor

page weight 715k, 1.57s, 19 requests with Elementor

1 second load time difference with this test! The two test sources reveal different results. Which do we trust in the end? Neither. We trust our browser timer most.

Why? Voodoo.

Timer results: 1.2 seconds with Elementor pagebuilder and 930 milliseconds without Elmentor. Both pages with unprimed cache. 270 millisecond is the difference on Firefox browser desktop.

1.71 seconds  (with Elementor) vs 850 milliseconds (without Elementor) on Google Chrome browser. That’s 860 milliseconds faster. Go figure.

But no matter which speed test you use, it’s intuitive Elementor is slower. Elementor makes significantly more requests and adds more scripts and styles to pages than using a simple column grid plugin with a fast theme.

Below: 3-minute demo video.
“How to use the free Lightweight Grid Columns Plugin” developed by GeneratePress.

So does using Elementor slow down desktop pages significantly? No.

But the difference in page weight will slow down mobile. There is no noticeable difference in load time on desktop. It only matters to mobile users with limited remote bandwidth and/or metered data. How bad is that?

For some sites, that’s 70 to 80 percent of visitor traffic.

NOTE: The test pages are both optimized and enhanced for speed with the same performance plugins. Both are on the same site, host and theme.

While internet mobile speeds dropped by 7 seconds this last year. The average load time is still 15 seconds. Horrible mobile connection times.

This link below gives solid information about the state-of-the-moment for what is normal and bad mobile speed:

Don’t think for a minute Google is always right – but their sample size is reported. They recommend less than 500k pages for mobile. We agree.

Avoiding pagebuilders for mobile speed.

Cutting through Google BS.

“Statistics” and bloviations from SEO gurus say more searches are from mobile devices. Some sources say the growth in mobile search makes desktop searches irrelevant.

Our skepticism increases.

You can bring in Google Analytics data from their online store. You can add it directly to your own Google Analytics account. It’s mostly to help you learn how to use Google Analytics when a website doesn’t have much going on.

Google’s online store is interesting. In the section showing what kind of devices people use on Google’s online store:

  • 70 percent of visitors come from desktop

  • 26 percent originate from mobile phones

  • And the rest (small percentage) were from a tablet.

How can *THAT* be? Has Google – and cellphone companies – been lying to us? Do SEO gurus not know what they’re talking about? Is all the conventional wisdom wrong? Is this an expected glitch from noon traffic?

Here’s a screenshot from the Google Analytics data for Google’s online store:

The title SEO “expert” is an immediate red flag of poor source credibility.

The trust level for purchase transactions on a desktop is still higher than mobile. In Africa or The Philippines, you have no choice. Mobile is your only option since you may not afford a table to but a computer on.

Most shopping happens from a company-owned job-related computer. That’s right. Goofing off. Especially during the holiday season. It’s estimated employees goof off 30 percent of the time. You can fake you’re working while shopping and listening to Pandora. Perfect. So is it real shopping? Uh. We don’t think so. Wasting time is not shopping with a purpose. It’s window-shopping from boredom.

OFF-TOPIC: Take for example the statistic that WordPress owns 1/3 of the Internet. Is that real? Or a myth they don’t squelch because it makes them look and feel important? No clue.

We don’t know what to trust in the world of metrics anymore. Google doesn’t disclose how it gets information. It’s secret. They don’t tell us if it’s skewed by something or biased. In a sinister world, it would be completely fabricated.

If their data is so perfect, why do they fix algorithms every month?

Google does more to slow down mobile traffic and page loads than any other culprit on the web. Yet they claim they’re advocates of speed. Smokescreen.

One question is who are the people in the sample? Are they global or domestic? If this is store data, what is the buying behavior of their particular sample? How stale is the sample – real-time? Are they last year’s average? Cyber Monday?

Anyway, a few simple questions would blow some holes in this information.

Upside down Google.

This much is real – Google spins data to their advantage. Vanity metrics.

Our experience working with clients around the world is “mobile is worrisome.” But not for everybody. For example, 85 percent of our readership is on desktops or laptops

The people who ask us to “fix” their websites have high mobile rates: 70 to 80 percent of mobile traffic. Where do they get that information? Google Analytics! Is Google Analytics a trustworthy source of metrics? Not for a minute. They have improved a few things to remove artificiality. For example, until recently they counted visits from bots as real visitors. That meant an easy error of 10 to 30 percent on some sites.

Last year, they did various adjustments to thwart people generating fake content. The people the hardest hit were selling snake oil. Those were the people approaching us for fixes. All brainwashed that SEO was the most important thing to mess with. They wanted speed for better SEO. Even though we told them that was a falsehood. They still wanted speed for SEO, just in case, we were wrong. Too weird.

We don’t have to brainwash people that speed is important. Google does that for us. Free sponsorship.

So we use Google Analytics to track post popularity. The reason is that it’s faster loading than a “Popular Posts” plugin. Those plugins track metrics inside WordPress using the MySQL database. The way we do it is faster anyway. Last year our traffic was up. Google did some adjustments and the number dropped by 20 percent. We also realized we had a slow tracking beacon on our homepage. That’s our showcase page. That’s the page most skeptics test for speed to see if we walk the talk. Google Analytics slows down pages. So we removed it from the homepage.

We turned off tracking for the homepage with selective activation. The numbers dropped another 10 percent. That was fine since that was before reported as 10 percent of our visitors. But we care less about how many people come to our website front door. We’re not interested in “funnels” and “paths.” We only want to track the popularity of articles. Not our site popularity.

Now with all this jockeying around, did our bundle sales drop? Maybe. They certainly didn’t increase. But we can’t attribute it specifically to lower traffic. It will always be unknown even if we get sucked into the SEO vortex – like many other web fools.

So many unknowns based on half-truths and misdirection.

What we’ve seen as far as web designers go, they still build for desktop first. Not mobile. Why? Have you ever tried to build a website using a phone? Crazy. But people do it. A phone is how many manage online stuff. Not the way we want to do it. We hate looking at tiny screens and trying to push things around with our fingers. We test with mobile devices. We don’t build on them.

Based on our site “data,” designers prefer desktops. And according to Google, 75 percent of our traffic is international. But do we build for mobile-first? Yes. To the extreme. Why? Because that is our positioning strategy. It’s what differentiates us from the herd of wannabee speed experts. That is a fragile position. But it gets us conversations with some interesting people and problems. We then become even more expert. We figure the 25 percent who look at our site on mobile are the same people viewing on desktop. They’re checking our credibility.

Anyway, what makes a difference? We don’t know. We may not even care. It has an opportunity-cost checking metrics every day. But content that solves problems (real or imagined) seems to work for us. Do we care what device they’re looking on? No. Because we build for mobile since that is the anxiety and pain for our readers. Real or imagined pain. We may be selling placebos. If it makes users feel better, that is OK with us.

So interesting side note: We’ve had 3 or 4 international bundle sales this year when downloads failed. Why? They were downloading a 3-megabyte bundle on an iPhone! The connection timed out. We ended up supplying those 4 bundles through But that put the kibosh on our idea of self-hosting video from our media library. Can you imagine downloading on a remote phone something as big as a gigabyte? Crazy.

Google can’t measure user experience. Not really. Can they measure happy or sad or disgust? Nope. But they have a lot of people fooled into thinking they *can.* Even if they could see your face, they would still have to guess. Google can’t judge quality of content. They guess.

Google predicts 200 “precision” secondary signals. They make assumptions what those mean. This includes things like:

  • Backlinks

  • Bounce rates

  • Click through

  • Dwell time

  • Etc.


Do these signals show website goodness or quality?

Maybe they do.

There is some truth in what they’re doing, but not a lot. Even real-life people judging every website would still be inaccurate – and impossible. All the “signals” are prone to cheating and mismeasuring. It’s ridiculous.

People make a lot of assumptions about what matters and what doesn’t. For example, many think speed is critical.

Sorry. Relative content is much bigger than speed. Anything is bigger than speed. Speed is a pimple on the Google algorithm. Less than a half-percent improvement. Big wow. It’s amazing how many people believe that speed is a huge ranking factor. It’s not, as we’ve said many times.

Doesn’t Google use PageSpeed Insights scores in search ranking? No. That test’s an ivory-tower exercise to drive site creators crazy. WordPress sites can’t pass that test. Not even Google’s homepage passes that test. Try it sometime.

Is speed anxiety serious for e-commerce? Yes. Big anxiety. Why? Google whipped them up in a frothing frenzy. Speed propaganda says fiddling makes a difference. Amazing.

We often open an article in a tab and then proceed to read something in another tab. That dormant open tab counts as dwell-time in Google’s book. Google (supposedly) counts that dwell-time for up to 30 minutes. Is that indicative someone is reading the content? We may never return to read the article – and close the tab.

This fake-out creating false data bothers mighty Google. It’s the motivation for more spying via Chrome browsers to gather data on user behaviors. Every time we use a Google product, we consent to them gathering data.

Google uses artificial intelligence called RankBrain to predict user intent. This means filtered information by an “unbiased” machine before presenting search result choices. We don’t filter anymore. Google does. Interesting. How does that taint the data? Isn’t data then analyzing itself? Too weird.

What’s to prevent Google giving preferential treatment to big advertising clients? They wouldn’t do that, would they? Well, yes. An example: When it came time to roll out the mobile-first page ranking algorithm, did they test on big accounts that brought them profits? No. They quietly excluded them. Instead, they experimented on millions of little sites as no-risk collateral damage. They weren’t about to test on any big fish. Profit first.

Hmm? So Google does game their own system.

Everyone says Facebook and Twitter over-control what people see on the Internet. But they never realize Google is the one who controls most:

  1. What website pops up during a search.

  2. What Google “thinks” we’re looking for.

Don’t believe everything you read or hear about the relationship of SEO, UX, and mobile speed. Especially if Google said it.

Don’t use Cloudflare CDN: build in speed quality instead.

Some sites we evaluate for speed testing are using free Cloudflare CDN services. A CDN (content distribution network) is a way to get servers geographically closer to the user and thus reduce latency. That’s the goal anyway.

Cloudflare is a US-based website performance company founded in 2009. Cloudflare claims to improve page load times and performance.

In the recent past, we’ve used free Cloudflare CDN services and their plugin to bulletproof our WordPress websites. Testing, we found Cloudflare doesn’t guarantee consistent load speeds. We saw an unpredictable and random page load times from 10 to 25 seconds. That’s unacceptable even if the average time is one second.

Typical server error message presented by Cloudflare after connection failure. Makes it sound like the blame is your fault. Excuses. Wrong!

Cloudflare uses a modified version of NGINX – a key Russian-created technology. Nginx (engine-x) is an optimized open-source server software used in the LEMP stack (Linux, Nginx, MySQL, and PHP).

We first thought there was traffic congestion on the shared hosting server. We checked using and found only three domains resided on the shared server. One was inactive and the other two had benign, low-traffic content. The server wasn’t our offender.

After plugin testing, it was clear that Cloudflare was the culprit throwing in random delays. We canceled the account and removed the plugin. Then things stabilized. We also got better speed test results in Our cached time improved from 750 milliseconds to a 500-millisecond load. We’re giddy from this discovery.

Christian Nelson, ally and web critic, saw this weird, random, delay phenomenon years ago – but not only on Cloudflare. He’s maintained a low opinion of CDN solutions since. He’s right on the money. CDN response times are unpredictable.

We’re against any CDN paid or free services. Build with origin optimization. Then there’s no or little benefit from edge optimization. CDN is a band-aid for sloppy site owners. You can’t speed up a site that’s already fast. It’s a waste of money.

One more bad thing about Cloudflare CDN.

Cloudflare’s Nginx servers cause failure on time-to-first-byte measurements (TTFB). Usually shown as a red “F” as in failure or flunk using This negative flag generated a brouhaha, and Cloudflare responded with a special blog entry about the topic and why they think it not a real problem. We agree. TTFB isn’t a problem. Cloudflare flakiness is the problem.

Cloudflare’s claim is “Gzip compression of web pages reduces the time it takes a web page to download, but the compression itself has a cost. That cost causes TTFB to be greater even though the complete download is quicker.” But only on Nginx servers. Apache servers are just fine.

Nginx waits until compression has started before sending the HTTP headers; when compression (Gzip) is turned off it sends the headers immediately. Nowadays, all files are Gzipped for speed.

Our complaint: Who cares about TTFB when Cloudflare throws a monkey wrench into the running engine and randomly gives 10- to 20-seconds page loads? Hiccups aren’t acceptable.

Stop worrying about Time To First Byte (TTFB)
05 Jul 2012 by John Graham-Cumming of Cloudflare. (A lame rebuttal).

Our experience is Cloudflare CDN is notorious for slowing down your site with 500, 501, and 520 server errors. That’s probably where your TTFB errors are coming from. Cloudflare uses NGINX servers instead of Apache. This causes the lazy loading of all Gzip compressed assets. Unnecessary delays. TTFB is the only metric Google uses in its SEO ranking algorithms.

Using Cloudflare would explain the reason for your speed fluctuations. We do not recommend them – nor any CDN for that matter. CDNs are band-aids for poorly optimized websites. It’s better to build quality into your site. That is called origin optimization. CDNs are edge optimization strategy.

Cloudflare ran a test and concluded that time to first byte (TTFB) does not matter. Except, it absolutely does. As they say: if you’re experiment contradicts intuition, check your experiment.
Ilya Grigorik, Web Performance Engineer at Google

Another typical Cloudflare error screen.

Offsite link: Cloudflare Makes Websites Slower, Not Faster “I noticed that my Cloudflare-enabled sites became much slower and they would often time out.”

“When you put a CDN in front of your website, it will add latency to the TTFB of your dynamic content. Accessing the origin server directly is faster than routing traffic over a CDN. The CDN will improve performance for cacheable elements, but a dynamic page will have to be fetched from the origin server no matter what.” – OFFSITE RESOURCE

Why we dumped pretty Shopify – and 2-second mobile speed.

While we’re not selling jewels, the Shopify aesthetic at Awe grabbed our attention. The UX and speed leave a lot to be desired, but the feeling is good enough to make up for it.

Is it a cliché store design? Yeah. But that may be the expectation. If you get too creative (expressive noise), you won’t make sales (confusion of choices). People can’t find things when convention isn’t followed.

Four sample web pages from Awe ecommerce:

1. above ABOUT PAGE


3. above HOMEPAGE


This site is a common Shopify example. They throw millions of bucks making their services fast loading. But silly designers still slow down Shopify pages with apathy. It could load in under 1 second. Instead, instead it’s 3 seconds. Is that horrible?

It depends upon the audience. If they are a mobile audience – YES. It’s a waste of bandwidth from being careless or apathetic about speed strategy. Speed is the first hurdle to a good user experience. UX is about hospitality.

UX observations of these Shopify pages:


Color is the biggest influence of quality and habitat cuing after speed. “Does it feel good to be here?” The large images set an elegant mood with female lifestyle inference. They use white space and solid colors. Elegant themes generally have higher usage of blacks and metallic colors. We could say tan is gold with no reflections and gray is silver with no glint – and that is believable. It has a blackish footer. We’ll judge this site theme as elegant. It looks like their specialty is gold and silver – so that works.


Sliders don’t work unless they tell a story. A single non-moving image is better. Is this a picture story? We can’t tell – but we guess not. Mere glamour shots. The slider was “present” and the designers couldn’t resist not filling it. We’ve written about this:


And this caustic collection in this free PDF format:

Some core web UX philosophy: Avoid sliders unless they tell a captioned 3- or 4-panel story. The imagery better be good. No image links. No rollover pause control. This flub disables the story – a negative feature.

Almost always, we’re anti-animation. No moving parts on a web page. Why? Have you ever tried to read a page with a fly walking around on it? Distraction.

That doesn’t mean we haven’t experimented with motion. But the attention trickery is usually a UX failure.

These pages have minimal animation – but no animation is good. It’s often a content-cramming ploy.


Our reference about building big hero images that are fast loading:


There won’t be a test. So skim them.


Logos are overrated. We like the simplistic classic balance of this clever logotype. Clever is usually badness. No icon or symbol wasting space in the header. That’s good.



We’re not in love with double layer navigation bars. Bad UX. One or the other gets ignored. It’s a trend or a fad. Is it a solution? It shoves everything down the page a little further. Vertical waste is negative. We don’t like the dropdown menus that cover content. Is there no alternative?


Do we like the gimmicky photo image swaps on rollover? No. It’s hiding the content. It may be cleaner but it doesn’t promote product understanding. We’d rather have a magnifier show product detail.


Do we like the annoying signup popup offer? Nope.


They’d have better UX with static signup in the footer or embedded in the body content. And faster-loading pages, too.



The coolness feature of the day. Iron boat anchor and it’s live in a few minutes. We tested it. It says Jill will answer but Sharon did (Screener of Incoming Calls?) and she’s a real person. This costs money. She disappeared for 25 minutes when we asked her location and if she worked for Shopify. And she promised to “answer any & all questions.” Disappointment.

But usually chat is fake.

Then Real Jill came online and said she was the only one in the office on the holiday and was swamped. Now that’s the real story. We told her she deserved a raise.


Is Shopify bulletproof?

No. You can easily overbuild slow sites there, too.

Our lame store-building experience with Shopify. Fast (under 2 seconds) but not good functionality.

Q&A with Kendra Heim, PagePipe Staff

1How hard was it to set up a new account?
Super easy. Enter a valid email address, create a password, answer a couple questions about your business, and finally enter your personal information (physical address, name, phone number.)

Got any reference on how to set up an account?

3Tell us about the decisions you made when making the store. What was most difficult?
The most difficult part was figuring out how to make the home page a viable storefront, or more accurately a viable catalog page.

4What are the limitations or design constraints with free Shopify?
There are only 8 free themes to choose from. Each has its set parameters and variations. These include menu placement, logo placement, added functions etc. You need to do some looking to decide which fits your specific needs.

For our store, we chose Minimal with the vintage style. You can’t add much design to the page, only pre-designed elements, and this doesn’t work freely on every page. Some pages allow you to add elements, while some do not. This is good and bad. It keeps websites cleaner and better looking if those using the design tools aren’t familiar with design, but it also cripples your ability to design if you do understand how.

You can change colors. But you can’t add any color blocks or change the location of the text, or how the text alignment, etc. You can’t add a photo and change the size or move it around. The design is foolproof but kills a creative mind.

One problem was trying to make the homepage a catalog page. There were ways to add featured products and collections, however, clicking on these would then take you to a product page or another catalog page. It was adding steps. To get around this, we used a simple image and text element with a button and linked this button to an ordering page. While there is one extra page for ordering, it’s better than having multiple added pages.

Another reason this was necessary was to ensure we could use an app for quantity bundle discounts. There are some free apps. They allow you to apply a bundle to only one product before you need to purchase the app. We had 4 products. In order to get discounts on all 4 products, we created one product with 4 variations. This allowed us to use a free discount app. The app we chose was QD because the discount information wasn’t obnoxiously placed on the product page.

What do you hate most about Shopify?
I can’t move anything or add what I want, ie. text and photos.

5If you had it to do over again, what would you do differently?
Find a theme that matched as close to what I wanted first. I wasted time trying to get something to work that probably never would have.

6How much did Shopify tempt you upselling paid features?
I didn’t feel tempted because I didn’t want to buy anything. But, they do cripple you so much that they make purchasing more apps and features appealing. It seems easier than figuring out a workaround.

7What was the hardest limitation to deal with?
The set elements and trying to get their idea of a homepage to work with what we actually wanted as a homepage which was a catalog.

8What helpful tips would you give someone learning Shopify?
Keep it simple.


9What were the original goals for the project? Did you achieve them?
Create a storefront using Shopify. The home page needs to be a catalog page. There should be product pages for each product. It should integrate with a WordPress site. I think I did manage the original goals, but we also found out that more had to be done on WordPress than originally thought. Shopify would not let you have product information pages for what we wanted, so Shopify became strictly a store. The WordPress site will need to have the pages for product information and contact information while Shopify manages the store by using a catalog home page, an ordering page, and a cart. The ordering page is similar to the cart, but we can’t get around that.

Our contempt is about fake freebies. Shopify is a bait-and-switch worst-case and best-case an upselling ploy. They deliberately cripple the product so it’s practically useless. This is a common marketing strategy deplored by idealists. Unless it is the idealist’s business that profits from it.

NOTE: Why were we even tempted to examine Shopify when we write about WordPress speed?  It’s a struggle to get 3- to 4-second page loads on shared hosting with WooCommerce. But when “free” is your criteria, Shopify is insufficient in that class.

Conclusion: We scrapped the idea of a hybrid site combining WordPress blog and a Shopify store. To restrictive without shelling out money for extras.

Online speed test *scores* are ineffective for mobile speed improvement.

Online speed test scores are especially useless. These include lame tests like Google PageSpeed Insights. Many test-result recommendations don’t make any measurable difference in speed. They’re not real-world practicalities. They sound rational and appeal to logic. But they’re a waste of time and energy. You’ll drive yourself mad attempting to achieve perfect test scores. Google doesn’t even use test scores in page ranking.

So if speed test scores don’t matter, what does? Forget scores. It’s load time in milliseconds and page weight. Cumulative file size (page weight) is expressed in kilobytes or megabytes. Load time and weight make the biggest difference, especially for mobile audiences. Speed is critical for a good user experience (UX). Readable, relevant content is most important for SEO. But impatient visitors won’t wait for slow pages. Then you waste your hard-earned relevant content and it’s never seen. Most sites are “not good enough” for mobile users.

Google gives you technical speed suggestions. These are published in their webmaster recommendations. Few make any difference in mobile speed. Why? Is it sadistic torment of website owners? We wonder. The most infamous waste is testing with Google PageSpeed Insights.

v5 of the PageSpeed Insights API was released in November 2018. It now uses Lighthouse as its analysis engine and also incorporates field data provided by the Chrome User Experience Report (CrUX).

We still feel this version 5 is the most inferior speed test for site evaluation.  We don’t recommend it. Google conveniently now excludes Google Analytics and Google Fonts from the scoring. What? You’ve got to be kidding! Those things slow sites down – and they’re sweeping that liability under the carpet? Absurdity. Biased results. They changed the scoring so everyone wins. It’s a fake guarantee. So what do we recommend? or

Google PageSpeed Insights mobile test results for PagePipe homepage. Perfect but still lame recommendations cause site owners anxiety. Wasteful expenditure of time and energy.
Google PageSpeed Insights desktop test results for PagePipe homepage. Perfect buts still insane recommendations cause site owners anxiety. Wasteful expenditure of time and energy.

Here are some weird things Google often recommends *fixing*:

1Eliminate render-blocking JavaScript and CSS in above-the-fold content.

This imperious rule is a great waste of time. WordPress almost always breaks this rule. The return on investment in improved speed is impossible to measure. It’s so small and insignificant. And there is a high risk of breaking your site. If this *fix* tempts you, you’re a programmer and should leave PagePipe. You’ll hear disturbing things you don’t like here.  Plugins don’t help much – like the oft-recommended Async JS plugin. Work on other things that are more important like image optimization or removing heavy assets like chat, sliders, header video, and third-party services.

Deferring Javascript while loading means taking Javascript to the bottom of the HTML document. This will cause the Javascript content to load last. If you load jQuery last, you’ll blow WordPress’ brains.

2Minify and concatenate CSS, JS, and HTML files.

These improve your score – but rarely improve your speed. Scores are meaningless. It’s milliseconds of load time that count. Minification plugins frequently break sites. We don’t use a minification plugin on PagePipe. We’ve experimented with many. They make no difference in speed and only cause problems with Easy Digital Downloads plugin – among others. Does that mean we never use minification? No. If nothing breaks, fine.

Trimming HTTP requests cut down on the number of calls to your server. The big theoretical gain is from concatenation (combining or lumping) JS script, HTML and CSS files together. These can break your site – white screen of death. It’s not worth it merely for irrelevant score improvement.

3Reduce server response time (TTFB 200ms).

This goal is laughable. TTFB is time-to-first-byte. It’s a measurement of server response time in milliseconds. Even Google’s home page can’t produce 200-millisecond time-to-first-byte specifications. That is because of HTTPS / SSL certification which introduces an additional 400 to 500 milliseconds of handshaking delays on the server.

Try on the *peerless* PageSpeed Insights test. They can’t even pass their own tests on the simplest of pages. Enough said. Zero credibility.

How much load time does take? Using online test (owned by Google), the result is 2.196 seconds. The full-load time can vary from 1.270 to 2.204 seconds depending on the test server location. That’s right: seconds. Not milliseconds.

4Optimize images.

When is optimizing images worth it? Well, we tested a page and Google PageSpeed Insights said we failed. Why? Because we could still optimize two images by 2 percent. What!? That’s ridiculous. And it didn’t detect resizing one image dimension to save extra weight. That was more noteworthy.

Is it worth optimizing to remove 2 percent? No. Why? Because images are loaded in parallel. Improving image weight doesn’t make as big of a difference in speed anymore. Browser image loading is faster now.

Should we still optimize images? Yes. It’s important. But we can’t only optimize images and say we’re done.

Imsanity is one of the best plugin solutions for automatic optimization. Why? Because it’s easy to set image size reduction to column-width size and also set the JPEG image quality to 70. WordPress default is 82 but only on cropped images – not on uploaded originals to the media library. Imsanity crops originals. Most other image optimizer plugins charge money once you pass a certain threshold number of images. So beware.

What’s better is plain-old, manual sizing and visual, save-for-web optimization in an image editor like Photoshop, GIMP, or pixlr. scores a 90 mobile. And desktop: a 99. I guess now we know what the standard is for Google’s own self-created criteria. Google itself. Please. Mercy.

It’s not enough to just compress the images. Specify the dimensions of the image, or else the browser loads the entire image and then mathematically resizes it to the required dimensions. Stretching with browser math delays image rendering.

5Avoid landing page redirects.

Simply configure your WordPress site. Go to the “Settings > General” page. See if “WordPress Address (URL)” and “Site Address (URL)” options include “www” prefixes. If they do, remove them, save the settings and that redirect will be gone. Tip: Use the Redirection plugin when removing old posts to protect SEO.

6Leverage browser caching.

Browser caching is beneficial for return visitors. That’s about 20 percent of your traffic. On a well-optimized site, caching doesn’t help much. When an unprimed cache loads in 750 milliseconds, how much better do you need to get? Adding a caching plugin may get the speed down to 400 to 500 milliseconds best case. That 350 millisecond gain is good – but not if the caching plugin is complex or breaks your site with concatenation. We only recommend one caching plugin and it’s Cache Enabler. Make one simple setting: change the far-future cache expiry to 8760 hours (1 year). You’re done.

Now, will a caching plugin get your sluggard 20-second page load down to a wonderful 2 seconds? No way. You won’t even measure a noticeable difference.

Tempted to use paid WP Rocket plugin? Consider this first.

7Prioritize visible content.

Ridiculous. How do tests propose we do that on a WordPress site? This is sometimes referred to as above-the-fold content. Over-optimizing for speed is not worth the frustrations fixing the problems. Run a PageSpeed Insights test on Wikipedia or YouTube. Bet the scores are crummy, poor, or *needs work*. Suggestion: Ignore this silly test result.

8Enable compression.

This just means switching on Gzip compression. If it’s not already enabled on your server, it’s a piece of cake with a plugin like Far Futures Expiry Header.

Other odd recommendations that usually don’t help speed much include:

  • Content Delivery Networks – CDNs are servers located in various geographical locations. They are closer to the users’ location and can reach content to them faster than the original server. A well-optimized site doesn’t need CDN. It’s a band-aid. Cloudflare has a free plan that we recommend you avoid. That’s right. Don’t use it. It slows down or delays your pages.
  • Accelerated Mobile Pages – Ignore making your webpages Google AMP compliant. This wasteful gimmick was announced by Google in October 2015.
  • Database Optimization – A periodic check and spring cleaning of databases to keep them lean and easily searchable. Cleaner plugins remove duplicate data, unwanted post revisions and more. Do they help with speed? Not anything we’ve ever detected. But it sounds like a good idea. We do it regularly. But it’s a matter of being vigilant and sleeping well at night. We’ve never seen a speed improvement.
  • Removing query strings from static resources in CSS and JS files – Developers use “?” and “&” to bypass cached files before they are purged. However, URLs with “?” and “&” are not cached by some servers. You can use a plugin to remove them. This removal improves your score but not your speed. Remember, caching doesn’t help so much.
  • Combining Images Into One – CSS Sprites – CSS Image Sprites were born out of the need to reduce the number of HTTP requests made on a website. The typical use of image sprites is for icons. This is where you bunch multiple images together into one big file. This is not very helpful and frequently won’t work on mobile-size screens. We say, “Forget sprites.”

So if those test parameters and tricks only help with scores – but not speed differences. What does matter most for speed improvement?

1. Themes without bloat. Popular themes like Divi and The7 alone take seconds to load – without any content or plugins. A typical responsive, free, stripped, WordPress theme with no bells-and-whistles loads in 40 to 50 milliseconds. Simplify.

2. Good Hosting – And we don’t mean expensive. If time-to-first-byte is too long (over 1 second), the only choice is changing your hosting service provider. You can have fast TTFB on shared hosting. We get around 250 to 500 milliseconds on cheap GoDaddy hosting. Test at

3. Lazy Loading – enable lazy loading for videos and images.

4. Gzip A compression technique reduces code files for faster transfer. It also saves mobile bandwidth.

5. Reducing Redirects – Get rid of as many redirects as possible. Redirects are good for SEO traffic. But you slow down the browser a little.

6. Disabling Trackbacks and Pingbacks – Trackbacks (manual) and pingbacks (automatic) appear in content moderation to let you know that someone else has put a link of your post on another blog or site. Most of these links are spam. It there’s too much of it, it can affect site speed. Disable them under Default Article Settings > Settings > Discussions. Or we can use a plugin that can deal with spam, like No Self-ping. Or use XML-RPC deactivation.

7. Disabling Hotlinking – Sometimes other *web criminals* use the content hosted on your site’s servers for their own websites. This is simply an extra load on your server. To stop others from using your server resources, the recommendation is changing your server .htaccess file code. A plugin will do the trick.

8. Identify plugins slowing down the website. How much will this help? Our experience is you may save up to a second. That’s great on a site that’s loading in 4 seconds. But if it’s a 20-second page, you’re still in trouble.

Remember, it’s not the number of plugins that slow down a site. It’s the quality. We have 43 plugins. Our homepage and most others load in under 1 second on shared hosting.

Use the performance report generated by the P3 plugin to remove or selectively disable the worst plugins dragging down site speed.

9. Selective activation of plugins Our best secret weapon for speed.


The best way to manage Google Maps for fast mobile websites.

Something we see bogging down homepages is the faddish inclusion of a huge Google Maps dynamic graphic. Often the trendy map isn’t needed on the homepage – or it isn’t needed anywhere! It’s gratuitous interactive bloat.

We understand needing a good map and directions. Especially if you’re a brick-and-mortar store – or have offices where you meet clientèle. Or you run a restaurant. Then people need to find you. We get it. So what can you do to keep your pages lightweight – and still have an interactive map?

First, let’s examine how heavy are Google Maps? They use an API (script) to call offsite web assets from Google’s servers. You can’t host these bits and pieces locally. That means the assets for maps aren’t cached. There are delays when servers talk to each other.

Often, Google Maps add at least 500k page weight. That’s our observation. But others have seen worse speed damage than this. More on this in a minute. Depending upon how you install Google Maps, the page weight loads on every page and post of your site. Even if only using a map on one solitary page. Global loading of a plugin or script is site drag. Most site owners don’t even know site drag is a potential liability.

To load the typical Google Map, it takes about 70 requests which is 2 megabytes extra page weight. Or up to 2-seconds load time. On slower connections and especially mobile ones it’s even more. – Offsite resource

Why does a map take so long and is so heavy? The majority of site owners use the easiest plugin installation – an iframe method. It gets the job done. It begins *building* the dynamic map from remote components during page load. It doesn’t take into account if the visitor is looking at the map – or interacting with it.

Instead of loading dynamic map data chunks, it’s better to load one single, static image. That’s about 50k file size. That takes a fraction of the time. The user clicks the static map. The interactive version then loads in a new browser window or on a new page. Simple offloading trick.

We prefer to open the actual Google hosted map page in a new window and not embedding the map into a local page. This completely offloads all heavy assets to Google’s servers and hosting.

How do you get a static map image? There are two simple ways we like. First go to Google Maps and use their tools to build the map the way you want and then do a screen capture.

Another way is to use an online free tool.

Go to Static Map Maker and use the form on the left to change the map. Leave the API field empty. We selected the retina option to produce a larger map. You can adjust the width and height to fit your site’s needs. Google imposes a maximum static map size of 640 x 640 pixels. But using the retina setting, you can get a 1280 pixel square PNG image. You’ll want the default roadmap type. Play with “address and zoom” to get the map you need. The preview on the right refreshes as you make changes.

Google Static Map Maker free online tool – click or tap above. The resultant file weighs only 39k after image optimization. The destination Google Maps page weighs 1M and loads in about 6 seconds. Let Google keep that load with 122 requests on their site – not yours.

This PagePipe speed tip is the fastest way to manage Google Maps for mobile websites.

Somebody changed something at Google. Now your map and driving directions are broken again.

We recommend future proofing you map page from Google changes.

Insert a screen-capture, static JPEG image and make it an image link to open a new tab with Google Maps. Keep maps heavy load off your site. Keep it on Google site instead.

There are two resulting benefits: your site is always fresh and current – and your site loads faster.

This is the best way to handle Google Maps especially for mobile devices. And it always works.

So deactivated your Google Map plugin. It’s no longer needed.

SiteGround and poor mobile speed.

SiteGround isn’t always kind to their customers. We probably only get whiners coming to PagePipe searching for change. Speed anxiety is their motivation.

SiteGround’s home page says, “Latest speed technologies are our passion.” We also have a passion about speed. But we say, “You can get WordPress speed on ugly, cheap servers.” SiteGround thinks no one knows more about speed than they do. Experts? Really?

PagePipe home-page loads in 900 milliseconds cached in our browser (at this moment). 1-second – even with cache cleared. That doesn’t mean we walk with the speed gods. It means our load time is good right now. We catch it behaving “just fine” much more than we find it failing. If it’s good for 80 percent of the time. It’s “good enough.” How far does it drift, ±50 percent. Horrible, huh. We don’t have an expectation that GoDaddy delivers better than that. Nor are we paying for better speed.

But more often than not, GoDaddy delivers 200-millisecond TTFB or better. Go figure. At his moment, it’s 139 milliseconds. That’s strange – but what we usually get. The other day a test was the worst we’ve ever seen, 15-second TTFB. Why? We don’t know. But that’s really rare. But we caught it. Are we ashamed? Nope.

Do we recommend GoDaddy? Of course not. They’re cruddy. We’re proving a point about cheap speed results. No SSD drives. No hopped-up CDN. No server caching. Only vanilla, shared, magnetic hosting.

If site owners don’t care about speed and choose ignoring it deliberately, then no big deal. It’s a business decision and choice everyone gets to make.

Do 1-second speed reports matter for desktop? Not much. But for mobile, it’s significant. Those translate into less waiting. In fact, they theoretically  load at user-expected desktop speeds. For site owners with 70-percent mobile traffic, it’s a godsend.

People’s expectations with SiteGround is 100-percent goodness. Why? Because SiteGround claims having the “latest speed technology.” But it’s just mumbo-jumbo, theoretical speed claims – not actual measurable milliseconds.

Many hosting customers don’t know about speed – or don’t care. In that case, fine. If they are happy, no problem. But to finger point and say, “It’s not our server speed problem. It’s Google or WordPress voodoo or you’re technically stupid.” That doesn’t sit well with us.

HostGator (claim: powerful hosting 2X Faster) and Bluehost (claim: 2-million websites worldwide). Both brag about their prowess. [note: 2x faster than what? a turtle?]

SiteGround is on our radar. No one’s ever written us about SiteGround wonderfulness. We have a self-proclaimed mission to counterattack speed incompetence, hypocrisy, and deception.

Had a wonderful experience with SiteGround? Congratulations. But have you watched your TTFB (server delay) bounce around over time – for top-tier GoGeek prices. Better check it out. READ MORE HERE

Speed trivia? Perhaps. Remember, our grand purpose. It’s saving the Internet from WordPress speed abuse – one website at a time. We help our little corner of the world.

Web work is disposable dust. In the future, new solutions will obsolete our speed expertise. Except humans will continue to abuse and overload websites. That won’t go away. Job security? Nah.

The best and fastest websites and hosts don’t exist yet.

“SiteGround was driving me crazy blaming WordPress plugins and my site’s coding for the problem of slow page loads. They made a simple php script to show that their servers were fast. It then got terrible scores on GTMetrix and Google PageSpeed Insight. It was a simple script. They tried to prove a point, but ended up disproving it. Their simple script loaded slow! Then they said it was a Google PageSpeed problem. I said the times were always inconsistent. They said that was Google’s problem.  What?

I’ll be leaving SiteGround soon. Great customer service for slow servers isn’t worth it for me.

The tech rep who was dealing with my support ticket eventually started getting snarky. He repeatedly said, “… as I’ve said before…” and similar things without trying to understand what I was complaining about or without trying at all to offer or look for a solution.

Eventually, I said I will start looking for a new host, and he replied along the lines of, “Thank you for your time. Please contact us if you have any problems.” Hmm…
I was SOOOO happy to find your PagePipe article as it mirrored my experience and frustration. I really like your analytical way of thinking.
By the way, I pointed my servers to FastComet hosting and although the PageSpeed Insight scores are inconsistent, they are consistently better than they were at SiteGround. My TTFB went from an F to an A at
These are things Siteground said they couldn’t help – because it was the coding of my website causing the problem. More importantly, the GTMetrix and Pingdom times went down. Not by much, but as you know, every little bit is hard earned when you’re under 2 seconds.”
– Kevin Cozma

Thanks for sharing your experience, Kevin.

Half of SiteGround’s speed recommendations are nonsense.

We mean no offense to Hristo Pandjarov.

He’s the author of SiteGround’s free ebook. “SPEED MATTERS: 21 Expert Tips to an Ultra-Fast WordPress Site.” Hristo’s an expert on WordPress speed optimization. He has a video online from a 2016 WordCamp. But we have found a few ideas in his ebook that don’t measure up to our experience and testing. Naturally. But most of his speed suggestions are safe and sane.

SiteGround’s download page requires email signup >

The ebook introduction, says: “Generally, if your website takes more than a second to load – it’s slow and needs optimizing.”

The average page load time is 9.82 seconds. And the average page weight is about 3M. Plainly, the bulk of websites flunk SiteGround and Hristo Pandjarov’s standard of goodness.

“Reducing page weight is practically guaranteed to improve the user experience across the board but will disproportionately enhance the experience for less capable devices.” –

Google is the dictator of all things web. They have an edict that 500 milliseconds to 2 seconds is good enough. But Google doesn’t always follow their own recommended best practices. Weaklings!

Three other self-proclaimed-expert opinions about this speed-threshold topic (we agree with most of it):

SiteGround implies that somewhere there exists a mandated 1-second barrier. Is their hosting service the only method to break 1 second? Speed authorities think otherwise.

Why are they advocating an idealistic or sometimes impossible 1-second goal?

A well-optimized site and SiteGround’s servers on good days can achieve this. We’ve used SiteGround with clients. But it’s possible to do 1-second loads on cruddy hosting too, if you abide by certain principles.

PagePipe: SiteGround’s feeble explanation of bad TTFB for hosted WordPress sites. >

Good mobile user experience needs the fastest page loads.

One second is instantaneous gratification for users – and has been for decades. But 2-second loads are a more realistic optimization and performance target. And those are desktop hardwired speeds.

What is realistic on wireless mobile? We suggest the performance budget is 3 seconds. That is also the user expectation – for today anyway.

From this web study, 4 seconds is average mobile speed.

You can waste a lot of resources attempting unreachable maximization (100 percent). Optimization, or 80 percent return, is more affordable and realistic. Avoid waste from gold-plating or over-engineering your website.

Note: PagePipe’s Home load time is under a second (most of the time) – sometimes 1.2 seconds. We use cheap GoDaddy “evil” because our goal is good speed results even under bad conditions. We practice what we preach. Just like Google. Ha!

1 Identify and Prioritize Issues. SiteGround lists GT Metrix and Pingdom online tests for speed benchmarking. Easy. Knowing what the test means takes some educating and reading. Learning curve stuff. Our preferred test is that’s geared for professional optimizers.

SiteGround gives a good piece of advice about speed testing:

“Even though most of the benchmarking tools will give you a ‘grade,’ don’t go too far chasing it.”

And this supportive quote below is from WP Rockets FAQ page about ratings:

“Performance ratings are mainly indicators of good practice. Ratings tools check that the optimizations have been made. These ratings do not indicate, however, the actual speed of a site, they are only indicators. Good ratings do not guarantee a fast site and vice versa. The actual page load time is the most important metric to look at.”

We’d add to that our puny opinion: “WordPress – by it’s very nature – cannot pass many speed tests. At least, not without major expenditure and effort. In the end, those improvements will not necessarily make the site faster. And speed (human perceived load time) is the only thing that counts – not scores.”

2 Reduce the number of Posts Shown on the Index Page. This is only a problem when the blog-listing page is the Home page. Then it may show too many featured images – if they are used. Installing a lazy-load plugin fixes this. We recommend Rocket Lazy Load plugin.

SiteGround recommends an infinite scrolling plugin or changing WordPress for “show at most” values. Those are good ideas. But, infinite scrolling can activate jQuery and add page weight, too. So test before and after installing any infinite-scroll plugin.

SiteGround also recommends pagination of long pages into sections using the <!–nextpage–> tag. An easier method of insertion is using Page-Break plugin. It adds a control panel button.

3 They recommend getting rid of sliders and using just one image. We agree. We’ve written about slider extravagance before:

PagePipe: What slider is the fastest loading? >

SiteGround recommends two other slider plugins we’ve tested before. We weren’t that impressed with the load times. Our extreme speed philosophy is no sliders on the Home page. Period!

4 SiteGround recommends using appropriate image sizes. Again, we agree. They don’t have a plugin solution recommendation but our safeguard utility is using Imsanity plugin. We also use this plugin to solve the next problem they talk about:


5 Optimize image size without damaging quality. This is referring to visually-lossless image optimization. We set Imsanity plugin at a quality of 70. We have a free PDF download about image optimization best practices >

And we have several articles about using image optimizer plugins and alternative web tools:

PagePipe: Quality-82 image-compression change for WordPress >
PagePipe: How the ShortPixel plugin eliminates needless junk >
PagePipe: Top-dog, image-optimizer web utilities >
PagePipe: WP Smush plugin doesn’t really help with speed >

SiteGround recommends using EWWW image Optimizer plugin. We don’t recommend it because it can cost money. We’re pro-free stuff. And there are plenty of other free alternatives and strategies. EWWW isn’t the best image optimizer as supposed and reported by many. It’s just one of a multitude of options.

Nothing will ever beat just optimizing images by-hand. Use an image processing program (like GIMP or Photoshop). Do that before uploading images to the WordPress media library.

Our most unpopular but best speed recommendation: Don’t use images whenever possible. That’s right. None. Just design with text and unicode symbols.

If you must use large images, don’t make them JPEG photos. Use PNG illustrations instead with limited color palettes. This produces the smallest, fastest file sizes and reinforces your branding.


6 Reduce the usage of external fonts. We agree with this suggestion but we go even further. There are various plugins that can “exorcise” this font fluff. Our recommendation is Disable Emojis and Remove Google Fonts or Disable Google Fonts plugins. We’ve used all these plugins.

Or choose a theme that doesn’t use any webfonts – just websafe ones. Yes! Those themes do exist. We’ve written about those, too;

PagePipe: Speed report: 35 theme candidates >
PagePipe: 15 free themes are prime candidates for testing aesthetics and customization >

To get rid of Font Awesome, you’ll need to use Asset Queue Manager plugin. This plugin can “break” your site with some themes so proceed with caution. But we love this plugin and use it a lot to strip down bloated themes.

PagePipe: Websafe fonts are still the hottest >

7 Manage the volume of comments on your site. This isn’t the first we’ve read about comments slowing down sites. But we haven’t seen any real data to prove it (yet). We know a few reasons why comments in theory cause slowness from database issues. SiteGround makes two plugin recommendations for comment management. But we’re more hardcore about achieving goals and streamlining sites. We say, “Get rid of comments completely.” Read about our radical ideas on comment management:

PagePipe: Should you use Akismet anti-spam plugin?

8 Enable Gzip compression for your pages. SiteGround recommends editing your .htaccess file but don’t say how to do that. So SiteGround must not have Gzip enabled like on some hosts. This .htaccess file edit is not an easy thing for newbies. We think it’s a pain. It’s easier to change the .htaccess file on your server with Far Future Expiry Header plugin. Read more about Gzip:

PagePipe: Update on Gzip Compression >

9 Enable caching. OK. Unlike the rest of the world, we don’t think caching helps much on a well-optimized website. We just never see speed benefits. SiteGround makes two plugin suggestions. WP Rocket, a paid plugin, and WP Super Cache, a freebie. We’ve experimented with both of them and like we said: “We aren’t sure they help much.” Yeah. They’re band-aids for sloppy-built websites. But don’t help quality sites.


The recommendations in this section are kind of silly or else just common sense. Someone must have been trying to fluff up the report with filler. SiteGround then goes on to tell us many things we’ve already covered:

10 Select a reputable theme from a solid provider. We only use free WordPress themes from their repository. That is our choice and self-imposed limitation. It speeds up our decision making and creative process. We don’t have time for shopping. We don’t spend money on complicated “premium” themes. Not us.

11 Avoid bloated themes. Their explanation of what is a bloated theme is good. Avoid sliders.

12 Always use a child theme when creating your website. This is common sense for safety sake. It prevents future updates from overwriting your customization. But what does a child theme have to do with speed? Nothing. Child themes load another CSS file. So this recommendation doesn’t make sense.

13 Optimize for mobile devices. Really? You need to tell people this? And they recommend the plugin WP Touch (non-native mobile conversion). This isn’t good. Even when they afterwards say, “Having a native mobile version is always preferable.” Even that isn’t a good idea. What’s preferable is using a responsive WordPress theme. A mobile version is  a second version of your website that sniffs to detect a small screen device and then redirects to the mobile version. Not the same as responsive which just serves one site – no duplication.

14 When using icons, use an icon font. We despise icon fonts. They are heavy and slow-loading – the bane of speed. We disable icons whenever possible.

15 Don’t overlap functionality with plugins. A good suggestion but isn’t this just common sense again. Don’t duplicate stuff. Simplify.

16 Always keep your plugins up-to-date. This is just good housekeeping. Staying updated and current helps speed? We haven’t seen any evidence yet. SiteGround claims it’ll give your site a huge performance boost. Serious? Got some experiential proof of that? Or is it just theory? Or exaggeration?

17 Cleanup your plugin options from your database. We do this as best practice. Again, it’s seems like just common-sense good housekeeping to us. We’ve never seen any speed boost yet from cleanup – even with big fat databases. There are several plugins to do this. We don’t make a recommendation. We’ve tried them all and it gives a nice feeling that you checked the databases and verified. But no speed improvements whatsoever measurable.


Now we’re into the promotional selling materials of the brochure. In other words, SiteGround specific features they hope to motivate us to buy.

18 Take advantage of sever level caching.

This is pure specsmanship and boasting about SiteGround’s capabilities.

19 Use a CDN. We’re not sold on CDN’s. They don’t help much for a  well-optimized site. Just like caching. If you need a CDN, it is indicative you didn’t build your site as well as you thought. Another speed band-aid. The author said in his video to test CDNs since they can slow down your site. Good advice. That’s our experience with free CloudFlare. Slowed by server 500 and 501 errors. Longer TTFB (time to first byte). Badness.

20 Use SSL and utilize HTTP/2. This is a nice way to upsell and make money for SiteGround. These aren’t necessary  for speed. SiteGround was kind enough to mention a free alternative. Secure third-party transactions like with PayPal means this stuff isn’t needed.

So what’s missing?

We think social links are a big culprit for site drag. That isn’t mentioned anywhere in the Ebook. Most site owners don’t realize social media gives little benefit. But they feel like an outcast if they don’t have it. Yes. There’s stigma to conform to the herd. Don’t give into this peer pressure. Social buttons and likes slow down pages.

Remember what your mother taught you about peer pressure and popularity. They can be bad news.

If you have to use social media, use static image buttons or CSS buttons links instead. The fastest loading social-sharing button is none. Do value analysis. What kind of return are you getting on your social media? Is it a time waste generating that social content?

Hristo advises on another blog against going overboard with Social Media widgets or plugins. He just forgot to include it here. Social widgets and plugins ping their respective servers, delaying page loads. Particularly, Hristo says not to use IFRAME. He recommends using one plugin that covers all the social networks. (Facebook, Google+, LinkedIn, Twitter, Pinterest etc). Don’t use a separate plugin for each network. Again, we think social media is as useful as a cast-iron paddle in a chicken-wire canoe.

We disagree with this ebook, web hosting isn’t key to great performance.

We’ve seen sites on great hosts (including SiteGround) with lousy speed tests. It’s more essential to use speed strategy for balancing aesthetics and speed.

They said nothing about failing some basic Pingdom tests and the simple plugin solutions:

Query Strings Remover 1.5k
Removes query strings from static resources like CSS and JavaScript files. This plugin claims it will improve scores in Google PageSpeed, YSlow, Pingdom and GTmetrix. Just install and forget everything, as no configuration needed. Note: WP Rocket claims removing query strings doesn’t improve speed, just scores. We suspect they’re right.

Speed Booster Pack 82k
Speed Booster Pack allows you to improve your page loading speed. You’ll get a higher score on testing services. (GTmetrix, Google PageSpeed, YSlow, Pingdom, or Webpagetest). We’ve tested this plugin. We found it’s minification features succeed where other minification plugins caused conflicts or white screens. It’s not for everyone but worth noting here.


The SPEED MATTERS ebook is better than most with good speed suggestions. But plainly selling services. At least it doesn’t perpetuate the myth that speed improves search engine optimization (SEO). That’s always a disturbing lie told by many site optimizers.

Ideas we agree on:

  • We agree performance test “scores” are meaningless ratings. Only speed measurements in milliseconds count. Or even better user perception of fast speed.
  • We agree sliders suck. But we say get rid of them on homepages.
  • We agree on image optimization. We even define how good is good enough in a downloadable PDF.
  • We agree on Gzip. We tell how to activate Gzip using a plugin without editing the .htaccess file by-hand.
  • Social links are baggage. Even though the author left that off. We know he agrees from other blog posts he’s written.

Ideas we disagree on:

  • We don’t think a good host is the key to site performance. We think speed strategy is the answer.
  • They recommend a 1-second performance budget. We recommend 2-second loads for desktop and 3 seconds for mobile as best practice. Even though PagePipe is a 1-second site! Other experts agree. Even Google says 2 seconds is good enough.
  • They recommend EWWW image optimizer plugin. We say that’s poo. We recommend free Imsanity plugin instead. It’s configurable with a maximum width, height and quality settings. And authored by the same guy.
  • We recommend using no images – or substituting PNG illustrations for heavier JPEG photographs.
  • They recommend using Google Fonts sparingly. We say get rid of them completely by substituting websafe fonts for speed. We also say eliminate Font Awesome icon font when possible – and always get rid of emojis. We recommend various plugins to do these eliminations. These are drastic but necessary measures.
  • They say manage (reduce) comments on your site. We say get rid of them completely with a plugin.
  • They say use a caching plugin and CDN. We say these are unnecessary band-aids if you build a quality speed site using strategy.
  • We think recommendations 10 through 17 are common-sense housekeeping or plain silly.
  • We think items 19 and 20 are less-credible selling promotions.

So half the report – the first 9 items – are worth reading. We think they aren’t aggressive enough to achieve their one-second page goal.

All-in-One-SEO Pack is tortuous slow-loading nonsense.

The LTI SEO plugin is the lightest SEO (search engine optimization) plugin built. It’s installed and still works on various client sites. Why? It’s old but not broken.

Clients insist on SEO gyrations. It’s a placebo effect known as “SEO tweaking.” A futile and silly habit for neurotic, obsessive-compulsive dullards. It’s an addictive tranquilizer for the vigilant nervous. Then they sleep at night thinking all will be well in Googleland.

SEO tweaking is self-defeating behavior. It’s insanity. Go ahead! Kowtow to what Google publishes as metric truth. See if it makes any measurable difference. It won’t.

Hundreds of third-world promises: “Get easy number one Google page ranking.” These promises flood my email inbox. Isn’t source credibility a clue of the valueless remedy called SEO?

LTI SEO plugin is not installed on PagePipe. Why? Because relevant desired content is the only thing to quickly alter SEO. The slow way is focusing on speed or rewriting post titles. Yes. We do those things. Those alter user experience. UX has future value. But no guarantees.

Relevant content is the hope. Not SEO plugins! Not gaming the system. There’s no system to game. No game to systematize. Vaporous provable claims or fanboy testimonials are weak. But no measurable proof, research, or data of real ranking improvement.

Millions are wasting and squandering resources on SEO.

We don’t defend any lightweight SEO plugin. Nor defend any SEO plugin – period. They’re an utter waste of human resources. Can you feel our oozing contempt for those selling SEO? And especially anyone claiming speed makes an immediate difference in SEO. Absurd.

LTI is the only SEO plugin installed at customer’s dictatorial insistence. Never volunteer installing SEO baggage. You could substitute 14 other site features with discrete plugins consuming comparable speed.

The “very popular All-in-One-SEO Pack plugin”? Tortuous slow-loading nonsense. We’ve tested it’s speed – 174 milliseconds added on every page and post of your site. But speed isn’t the point. It’s a waste of content writing time!

Content is the user experience.

Where’s the Twenty-eighteen WordPress default theme?

Normally, we write about releases of default themes – and we torture test it for speed. Not so in the 2018 year. Why? Gutenberg delayed Twenty-eighteen theme completion schedule. The powers that be said, “Spring 2018” for introduction. That never happened.

Twenty-nineteen theme‘s official release was October 16, 2018. There is no Twenty-eighteen theme. A hole in the dynastic chain. So someone pounce on that theme name! Great opportunity to confuse the world. And perhaps make money from it.

Twenty Nineteen is part of WordPress core version 5.0 and up.

Disable Gutenberg
Completely disables the Gutenberg block editor and enables the classic WordPress post editor (TinyMCE aka WYSIWYG) for lighter coding and simplicity.

Twenty-nineteen theme is Gutenberg-specific. We recommend two alternatives for speed:


thumbnail of THEME-ME-10-v1.compressed
THEME.ME: What is the fastest free theme? There are 5,100 free themes in the WordPress theme directory. Of those, only 1,602 are responsive. All the rest are fixed-width junk. How did we sort the remaining 1,602 free responsive themes to find the fastest loading?


Twenty-seventeen Default Theme Tips Read our torture-test results of this popular free theme. Don’t get locked in for recurring *annual renewal* theme memberships. Save your money. The Twenty-seventeen Torture-tested Themes ebook contains honest and common-sense reporting and tips about mobile WordPress speed!


Unawares you broke your lovely site activating PHP 7.x.

PHP 7 is twice as fast as PHP 5.x and requires one fraction of the server memory.

Comparison of PHP version speeds.

Does activating PHP 7 from version 5.6 make a difference in speed test scores? There is no measurable load-time difference in milliseconds. None. Why no improvement?

Some claim to add PHP 7 instead of a version 5.6 speeds up page loads by 300 milliseconds on a cache-less site. We don’t see that improvement evaluating with normal online tests like or

On a well-optimized site, there is no speed change evident. But the same can be said about caching plugins, minification plugins, and CDNs. With proper origin optimization, there’s little benefit from inadequate speed fix-it attempts. Band-aids.

Our PagePipe blog is a well-optimized site. So why would we even want to risk a change? We write about plugin technology and speed. We stay current to “walk the talk.” We also have an insatiable curiosity. So we did it.

A 3,760-word article at WP Elevation is about the pain of producing websites. The article expresses everything we hate about website creation. The thought of building “explosive live hand grenades” stresses us. Just reading the article was stressful. Why?

Because it’s true. The nit-picky horrors described are exactly what occurs during web projects. Client or website owner expectations are high. Their technical knowledge is often low.

A new monster arose on the WordPress horizon.

The fragile nature of WordPress and PHP v7.x.

Why does adding PHP 7.x break your site? Our choice to transition our GoDaddy-host-server to PHP 7 rattled our nerves. And we’re initiated in this stuff. Our experience is a good example of what goes wrong. Upgrading PHP version 5.6 to version 7.x is a simple C-panel setting – but not without potential consequences.

PHP 7 released long ago on December, 3rd, 2015. GoDaddy didn’t add this server option for a year and a half. Why? Because they knew the changes might break hundreds of thousands of WordPress websites. They left it up to users to perform the update. And they delayed the service call costs for as long as possible. The GoDaddy default version was set to 5.4. Making users choose their poison was smart. Users then are responsible for breakage. Or dialing back the PHP version themselves – or tracking down fixes. GoDaddy is blameless – sort of.

Above: Pie chart – Percentages of WordPress sites using different PHP versions.

Risk breaking my site? Why even care about PHP version 7.x?

PHP is the code of WordPress, a server-side programming language. It first appeared in 1995. All themes and plugins use PHP, too. Upgrading your site to run on PHP 7 instead of PHP 5.6, you’ll improve the performance of WordPress core by 2x. That’s right. Twice as fast is the typical gain in core speed. We anxiously waited and watched for this no-extra-cost, speed opportunity. Free speed. Most vendors upgraded long ago. So we felt snubbed. But we didn’t change hosts. We like bragging about good speed achieved under the worst conditions!

So how faster does WordPress core load? We should see a 100- to 300-millisecond improvement. But we never see betterment in testing. Updating PHP is a theoretical improvement – not an actual improvement.

PHP running twice as fast doesn’t mean your website loads twice as fast. We’ve never seen significant, measurable differences switching back and forth between PHP 5.6 and PHP 7.3 on various hosts. For us, it’s a theoretical improvement in speed. We think it’s good – but if you don’t change versions – no problem for us. It might be a problem for you at a future date.

PHP 7.x isn’t going to break WordPress – it may cause some of your plugins to malfunction. Perhaps your theme. But the result is the same, your site appears broken. You can test all your plugins using a free plugin. Naturally! We tested with:

PHP Compatibility Checker
Active installs: 30,000+
Compressed download: 1M

With this plugin above, you can check your site for PHP 7 compatibility.

WordPress phpinfo()
Active installs: 20,000+
Compressed download: 8k

With this plugin above, you can check which version of PHP your site is using without using Cpanel access.

Display PHP Version
Active installs: 40,000+
Compressed download: 11k

Display PHP Version plugin displays the current PHP version in the “At a Glance” admin dashboard widget. We like it.

So what broke after the change from 5.6 to 7.x?

  1. Broken Link Checker – compatible – warning 1 – This plugin broke the site when viewed on an Apple iPad. Meaningless code was all over the screen. We disabled the plugin. This is plugin causing site drag anyway. Only us it during maintenance. Leave it disabled. On some host, they ban Broken Link Checker. Why? Because it overloads the server slowing down other sharing domains.
  2. Simple Content Adder – We got a red flag for the file revisions.php. But we couldn’t find it breaking anything. We left it as-is.
  3. SS Downloads – red flag – This favorite old plugin broke the site with PHP error screen. The plugin failed because it triggered a fatal error. The plugin is for email capture before PDF downloads. We had to dump the plugin. Presently, all our free downloads use MailChimp signup. We do product downloads with Easy Digital Downloads plugin on our store site.
  4. Title Experiments Free – compatible but 7 warnings. We wrote plugin author, Jason Funk, and he updated the plugin to version 8.9 for PHP 7.1 compatibility. No more warnings. Thanks, Jason. [Jason later removed this plugin from the directory.] It caused global loading – site drag.
  5. WordPress Popular Posts – compatible – 24 warnings. The plugin stopped gathering data for page visits. This is the primary reason we use this plugin. It’s very popular with 300,000+ active installs (v3.3.4) The new version 4.0.0 is now PHP 7.x compatible. It has slow Font Awesome onboard but it’s not enqueued. We’re thankful. We like the new GUI control panel for the plugin. The original plugin was a 125k zip file. The new one is 759k. Most extra weight is font overhead for the control panel. It doesn’t affect your site’s front end. This newest version is now available on the WordPress directory. We don’t use this plugin any more because of site drag.

How fast was PagePipe home page after the switch to PHP 7.x?
699 milliseconds unprimed cache and 440 primed. Superfast even on GoDaddy mechanical, shared server with no CDN.

So a quick comparison of primed cache:
PHP 7.2: Pingdom NY PagePipe home page – primed cache: 559ms.
PHP 5.6: Pingdom NY PagePipe home page – primed cache: 567ms.

8 milliseconds gain with TTFB fluctuations. Maybe? Insignificant gain on an optimized page. We’d be better off economizing in other areas.

Why no big gains? Because we have super optimized the homepage. There’s a point of diminishing returns. Only fat bloated slow websites benefit from the PHP version switch.

PHP gains are overrated and exaggerated. A bloated site gets the most improvement. So PHP is a cheap test of site bloat. Big speed improvements from PHP indicates a big potential from the investment in site origin optimization.

“None of my speed tests provided clear evidence that my site now loads faster on PHP 7 compared to PHP 5.6.” – OFFSITE REFERENCE:

Future-proof site strategy requires fast and free default themes.

If it ain’t broke, don’t fix it. Changing a site for mere redecoration is absurd. Aesthetic design alterations rarely make a difference in profitability. Graphic complication is often whimsical, not strategic.

Change can cause problems. Before now, it was foolish to update themes to newer versions without a child theme for protection.

Using a child theme was a prerequisite to preserving custom CSS coding. When we recently upgraded a clients theme to “redecorate,” the updated theme disabled the One-click Child plugin completely. That’s not normal. We lost the customization CSS.

There’s more to this site conversion story:

Redecorating and speed improvements made no measurable improvements in web metrics. Those were measured by Google Analytics over a two-year period. That’s right. Bounce rate, dwell time, and traffic count didn’t change for the better. The site under test has 70 to 80 percent mobile traffic. These mobile-first changes made no difference over the short term or long term. The speed dropped below 2 seconds (goodness) from the old speed of 4 seconds (badness). The site was also enhanced to appeal to an all female audience. While this made the site feel much more credible, it didn’t change the traffic quality.

Why did speed and aesthetic changes fail to help this site? Simple. Content wasn’t valued enough by a larger audience. The pie didn’t get bigger or better. The content is written in a mix of formal and scientific writing. It’s boring medical jargon.

You can’t bore people and expect them to stay just because your site is fast and beautiful.

In the past, a child theme (plugin) was the best way to protect custom code during upgrades or updates. But that is no longer true.

Note: Using a child theme adds one request slowing down all pages.

Simple CSS plugin doesn’t add any requests. It’s a faster method.

Custom code is now placed in the Customizer. You’d do this in the “Additional CSS” section. But it is vulnerable, too. It’s better to use a plugin called “Simple CSS.” It appears right there in the Customizer ready to receive your custom code. And protects it during updates, upgrades, or theme changes.

We have an assortment of fast themes from the WordPress directory. We collect themes for evaluation. But those freebies don’t always meet the criteria of longevity and easy updates.

Using stock WordPress default themes for better speed.

Annual default themes are well designed. Annual generic default themes are usually conservative. No cutting-edge experimentation. Our recommendation is using a lightweight default theme. If your site has 70- to 80-percent mobile traffic, small screen users are a priority. Mobile-first ranking is number one for SEO. There are only six WordPress default themes working well as responsive designs and fast loading:

Often people think free themes are low quality. It’s quite the contrary. … Free WordPress themes are actually held to a higher quality standard. All themes in the official WordPress theme directory go through a strict theme review process.

There are some very talented folks in the theme review team who examine and test these themes before they are included into the directory. – source

Swapping generic themes is a torture test. It’s unrealistic to expect themes to be interchangeable. Swapping to another theme is often the same as “nuking” a site by upgrading. Then restoring (reinstalling) the original theme choice and assessing the damage. That demonstrates how resilient a potential theme upgrade is. It may be destructive testing.

You can create a staging area on your server using WP Staging plugin. But you can’t “push back” to the live area without buying the pro version. We do the tests using the free version. Then duplicate the changes on the live site after we verify in staging. It’s not that painful and safer than working live with unknowns.

How long are stock WordPress themes supported?

WordPress core supplies the last three-years default themes with the latest core version. That means they’re fresh. They’re updated for most-recent WordPress version compatibility. That means these are getting special support treatment and attention. Top of the pile.

Is their speed excellent?

Yes. We’ve had good results. Strip themes of Google Fonts, Emojis, other WordPress baggage, etc. Do those modifications with plugins not affected by updates.

Are they designed and supported by

Yes. They’re prime. They’re portfolio pieces for the chosen theme designers. Based on history, we expect active theme support for at least 7 years. And there’s no marketing upselling to pro versions. They’re updated with each new core release.

What if your web developer croaks? Who’s their successor? Will they know what to do? Do you have to scrap everything?

If you fire your web developer today, you’re left with a difficult task of reverse engineering their work. You don’t deserve that vulnerability. It’s great job security for the developer – but not a good practice for you.

The last web contractor is always the fall guy. New developers will definitely change the theme for easiest possible upgrades – for them – not you, the site owner. They charge you to do that. They’d swear at us for our past choices – and say derogatory insults about our skills or mindset.

Most web designers and developers have an odd need to complicate sites. They add whizzy features like animation, sliders, parallax background images, etc. This makes it look like they worked harder. They love gadgetry. But these are the things that bloat a site.

Feature gaps are the things the theme of your dreams is missing.

The feature gap can be closed completely with the use of plugins. … The selection of the right plugins can make all the difference in turning a site that is almost what you want into one that meets or exceeds the needs of your business and your audience. – source

Free WordPress themes tend to be compatible with a lot more plugins than premium themes. This is because all the free WordPress themes in the official repository all have to meet certain standards to be approved. – source

Simplicity is our goal.

If we had a crystal ball, we’d predict theme difficulties or fragility. You can step into a trap. “Who is the guilty party?” That answer to future brokenness varies. Is it the developer’s judgment? The theme creator? The plugins selected? Or WordPress making big changes? WordPress is a dynamic landscape full of potential risks.

The goal is preserving the look and speed while hardening the site for future changes. Then you’re improving website “shelf-life.” Return on investment!

We document site specifications and upgrading procedure as a deliverable PDF. This is a style guide or brand manual. The goal is making it as easy as possible for another web technician to pick up the reigns and keep going. We charge $900 for style guides. That’s because once we hand it over, we’re out of the picture. No more income. Obsolete. The site owner can approach any developer and hand them our blueprint.

Speed websites are not canned or off-the-shelf. It requires a brain. You’re smart enough to figure it out. But how much of your life would you burn up? For us, we’re motivated and curious to learn new things. We enjoy theme experiments to increase our knowledge of future successful projects.

Theme changes have unknowable risks. All projects do. We fail many times in testing before there’s a success. You have to check the grief factor.

We do important tweaking of site speed using the Plugin Logic plugin. It’s a secret weapon allowing us to activate or deactivate plugins using page or post URLs. The URLs are static instead of dynamic. Also known as Absolute versus Relative links. This means if the site moves to staging areas or is migrated, the URLs listed will not change to the new domain URLs. Plugin Logic settings are then pointing to the wrong addresses. Page and posts may appear broken because other plugin functions are not activated.

It makes WordPress look bad when a theme change causes big disruption.

You need a future-proof theme strategy. It needs to support long-term and be fast loading. Claims that a paid or free theme is fast loading doesn’t mean it’s true. We’ve done tests and written about this terrible marketing deception. It’s false advertising. Authors use exaggeration of better speed as a marketing differentiator.

We have investigated thousands of paid and free themes. They both share the same vulnerabilities. We wish paid (premium) themes would have better support and performance. Paid-themes are usually more complicated and have longer learning curves. There are no guarantees you’ll get what you hope or what’s in the demo. Theming companies and authors sellout or go bankrupt overnight. They are under no obligation to support a theme. They can stop at any time.

We don’t like this vaporous aspect of the WordPress world. It’s inherent in open-source volunteer communities. It plagues plugins, too. Even some of the biggest and most popular plugins can go sour.

Technical volatility is a motivating factor to not sell WordPress web services.

So what is the safest and fastest theme strategy? We examined a new website to see if we could speed it up. We asked, “What theme is this? We’ve never seen it before.” He replied, “It’s stock WordPress’ Twenty-sixteen – customized.”

We were stunned.

We never realized you could build on top of one of those generic themes and still have it look great. It requires stripping the theme and then building up features with well-selected plugins. He was using our “speed strategy.”

WordPress is proud of long-term support for their annual themes. It’s a matter of professionalism for them. That works to our advantage. WordPress is not going away. Neither are those annual, pre-packaged themes. From our tests, those featured-and-endorsed themes are fastest.

Don’t throw money at a premium theme. Give Twenty-thirteen through Twenty-nineteen themes preferential consideration as long-term theme solutions. We recommend that direction.

Any theme, paid or free, can be abandoned or even banned. That’s the risk of the WordPress world.

For example, WordPress suspended Zerif Lite, a theme with 300,000 installs for 5 months. Why? Because they didn’t keep widget content active after upgrades. That non-compliance cost that author (ThemeIsle) $35,000 per month in revenue. Today they only have 100,000 installs. Ouch. Big hit.

So we place our bet based upon reading the signs of theme credibility and longevity.

Accelerate theme uses a widgetized front page for homepage customization. It’s a common theme-developer workaround. In times past, its only flaw was when making upgrades. All widgets “retired” to the Inactive Widgets section. They then were installed again one-by-one (drag and drop) to the right locations. It was a confusing puzzle.

Accelerate theme is not the Lone Ranger. All themes dependent on “widgetized” front pages potentially have this same not-so-well-known bugaboo. It’s not advertised – that’s for certain. To fix the errant Zerif Lite theme, the author’s add a stopgap plugin to maintain widgetized page content.

Be wise in your theme selection. Look at free WordPress authored themes first.

The average price for a premium theme is $57.54. – source

Premium WordPress themes have a higher potential for theme bloat. Which is the natural trade-off that occurs with more features and functionality. – source

Should I use “Hello Elementor” theme? Is it fast?

“I’m using GeneratePress (or Astra or whatever) and I’ve heard that the Hello theme is a lot faster, do you think I should switch to the Hello theme?”

If you have to ask that question, you’ve given yourself away as someone who should definitely not try using the Hello theme. – Christian Nelson, friend of PagePipe

Hello Elementor? Don’t use the theme. Seriously. Elementor pagebuilder works with any theme just dandy. It’s not your theme slowing things down.

But 60,000 other people are using it! And it’s free. That means it’s good. Right? Sorry. Popularity is overrated. Your mother told you that. And 60,000 active installations is achieved by many themes that SUCK.

EXCEPTION:Don’t use Divi theme. Please. Ever.

Newsflash: It’s the huge graphics and popups and things like chatbox sliding around the page slowing down your site. Trendy cool features are non-features for speed. They are bricks, doorstops, and paperweights. If you can’t divorce yourself from these boat anchors, you’ll never be as fast as Google yearns. But when is their opinion on speed and SEO ever plain truth. Weasel words.

Why we never evaluate mobile speed with Think-With-Google test results.

Google updated their Think-With-Google testmysite tool. We thought we’d check it out and see if it gave us any valid speed information.

Previously 3 seconds was Good – now it’s Poor!

We’ve run a bunch of test on TestMySite tool – including URL itself. produced a 1.1 second load time. Guess they’re just “average,” too, like us. What a relief! – our store – got an “average” rating also at 2 seconds.

Is this test lame or what?

Source: Google’s published speed groupings are:

Under 1 second

1 second to 2.5 seconds

2.5 seconds and up

So what’s a 10-second site? Extra slow? Man, that’s worse than extra slow. And how about a horrible 25-second page load?  XXS (extra-extra slow)? This test is an embarrassment – a misleading sham.

Their speed test said our page loaded in 2 seconds flat. The contradictory report said, “2.5 seconds.” Which is it then? Make up your mind!

How much money did Google spend creating this wonderful web gadget?

Face it. Very few sites are under 1 second. Even Google couldn’t do it on their model homepage. Perhaps only 1 or 2 percent of the web can make a less-than-1-second claim. This bogus test crushes the spirits of ordinary site owners. Do common WordPress sites have unlimited resources to throw at speed performance? Hardly. And if you are “1 second exactly” are you “fast” or “average”? They say both in their groupings. Confusing weirdness.

Wake up! Speed does NOT affect SEO directly. It affects user experience. UX indirectly affects metrics indicating user intent.

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

The speed test most professionals prefer is for testing speed – and TTFB. That service is also owned by Google – but doesn’t wear their branding. It’s open source and free. Pingdom is valuable, too. Other tests we steer clear of for a variety of reasons. All tests give different results.

Tests like Google PageSpeed Insights are bogus, too. Making their suggested changes may change your score. They definitely won’t change your speed. And, never improves SEO page ranking. Wasted time and energy.

All Google’s suggestions for “improving” our PagePipe store ruins our site’s ecommerce features completely. It’s faster! Big deal. It’s broken. No sales – but dang it’s fast. Don’t trust the recommendations of any speed score.

Speed scores are irrelevant. Only load time in milliseconds and page weight in kilobytes or megabytes are what count for mobile. But isn’t perceived speed good enough on mobile? Nope. The weight loading behind the scenes consumes mobile data allowances. Feature bloat costs mobile users money.

What are the real averages not the ideal averages? We don’t live in a Utopian world using WordPress. How bad is bad?

So how good is good-enough speed?

MachMatrics has answers based on 2018 Internet data:

What is the average load time?
8.66 seconds.

What’s recommended?
Under 3 seconds.

What’s the average webpage size?
1.88 megabytes (M)

What’s recommended?
Under 500 kilobytes (k)

What’s the average number of resources?
115.6 requests

What’s recommended?
Under 50.

What’s the average server delay? (TTFB – time to first byte)
2.11 seconds

What’s recommended?
Under 1.3 seconds

“A one-second delay in webpage time equals a 7% reduction in conversions, 11% fewer page views and 16% reduction in customer satisfaction.”

“We found a clear correlation between a faster time to first byte (TTFB) and a higher search engine rank. While it could not be outright proven that decreasing TTFB directly caused an increasing search rank, there was enough of a correlation to at least warrant some further discussion of the topic.” – source

Those are NOT our recommendations for mobile devices. Ours are:

Load time
2 seconds or less

Webpage size
Under 1 megabyte

Under 25

Time to first byte (TTFB)
Over 1 second is terrible.
Less than 1 second is marginal.
500-millisecond TTFB is good.
100 to 200 milliseconds is great.

Speed is the unofficial gatekeeper to your content. – source

What were the Google-test official recommendations for PagePipe store?

  1. Serve images in next-gen formats
    JPEG 2000, JPEG XR, and WebP are idealistic image formats. The difference they make is insignificant. And some browsers can’t even render the files.
  2. Avoid an excessive DOM size
    A joke? Beyond the skills of most web designers.
  3. Eliminate render-blocking resources
    See reference
  4. Properly resize images
    See reference
  5. Minify JavaScript
    See reference
  6. Defer unused CSS
    See reference


None of these 6 recommendations make a difference in UX, SEO, or actual speed improvements. Instead, they often break the pages.

AVERAGE RATING: PagePipe is divided on two different hosts. The blog is on There is no SSL slowdown on this GoDaddy shared host server. No CDN.

ThinkwithGoogle says, “PagePipe is average.” We call BS. Only 1 percent of the Internet websites load in less than 1 second. That would not include Google’s homepage.

Who owns Uh? Google! Complete load time for 3.637 seconds. That’s a major flunk. And they tried to make us feel bad about ourselves. Shame on them. Average? Bah!

AVERAGE RATING: PagePipe is divided on two different hosts. The store is on SSL is activated on this BlueHost shared host server. No CDN. HTTPS/SSL handshaking adds 500 milliseconds to a page load.

Now this seems really bad doesn’t it. 2.4 seconds? Perhaps hypocritical. But we advocate Kinsta’s Bryan Jackson and his proposed hierarchy of user speed tolerance. It’s good speed strategy. Entry pages (our blog) need to be under 2 seconds. This is where first impression counts most. It’s why we didn’t use HTTPS/SSL on the blog. We need the 500 millisecond boost in speed.

Viewers hate slow pages.

When people are curious enough to enter our store, they’re more tolerant and wait the extra half second for SSL – but over on BlueHost. They are engaged now. Brian says 3 seconds is the upper limit of speed tolerance. It depends upon the user’s perceived value of the expected content. BlueHost has a Time to First Byte (TTFB) of 1.339 seconds. Wow! Slow server overhead. But free SSL. (Not $70 per year per domain like GoDaddy).

What’s GoDaddy’s TTFB for 259 milliseconds. Happiness.

Fixing Think-with-Google’s speed suggestions are practically impossible on a WordPress site. If you pay to have these esoteric changes done, you’ve just wasted good money.

Do yourself a favor and don’t evaluate your site speed with this lame Think-with-Google test. Use or instead. Be kind to yourself and your wallet.

Tiny Hestia free WordPress theme: mobile speed review.

In Ancient Greek religion, Hestia is a virgin goddess of architecture.

Tiny Hestia is a free child-theme that strips down the full-Hestia WordPress theme.

There is no reported visual differences between the child theme and the free parent theme. No changes of style. The Tiny Hestia child theme removes all frivolous scripts to make the theme super fast and clean. That’s the claim. Let’s do some benchmark testing. All tests are done on cheap, shared, magnetic GoDaddy hosting. No CDN.

Version: 1.1.50
Active Installs: 100,000+
ZIP download: 4M

Version: 1.0.5
Active Installs: 5,000+
ZIP download: 785k

Decompressed Tiny Hestia is 1 megabyte. We note: 752k of that is the theme screenshot. That leaves 248k of CSS, PHP, and Bootstrap. Most notably, they removed heavy-loading Font Awesome. It’s replaced with a tiny 1.6k image sprite. The sprite (above left) contains only three icons: a shopping cart, a chain for links, and a magnify glass for search.

Here’s the included theme screenshots:

Main Hestia screenshot.

Tiny Hestia Screenshot speed tests for these themes:

Hestia master 474 millisecond load time. No images.

Tiny Hestia load time 434 milliseconds.

The differences include slightly better speed, better page weight, and fewer number of HTTP requests.

Fat Hestia 〉 256k
Tiny Hestia 〉 83.4k

Fat Hestia 〉 18 requests
Tiny Hestia 〉 10 requests

So what if we optimized Tiny Hestia with some speed plugins? What would the results be then?

Tiny Hestia with speed plugins: Load time is now 225 milliseconds.

Tiny Hestia Before 〉 83.4k
After adding plugins 〉 71.1k

Tiny Hestia Before 〉 10 requests
After adding plugins 〉 4 requests

We’ve been using Magazeen Lite free theme. So we thought we’d compare it. Note: We’ve switched PagePipe to Twenty-seventeen default theme.

Magazeen Lite theme for comparison with the same speed plugins installed.  About the same speed, number of calls, and 15k lighter page weight.

Active Installs: 200+
ZIP download: 432k

Any free theme with a zip download file size of about 500k or less will not include Font Awesome.

For Zip downloads that weigh below 1M, about 30 percent will have Font Awesome included. Font Awesome can add 70k to 300k of extra page weight globally (site drag). 17 percent of these themes will have lighter-weight Genericons. The remaining 47 percent will not have any icon font. The remaining 6 percent will have a variety of different lightweight icon fonts.

There is no easy way to remove icon fonts without messing up the mobile user experience. It’s plain – for extreme optimization – it’s best to start with a theme without Font Awesome.

Below is a list of 45 fast themes we evaluated. None have Font Awesome. They’re not beautiful themes. They only have speed potential. Load the theme up with:

  • sliders
  • huge images
  • SEO plugins
  • third-party advertising
  • Facebook counters
  • etc

And you’ll have a heavy, slow site. Use good speed strategy and common sense creating your website.

Our speed suggestions from the free WordPress Theme Directory:

Aquarella Lite
Best Reloaded
Burger Factory
Cosmica Green
Gama store
Golden Black
Iconic One
Mediquip Plus
PDX Chambers Basic
Responsive Kubrick
Seos Video
Simple Store
Simply Pure
VW fitness
VW Hospital Lite

The speed plugins we used from the free WordPress plugin directory:

  • Autoptimize
  • Cache Enabler
  • Disable Emojis
  • Far Future Expiration Plugin
  • Query Strings Remover
  • Remove Google Fonts References
  • WP jQuery Plus

Is Tiny Hestia optimized special or super speedy?

Not necessarily. It’s better than Big Hestia. By simply leaving Font Awesome out, many trim themes easily have equal speed. But Hestia looks quite nice. And we like the design touches. We recommend Tiny Hestia for improved mobile user experience.



thumbnail of THEME-ME-10-v1.compressed
THEME.ME: What is the fastest free theme? There are 5,100 free themes in the WordPress theme directory. Of those, only 1,602 are responsive. All the rest are fixed-width junk. How did we sort the remaining 1,602 free responsive themes to find the fastest loading?


Twenty-seventeen Default Theme Tips Read our torture-test results of this popular free theme. Don’t get locked in for recurring *annual renewal* theme memberships. Save your money. The Twenty-seventeen Torture-tested Themes ebook contains honest and common-sense reporting and tips about mobile WordPress speed!


Review: How fast is Bimber WordPress theme?

Aggregator websites collect and post syndicated material from around the Web, including news, specialized publishing, or the latest bargains and deals in Internet shopping.

Good aggregation helps readers find interesting news and information. It also gives sites they link to added exposure. They are middle men, but they greatly benefit both sides.

Aggregator websites are all about monetization. Website monetization is the process of converting existing traffic being sent to a particular website into revenue. The most popular ways of monetizing a website are by implementing Pay per click (PPC) and Cost per impression (CPI/CPM) advertising.

A good explanation of aggregator strategy and purposes can be found at

There are many WordPress themes that cater to the needs of this niche market. As near as we can tell, there is no free theme that can do all the necessary features. But there are paid themes and one in particular is of interest: Bimber by ThemeForest.

Bimber has great Mobile UX. Banner ad appears underneath a top feature, thumb-swipable, horizontal scroll. No scrolling jank from the ad shoving things around as it loads on the page. Very nice.


It’s difficult to make an aggregator theme and site load quickly. Aggregators are image intensive and can have 100s of javascript HTTP requests. Because of syndications, ads, and other offsite or third-party assets, we’ve seen aggregator home pages with over 300 calls. Page weights are in the above-average, multi-megabyte range.

Aggregator websites have resource intensive hogs like Disqus, Facebook, Twitter, Google Analytics, YouTube, Vimeo, Google News, etc. There is nothing wrong with using plugins that may be resource intensive, but you need to balance the trade-off of the plugins’ functionality with the speed and optimization of your website. This requires value analysis. Especially for mobile users.

Value analysis includes the following: combination, simplification, elimination, standardization, and substitution. This is strategic performance optimization. A value analysis audit examines every requested component and it’s contribution to site goals. This requires setting self-imposed limitations. Aggregator sites are seductive for adding too many features in the hopes of perfecting revenue.

Perfection has too high of a price. Metrics need to be evaluated. Only 20 percent of assets provide for 80 percent of the profit-producing features.

Bimber theme is touted as a lightweight aggregator theme. Their marketing says they are a “viral & buzz theme.” Those are unmeasurable, unregulated advertising claims. How fast is “lightweight”? Viral and Buzz are jargon, weasel words. This diminishes their credibility.

Test results for Bimber speed reports vary depending upon the date of the test, the location, and the testing tool. Times ranged from best-case 1 second to worst-case 5 seconds. that is quite a spread. And page weights varied from 830k to 1.7M. Again, a big spread. So testing conditions with changing parameters render objective benchmarking a flop. It’s hard to say if our performance goal of a 2-second load time is achievable especially internationally.

The average Internet page weight today is around 2.3M. None of these test reports used a demo page of that size. It also appears that aggregator sites are above average in page weight with above 4M of files. This diminishes the prospect of good speed (under 2 seconds) for mobile users.

Bimber is frequently featured on articles dedicated to fast WordPress themes. Fast, of course, is relative.

The above article claims the following for Bimber load times:

GTMetrix Score:
PageSpeed 89%, Yslow 80%, loadtime: 3.64 seconds, requests: 47

Pingdom Score:
Load time: 981ms, Requests: 61, Page size: 830kB
(Note: Aggregator sites are never this light – under 1M. These are unreliable results. A fake page.)

Google Page Speed Insights:
Desktop: 89/100, Mobile: 85/100

Another recent 2016 test claims the Bimber theme loads within 1.5 seconds. (Pingdom score 84/100 to Amsterdam, Netherlands), Page size: 1.7MB, 83 requests.
(Note: This is a more realistic page weight test. But still too small for any real-world aggregator situation. And only 83 requests is also not a real-world number. HTTP request would be in the 100s of calls.)

“On the (Bimber) homepage, you have a 728×90 ad banner, exactly below the header which will attract your users. A 300×250 is placed within the content so that it would look more like a part of your site rather than an advertisement. This is the most profitable ad placement in this theme.”

Bimber demo framebuster code won’t allow testing on browser-based iPhone simulators. Or on Yslow. So we couldn’t get results there. Yslow tests would have revealed how much lazy loading of assets were really occurring (if any).

About those HTTP calls: there were only 47 to 83 requests on these tests. That doesn’t represent the hundreds of usual HTTP requests that occur on a normal aggregator website. This demo is a best-case scenario. Or a mock-up dummy.

Bimber’s advertising page claims the theme is optimized for Google PageSpeed. We couldn’t care less about this test claim. But we ran the demo page anyway for verification. We got the usual frustrating, boiler-plate, error messages this lame test usually produces for WordPress sites. The scores are meaningless if the page  loads in 5 seconds. Google doesn’t even use PageSpeed scores in it’s own ranking algorithm. Instead, Google uses Time To First Byte (TTFB). Bimber can get good time to first byte under the right conditions (322 milliseconds). That depends most on the hosting service.

Read our article: Why we don’t use Google PageSpeed Insights. >

Also offsite links:
Why you Shouldn’t Care About Google PageSpeed Insights

Why Trying to Get 95+ on Google PageSpeed Insights for Your WordPress Site Will Drive You Mad!

Our own Bimber PageSpeed Insights test results.

>Mobile 90/100, with the usual WordPress unachievable error message of:
“Eliminate render-blocking JavaScript and CSS in above-the-fold content”

Desktop 94/100, with the following absurd warnings:

  • Enable compression
  • Eliminate render-blocking JavaScript and CSS in above-the-fold content
  • Leverage browser caching

We know those things are being done as best as possible. This is a sales demo after all.

Bimber on iPhone.

What is of more benefit is testing with Ironically, an open-source tool also sponsored by Google after a buyout.

Our Bimber demo page test with
weight: 1.3M
First View (cleared cache): 3 seconds
Repeat view (primed cached): 2 seconds
Requests: 50

Fully loaded: 1.7M, 5 seconds cleared, 3 seconds primed.

This data shows the demo is “lazy-loading” about 400k of assets. But they are not using a lazy-load plugin. It may be part of the Google CDN feature or built-into the theme. We’re not sure. Most (half) images are stored in the media library.

The most important thing for SEO is Time To First Byte. Bimber TTFB is only 322 milliseconds (very fast) when hosted on a fast NGINX server (not Apache based).

But this speed number only influences less than 1 percent in the Google algorithm. Relevant content will always superseded speed for ranking. Speed is not a significant SEO factor. It’s a major UX factor.

The Bimber demo uses two free plugins from the WordPress plugin repository.

  1. Sitelinks Search Box
    Free plugin so people can reach your content more quickly from search results. If you use WordPress SEO by Yoast plugin version 1.6 or newer, you don’t need to use this plugin, as this feature has been included in the version 1.6 update.

After activating the plugin you only have to “Wait for Google Search algorithms to identify your site as a candidate for the new sitelinks search box”.

2. W3 Total Cache plugin
This is a popular plugin (over 1 million installs). Some people swear by it. But from our tests, we’ve never had improved speed results on a well-optimized site. The demo is successfully using WTO plugin for minification and content delivery network support. But other alternatives exist.

Note: W3T caching plugin wouldn’t be our recommendation. The most raved about caching plugin is WP Rocket. It’s a paid plugin we’ve never tested. And never will because all our tests of other available caching plugins reveal they only help improve speed if your site is grossly bloated. If the page is well optimized, there is no improvement whatsoever with caching plugins.

Elements that are significantly delaying or improving Bimber demo page load time:

  • At least, 1.5 to 2 second load time delay is for Facebook API JS libraries connections and calls. Out of 5 seconds total Facebook is a huge problem!
  • JS and CSS are minified and concatenated. This improves speed and is most likely being done with the W3T plugin.
  • The demo uses GStatic CDN (Google) to offload JS/images/CSS – and probably fonts. But mainly images. There are some blogger complaints that GStatic CDN does NOT improve performance and actually slows down page loading. It would require benchmark tests. We see CDNs as band-aids for sloppy web design.
  • About 1M of images on the Bimber demo page could have been compressed further by 379k (almost 40% reduction in file size — visually lossless). The speed gain would be less than a second – but worth it.
  • The demo page uses the Google viewport meta tag which means the content is optimized for mobile content. A viewport controls how a webpage is displayed on a mobile device. Without a viewport, mobile devices will render the page at a typical desktop screen width, scaled to fit the screen. Setting a viewport gives control over the page’s width and scaling on different devices.
  • The demo uses built-in Aggregation Functionality plus Pingbacks, RSS, Really Simple Discovery, and Window Live Writer Support. All of these things cause “drag” because they are offsite calls for assets or code.
  • We don’t know if the following are standard Bimber theme features or not: The demo also uses Open Graph Protocol (supported by Facebook). And Twitter Cards for linking content to Twitter. These cause drag.
  • Bimber uses “scrset” in their theme code for adapting images for high- and low-resolution displays. (Good for iPhones and iMacs).

Bimber Theme Conclusions:

Bimber theme has all the bells and whistles any aggregator business would love to have. It’s mobile UX is superior. It’s $49 price tag is cheap. To get load times below 5 seconds will take work. In the final speed analysis, every single HTTP request must be evaluated for contribution to site value.

Is GTMetrix a good-enough speed test?

I got 100/100 in GTMetrix. Is my site now good enough?

Scores represent principles that make little speed difference for most user experience.

What counts?

  • load time in milliseconds
  • page weight in kilobytes
  • the number of requests

Scores aren’t on the list of importance for evaluation. Even the number of requests isn’t super important because of browsers loading assets in parallel.

Speed scores are artificial or superficial criteria based on the original concepts of the Yahoo Performance team. In particular, Steve Souders the mastermind behind Yslow Score. Google pirated Sounder away to their team where he invented PageSpeed Score. It wasn’t innovative but a clone of what he’d done before. Now more extreme. (Impossible?) He coined the title performance engineer and page speed. At Google, he established the same obsessive-compulsive criteria that evolved into PageSpeed Insights test. He also influenced other ideas like introducing speed into the Google ranking algorithm to persuade compliance.

Google hand-waving about speed is self-serving. It’s about them making advertising money. Making the web a better place is a noble cause to get site owner buy in. Ads slow down websites the most and are unmanageable. So Google has us focus on other distracting trivialities.

Google never let speed influence page rankings more than 1 percent. In fact, it’s closer to 0.5 percent. But no one knows for sure because Google doesn’t publish this proprietary secret information. The idea that a “standard” exists influences myths regarding web speed. And pushes site owners to waste time attempting to achieve a Utopian ideal. It’s inefficient.

All online speed tests (Pingdom, GTMetrix, and many others) are interpreting Google criteria for goodness. It’s extreme or invalid to the point even Google can’t pass their own insane tests. This ivory-tower speed snobbery is out of control. In other words, it’s excessive and impractical.

The good news: scores are NOT used in the Google ranking algorithm. Only one speed parameter counts and that is Time to First Byte. TTFB is host-server dependent and beyond the control of website owners. They can only cherry-pick a better host with lower server overhead and change hosts. A good test for TTFB is

Our best-practice suggestion is to take 6 consecutive TTFB readings and average the results. Assume your worst TTFB in milliseconds is more common than the average reflects. How does that affect your 2-second performance budget? Take 2000 milliseconds and subtract the worst-case TTFB. That’s how much time is left to load your best pages. Hurts doesn’t it.

Speed doesn’t have the same valuation on all pages. You don’t have to be under 2 seconds all the time. What? Not all pages have equal importance to visitors? There is the primacy effect or halo effects influencing how a site is perceived. First impression counts. After the first page experience, people are more forgiving if speed was initially exceptional. Your 10 most popular posts or pages need to be the fastest possible. Less trafficked pages can be a little slower. If you’re using WooCommerce cut yourself some slack. Relax the performance goal to 3 seconds.

Speed does NOT affect ranking immediately. It affects SEO over time. Speed improves the user experience (UX). That’s measured by user intent. That’s derived from metrics like dwell time, bounce rate, and return visitors. Google search then knows visitors are finding what they search for on your site.

A few articles help explain Google’s speed oddity:



“I’m still not happy. My PageSpeed Insights score is low.”


“Think-with-Google ranked my site as just average … above 2 seconds.”

Please don’t use Think-with-Google test:


Even scored average with this Think-With-Google test. Only 1 percent of websites have speeds of less than 1 second. Focus on website content instead. If you’ve made it under 1 second: Time to stop. Remember less than 1 percent of the Internet achieves this perfection.

Try not to use CDN band-aids for speed. If you are using free Cloudflare, it’s not good. It’s especially a waste of money if you’re paying. You can achieve the same results with free origin optimization. Avoid annual or monthly paid edge optimization.


On, my site’s TTFB scores a big red F. Does TTFB really matter?

Yes in a big way. You can’t get under 2 seconds load time if your TTFB is 1.5 to 2 seconds. TTFB is server speed overhead.

Mobile-first ranking is a different and undefined criterion. Its influence on your ranking is still a mysterious and long-term strategic plan by Google. Punitive shaming affects those not complying. Google experiments on the little guys first. They can’t afford to upset their biggest advertising client accounts with inferior rank changes. Google isn’t stupid – even when it appears they are.

What’s included in PagePipe’s ComboPack deal?

PagePipe ComboPack includes:

issue #1 – Mail.Me – Contact Form 7 plugin alternatives. MAIL.ME details

issue #2 – Fly.Me – Hummingbird plugin alternative. FLY.ME details

issue #3 – Search.Me – Yoast SEO plugin alternative. SEARCH.ME details

issue #4 – Police.Me – iThemes Security plugin alternatives. POLICE.ME details

issue #5 – Crush.Me – Image Compression and optimization suggestions. CRUSH.ME details

issue #6 – Block.Me – Akismet plugin alternatives.

issue #7 – Blast.Me – WP Rocket plugin alternative. BLAST.ME details

issue #8 – Sign.Me – OptinMonster plugin alternatives.

issue #9 – Greet.Me – HelloBar plugin substitutes

issue #10 – Theme.Me – Alternatives to premium themes. THEME.ME details

issue #11 – Select.Me – Gonzales speed plugin alternatives.

issue #12 – Healing WordPress Distress.

issue #13 – Theme.2 – Torture-tested Twenty-seventeen theme for speed. THEME.2 details

issue #14 – Single-page “sliders” testimonials. details

Plus Read.Me – explanation of plugin recommendations – This WORD file is included in the bundle.

And the “Toxic WordPress” 153-page ebook bonus.

When is a plugin too old to trust?

Today, PagePipe uses 70 plugins. About 30 of those 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.

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

Some think outdated plugins produce 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.


“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 their legal protection against liability and lawsuits. C.Y.A. If a plugin doesn’t work any more or presents 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.

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.

A plugin we use to track plugin age is “More Plugin Info” plugin

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.

How many plugins is too many?

PagePipe is hosted on cheap GoDaddy magnetic servers with no CDN. GoDaddy hosting is the second most hated provider in the world. The first is BlueHost. We’re out to prove even “bad” hosting can get fast page speed. (We host our store on Bluehost! Our blog on GoDaddy!) is living proof these recommendations for speed actually work.

PagePipe now use 70 plugins on the blog (GoDaddy) and 24 plugins on the secure store (BlueHost). Even with this many plugins, load time is under 2 seconds on cheap, shared hosting. It’s not plugin quantity, it’s the quality that makes a difference. Web designers can’t be arbitrary in loading and activating plugins. The result is slow pages. And all our plugins are freebies from the plugin directory.

It’s a myth using many plugins slows down your website. Being sloppy in judging plugin quality or necessity is the culprit. That’s within a web designer’s control. It calls for wisdom and speed testing. The best plugins add no page weight at all – weightlessness! (In reality, about 1 millisecond – or less – per plugin to the initial page load.)

Get PagePipe’s ComboPack now

Improving “The7” theme for mobile speed.

Summary: The7 theme JavaScript is the main speed obstacle. Second, is the type of image files used to create the animation (PNGs). Third, the animation plugins (slider) is slowing down the site. These elements cannot be improved or changed.

It’s a miracle this theme loads in under 4 seconds (sometimes 3) with all of these obstacles stacked against.

The client wrote:

To make a long story short, the job was to improve the look of the website and improve the speed to 2 seconds or less.  When he started the site was loading close to 3 seconds and as you can see it got worse to about 4 seconds. I believe it was $680.00 through a “developer” in India.

You got at least $1,500 worth of work for $680 dollars. Many people would be satisfied with your site. It’s fresh and modern. You’re disappointed because your expectation of speed improvement didn’t materialize as promised. In fact, it got 1-second worse (depending upon the test used).

The theme “The7” cost $59. The visual composer (drag-and-drop) is built-in for maximum customization. It’s “feature-rich” – meaning the theme authors from the Ukraine included the kitchen sink to appeal to everyone. Multipurpose usually means slow. The7 has been sold 30,000 times. It’s popular. Popular means “slow.” That is because people are attracted to themes that look pretty and have bells and whistles. But learning how to use The7 is probably as complex as a new computer operating system.

$1.7 million dollars worth of The7 theme have been sold to happy(?) customers. In the Ukraine, that’s a lot of money.

One single javascript file for this theme feature is 403k minimized. A heavy load. There is about 1M of javascript total associated with the theme (before being gzip compressed). This cannot be improved.

Images on your page are 265k for background images and 230k for other images. The PNGs can’t be altered or it destroys the aesthetics. They require transparency. They are the biggest part of the image weight. They cannot be improved with optimization either.

This is typical: 50 percent code weight and 50 percent image weight.

The goal is to balance aesthetics (branding) and speed (load time). Anytime, you increase one you decrease the other. Push and pull. More decoration slows down a site. Less speeds it up.

There are two types of aesthetic design: classic and expressive.

“The7” site leans toward expressive because of the colors, animation, and image usage. Image usage includes PNG transparency and large background images (layering effects). If too much expressive aesthetic is used, then the page gets visually noisy – and heavy. It distracts from the content (text). The goal is to get people to read – or click a response button.

Classic aesthetic is static, clean, and usually stark white. Sometimes referred to as minimalist. But it has it’s roots in Greek and Bauhaus design theories with white space usage, invisible grids, and golden-aspect ratios.

If a page is too classic, it gets boring and repetitive. If it is too expressive, it turns into distracting noise. A balance has to be found again for wisdom. How “good is good enough” is subjective and biased by opinion and perception.

For me, it’s amazing The7 theme loads in 4 seconds with all the expressive design elements. 4 seconds is a typical load time for a WordPress theme that doesn’t have many images on the page –and no animation. But the Internet average load time is about 8 seconds. Which has been proven practically intolerable for users. The saving grace is the pages aren’t completely blank for 8 seconds. If it is blank, the site will most definitely be abandoned.

At this point, to get better speed, you’d have to throw money at the theme problem – or redesign. You’d have to sacrifice some expressive aesthetics – especially the animation. All for a few seconds of speed.

I do like the look of the site so my goal would be to improve the speed as you suggest.  4 seconds is just too long.

The prospects of trimming 2 seconds aren’t good. The image assets are heavy and require JavaScript to be loaded. The PNGs can’t be improved. They are already 8-bit save-for-web and best case. But JPEGs may be improved. From our tests, we doubt the Smush plugin is doing any good. WordPress image compression was recently changed from 90 to 82. That is good enough.

There are other things that can’t be changed: Fontawesome is included. It loads even if it isn’t used. SliderRevolution plugin is loaded on every page – even if there isn’t a slider present. Dashicons are loaded for every page. Various Google fonts are loaded. While all of these things can be removed with code modifications, they are part of the design and the site wouldn’t look the same – it may even break.

After he screwed up my site

Your site isn’t screwed up. It’s just not perfect in every way. Perfection can have a high price. It’s definitely an above-average website. Very usable. We wouldn’t have wanted to build it. We wouldn’t change it. Those animation addons have a steep learning curve.

I followed this guide exactly but it only made a tiny improvement:

We’ve never had any success with W3 Total Cache plugin. So you aren’t the Lone Ranger. In general, if the site is already as optimized as it can get, caching just doesn’t make any difference. It doesn’t matter what caching plugin you use.

But recently Cloudflare and MaxCDN stopped working right so I disable both of them and they weren’t really working anyway.

Be sure to completely uninstall any plugins associated with those old CDNs.

Cloudflare CDN also failed in our speed testing. Same story as caching. Once a site is optimized, CDNs can’t help. Instead, they frequently slow down pages or cause “page not found” errors. It’s our opinion that CDN mainly helps with security and not speed. But if you have a grossly bloated website, CDN makes a difference. Or if you are selling to an international market (which you aren’t).

CDN and caching are band-aids for sloppy designers. Too lazy to optimize.

Current plugins:
Yoast SEO premium
WP Smush
Relevansii premium
Blubrry powerpress for my podcast
Contact Form 7
Forget about Shortcode Buttons
Ninja Popups
Slider revolution-homepage animation
W3 Total Cache
WP Baker Visual Composer (Site Owner’s comment: This is what the developer used to design the site rather than my requested CSS in the style.css document in the child theme which is blank).

There isn’t anything we can add that would significantly improve the speed. We do believe W3 Total Cache is minifying your CSS and JS files. It’s also Gzip compressing all files. So you are getting some benefit from it. Those features could be added with other plugins – but there wouldn’t be a speed increase to remove the W3 Total Cache plugin.

Contact Form 7 is a heavy plugin. But changing it to something lighter won’t be significant. We’d leave it alone.

Conclusion: We suggest your website is good-enough to communicate for marketing purposes. Review the main goal of your site. Redesign should be postponed as long as possible.


thumbnail of THEME-ME-10-v1.compressed
THEME.ME: What is the fastest free theme? There are 5,100 free themes in the WordPress theme directory. Of those, only 1,602 are responsive. All the rest are fixed-width junk. How did we sort the remaining 1,602 free responsive themes to find the fastest loading?


Defense strategy against Gutenberg breaking plugins and themes.

“If it ain’t broke, don’t fix it.” We couldn’t agree more. But we know, the WordPress world breaks on a recurring basis. That’s the price of an open-source community. Things become obsolete or incompatible.

Looking into our crystal ball we predict some near term WordPress trends and how they affect sites. Presently, here’s our status:

A common blog has 170 posts and 21 pages. And 32 active plugins (the WordPress average is 25).

There was technical bumpiness (total panic!?) during past core updates. Many major themes formerly used homepage widgets for customization. Upon WordPress new customizer addition, widgets moved without prediction. These errant themes became non-complaint and had to change their code to match new WordPress standards.

The new standards make things more bulletproof. But actually nuked everyone using old standards forcing emergency compliance. We recovered from that heart attack. WordPress makes changes now by adding a Customizer for CSS code normally stored in a child theme. Child themes are considered obsolete – but there is no documentation saying this is so.

We recommend using Simple CSS plugin to safely add customized code to your CSS. It won’t be overwritten by theme or core updates.

Presently, custom CSS is stored in the Theme Customizer > Additional CSS. This is fragile if the theme is changed. The way around this is to transfer the code to a nice plugin called “Simple CSS.” It acts in the same way, but is protected from theme changes. It also doesn’t cause an extra call like a child theme plugin. It’s faster loading. But CSS code isn’t always compatible in every way when themes are changed.

We don’t use child themes on new sites any more.

On the horizon looms the Gutenberg WordPress changes. We’ll get nuked again. But there are workarounds as stopgaps to get us into safe territory and through the learning curves. Gutenberg has already proved and predicted not being compliant with over 8,000 plugins in the WordPress plugin directory. Is there a published list? No.

Are paid plugins better for Gutenberg compatibility? No. 15 percent of those are predicted by Gutenberg developers to fail.

In the past, WordPress maintained backwards compatibility with legacy themes and plugins. This will not be the case with version 5.0 forward.

Gutenberg introduces unknown and unforeseen problems. They claim presently they will force the interface over the top of the traditional editor. It’s a god-like power play.

Don’t fear. Plugins are already created to defeat Gutenberg when automatic update occurs. Postponing Gutenberg hassles is a strategy improving the return on investment for existing sites. We’re talking increasing shelf-life or longevity. We can make changes when we’re ready instead of having them shoved down our throats.

The life span of a typical website is 3 years.

One can’t know for certain but some of your favorite plugins may fail. Authors may chose to repair them or we may have to find substitutes. There are 55,000 plugins in the repository so we’re not worried about fixing it. We’re only worried about “breakage events.” We assume it won’t be plugins with active ongoing version updates. But we don’t know. No one knows. Just because a plugin is stale or abandoned by it’s author doesn’t indicate potential failure.

“Gutenberg has three planned stages. The first, aimed for inclusion in WordPress 5.0, focuses on the post editing experience and the implementation of blocks. This initial phase focuses on a content-first approach. …

These foundational elements will pave the way for stages two and three, planned for the next year, to go beyond the post into page templates and ultimately, full site customization.” – Source

The goal of Gutenberg is to become a site builder (full site customization) and replace all page builder plugins. Fortunately, we didn’t go down the path of page-builder-plugin temptation. But millions of sites will ultimately be affected. Why is WordPress doing this? Do they want to destroy page builder plugins? No. They want to destroy WIX, Weebly, SquareSpace, and any other CMS competitor. Matt Mullenweg said authors and users of page builder plugins are collateral damage.

So here are our strategic recommendations:

1. Install a preemptive-strike plugin against Gutenberg. This is a precautionary safety measure and stopgap. It will add a years time to adapt your site.

There are presently 3 to 4 plugins to do this, but the one we recommend is:

Oddly, it includes Font Awesome. We don’t like that. But that’s life. Do a staging area test of the impact on your theme and site.

Another plugin alternative is:

2. Install the Simple CSS plugin and transfer the code in Additional CSS to it.

3. Twenty-nineteen theme deserves investigation for potential as a theme replacement for long term reliability and longevity. It is built for the Gutenberg editor. This theme is fast loading because the authors stripped it of features and external font requests.

The goal is future-proofing your site and improving the return on investment.

Now the bad news, we recommend a complete rebuild of your existing site. It can be planned for. We expect planning a switch in 2020 would be prudent. It’s gonna cost (again). Start budgeting now. Your site will then have a 3 to 6 year life (ROI) from that version. One never know exactly since the WordPress market is dynamic (chaotic).