GreenGeeks hosting migration yields impressive speed results.

Stefan Ivanovski reports performance improvement – and boasts 100 Google Compliance scores. Even though he knows scores are vanity metrics.

Stephan’s speed tuning experience.

I had great service with my host before, BigScoots. I was on their managed WP starter plan ($34.95 a month). It was very expensive, but customer service went above and beyond. I have no complaints about their service. It was too much for my budget.

On Webtools Pingdom, Washington DC servers, I was loading my front page ( in about 800ms. Before BigScoots, I was on SiteGround and the Time to First Byte (TTFB) was off the charts. Nothing reasonable was helping.

Once I moved to GreenGreeks*, I started loading the front page in about 400 to 600ms on the DC Server. I was able to shave off 200 to 400 ms.

Also, the Google Page scores improved a bit after moving to GreenGeeks. Before they were around 90 for mobile and now they are 99 — sometimes 100. I am on the GreenGeeks Pro Shared plan. I’m quite pleased with the speed and results.

So far, I pay less but get more.

I built my website following your tips outlined in your PagePipe ebooks. I took some turns on my own to simplify the website building experience. Like getting the GeneratePress Premium theme.

Anyways, I tested the website on Google PageSpeed Insights. I know it’s vanity, but I got better scores than {big smile}

100 perfect score for mobile test – PageSpeed Insights by Google
100 perfect score for desktop test – PageSpeed Insights by Google

I guess you are to blame for this achievement!

Thank you, Steve!

You are a WordPress Rockstar. You teach practice. Others preach platitudes.

Stefan Ivanovski

Founder & CEO of Lifestyle Democracy

Master of City Planning, University of Pennsylvania, 2015
International Relations and Spanish, Bucknell University, 2012

*Recommended in our free technical guide: “Slow Web Hosting Sucks

Thanks for sharing your speed tuning experience, Stephan.

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

“Thanks for the great tips as always. It’s a true pleasure to read your blog. I encounter people experienced with WordPress whose recommendations are platitudes (like to use SiteGround). I was on SiteGround and their TTFB was erratic as you point out. Service was good, but not a speed optimized site.”—author: Stefan Ivanovski

Obsessive speed.

You are a perfectionist. You like to solve hard puzzles. The harder the better. What puzzle could be harder to solve than resolving the differences in WordPress and mobile speed.

Perfectionism is a double-edge sword. It is good and bad obsession. It is unattainable.

It’s a search for multidimensional and multilayered achievement of unattainable ideals and unrealistic goals. Super complexity.

The pursuit of perfectionism can result in depression, stress, anxiety, and panic. It reflects low self-esteem. It leads to perpetual dissatisfaction. Striving for excellence can go too far and be unhealthy. It leads to attempts to avoid imperfection (humans). Isolation results. Hermetic loneliness. Maladaptive perfectionism is a prediction of neuroticism. It leads to being preoccupied with expecting perfection from others. Intolerance results.

Perfectionism protects us from feelings of low self-worth and possible rejection. I was a perfectionist most of my life. It was crippling. And some people came to despise me.

You do not have to be perfect to be worthy.

The defective aloofness and dishonesty you hate is found in pursuing perfectionism.

You will be seen as critical, rejecting, and ultimately find yourself internally defective. “The devil is inside you.” You will become highly sensitive to the potential for judgment and rejection in interpersonal encounters.

Perfectionism is not holistic. Perfectionistic self-presentation is a defensive tendency. Perfectionists become hypocritical and hypercritical of others, seeking the illusion of virtue to hide their own vices.

Six dimensions of perfectionism:

Concern over making mistakes
High personal standards (striving for excellence)
The perception of high parental expectations
The perception of high parental criticism
The doubting of the quality of one's actions, and
A preference for order and organization.

Perfectionism can be damaging. It can take the form of procrastination when used to postpone tasks. You can end up with low productivity chasing irrelevant details.

You feel excessive pressure to succeed. This leads to a fear of failure. Perfectionism is grandiose. It gets worse when perfectionist’s expectations are not met.

Perfectionism is irrational.

There are reasons we are perfectionists. For me, it was early childhood trauma and psychological abuse.

Core Web Vitals another unimpressive Google speed hoax.

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.

Finally — a real test of before-and-after CWV changes. And how it made no difference. We know clients who spent $20,000 to comply with this bogus criteria. (Why didn’t they give that money to us? They’d have achieved the same benefits. Zero ranking improvement.) What did $20,000 buy them? Nothing. Read the article linked below:

The effect of CWV on ranking. Nothing.

Offsite Link


“… 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

Web Core Metrics is a Google vanity project. Hand-waving.

Insubstantial vanity metrics meant to impress or convince.

I don’t really understand the purpose of the core metrics. A lot of sites are slow despite passing it. I think it’s better for me to stop stressing over Google updates and focus on creating good content that solves user intent.

Kenny Le

Here are the 3 main metrics Google uses for a Core Web Vitals score:

  1. Largest Contentful Paint (LCP): measures loading performance. To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
  2. First Input Delay (FID): measures interactivity. To provide a good user experience, pages should have a FID of less than 100 milliseconds.
  3. Cumulative Layout Shift (CLS): measures visual stability. To provide a good user experience, pages should maintain a CLS of less than 0.1.

So if your website loads in under 2 seconds on, will it pass these silly Core Web Vitals parameters: absolutely.
Nothing changed. Needless anxiety.

We quote Google: “We’ll begin using page experience as part of our ranking systems beginning in mid-June 2021. However, page experience won’t play its full role as part of those systems until the end of August.” – source


“Given this, sites generally should not expect drastic changes.” Google is referring to page ranking — not UX. Or maybe not even UX. Who knows?

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.

If Google Web Core Vitals are significant
– and something your site needs,
we won’t laugh at you or mock.
This is the place to get help for your anxiety

We’re convinced chasing Google Core Web Vitals is motivated by fear.
It’s desperation for page ranking or SEO.
You choose the measurement method you trust.

We don’t trust Google. But you know that.

Speed (page load time) is measured in milliseconds and page weight in kilobytes.

Speed is a user-experience fundamental.

Without good speed, you can’t have good UX.

Don’t get distracted from what really matters:
relevant readable content.

Good UX is human perception – not machine measurements or a score.

Chasing scores and green colors frequently make no difference in load time or page weight. No change in user experience.

Everyone hates a slow website.


Q: What is the page experience update and how important is it compared to other ranking signals?

A: The page experience update introduces a new signal that our search algorithms will use alongside hundreds of other signals to determine the best content to show in response to a query. Our systems will continue to prioritize pages with the best information overall, even if some aspects of page experience are subpar. A good page experience doesn’t override having great, relevant content.

This is similar to changes we’ve had in the past, such as our mobile-friendly (2015) update or our speed (2018) update. As with those signals, page experience will be more important in “tie-breaker” types of situations. If there are multiple pages of similar quality and content, those with better page experience might perform better than those without. – reference

Think about what Google just told you. The new Web Core Vitals signals get mixed with hundred of other signals. Insignificant difference.

Google keeps repeating, “relevant content is most important.” What is relevant content? It’s stuff people want. If you don’t have something people want, no amount of speed tweaking will ever make any difference.

“A good page experience doesn’t override having great, relevant content.”

Google also said, Web Core Vitals will have the same impact as  the “mobile-friendly” update and the “speed” update. Neither of those past changes made any significant difference in page ranking. But how would anyone know? It’s not provable. No data. Voodoo. Scare tactics. Weird panic in the streets over nothing.

We’re convinced chasing Google Core Web Vitals is motivated by fear.
It’s desperation for page ranking or SEO.
You choose the measurement method you trust.

Web Core Vitals are a tie-breaker ranking? A joke?

When are two pages ever identical in every way.

You are not alone if  you’re struggling to improve Core Web Vitals scores and coming up short.  Anecdotal evidence suggests that achieving high Core Web Vitals performance is difficult.  The reason is because publishers and SEO are trying to fix something that technically is not broken. … tech SEOs and the developer community is stuck having to “fix” what isn’t broken in order to make it abide to Google’s idea of what the web should look like.

The amazing $9 Kinsta-fast TTFB alternative

Who kills $1,200-Kinsta hosting?

Can you get the speed of a dedicated server on shared hosting?

You can test TTFB at or

Time To First Byte is your 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, most likely database-intensive plugins are hammering server resources. That slows down the server. These are usually the heaviest and most popular plugins. They are writing and reading data and creating databases. These are inferior plugins for:

  • SEO
  • security
  • broken-link checkers
  • backup
  • caching
  • dynamic site map generators
  • related posts

REFERENCE: common blacklisted plugins

REFERENCE: WIKI: time to first byte defined

We moved PagePipe blog.

Where? Host Huski. For the best-priced TTFB. Their server response time (or average TTFB) is 169.8 milliseconds. How good is that? It is comparable to the TTFB we’d get on annual Kinsta hosting. How much does Kinsta cost? $1,200 every year ($100 monthly fee). Ouch.

Across the United States and Canada, Kinsta’s average TTFB is 164.0 milliseconds. We love Kinsta’s average TTFB.

But not for $1,200 recurring cost.

We’d rather pay $9 per month for an amazing TTFB of 169.8 milliseconds. That is Host Huski’s average TTFB. Not per their spec, that is from our own real-world testing on our own PagePipe blog after migration. That’s eight different tests over 3 days. Each test was 10 consecutive samples measured with online tool. The final result: 169.8 milliseconds. Only 5.8 milliseconds slower than Kinsta. But for a lot less money. Sweet.

A millisecond (ms) is one one-thousandth of a second.
The speed of a human eye blink is 100 to 400 milliseconds.

Why are we smiling? We love finding money-and-speed-saving discoveries like Host Huski.

Good server response is less than the blink of an eye.

We started on cheap GoDaddy shared hosting long ago. Then moved to Rochen. They raised their prices and services slowed down. Badness. So, then PagePipe moved to GreenGeeks for better speed and free SSL.

And now we’re on a Host Huski server. Are we fickle or impulsive or what?

We prefer thinking we’re clever. Sheer speed mania? Maybe.

Are we a Host Huski affiliate?

Host Huski doesn’t permit affiliates. An affiliate makes passive income. What does that mean? It means we’d sit on our backside – and take a piece of the pie when you buy something. They don’t allow that.

Does Host Huski give PagePipe free hosting as endorsement compensation?

We moved to Host Huski as paying customers. Not freeloaders. So you’ll believe us when we say “Host Huski is Kinsta-fast.” They have other incredible benefits. The value is high. We’re discriminating speed fanatics. We’re getting out our wallets as proof. Cash talks. That’s called insistence value. We only want Host Huski and won’t compromise with any substitution or generic product.

Host Huski’s claims and value are beyond “Pinch me.”

This very page you’re reading now is on a Host Huski server.

We know the only way to convince you this is real and truthful is ponying up. We pay for Host Huski services – because we want to prove a point? We are not a lazy sellout with these guys. No kickbacks to us when you move to their fast 169.8-millisecond servers. Suggestion: Move soon for speed sake. Save the internet from WordPress abuse.

We endorse Host Huski above any other web hosts.

Is this support nepotism?

We aren’t related to anyone at Host Huski. One of life’s injustices: we don’t choose our relatives.

But Host Huski are our brothers and sisters of speed. They believe like we do that speed is kindness. It’s a fundamental user experience. You want people to see your beautiful website or read your precious relevant content? You better open the web door fast and courteously.

Do we have equity in Host Huski? Or even Kinsta?

We wish.

Are we insane?

Rabid insane. Everyone hates a slow website.

Why are we so crazy about Host Huski?

TTFB Purity.

The acronym for Time To First Byte is TTFB. It’s server overhead. Or server delay. Or server response time. Those are all ways to say the same thing. We specify TTFB in milliseconds.

What’s a good TTFB?

Do you want a number? Under 200 milliseconds. The faster the better. How bad is bad? Well, SiteGround fluctuates from 200 milliseconds to 1.7 seconds. We know this from testing websites on their servers. That is not good. That sucks. But, they advertise speed as a feature, don’t they? Yeah. They do. They don’t publish a TTFB specification though. 200 milliseconds now and again counts for them. Cherry-picking specs.

TTFB is the time waiting for the initial server response. Delay.

SearchEnginePeople and Google say, “TTFB needs to be less than 200 milliseconds.” How did they come up with that number? We don’t know. It’s estimated Google has 900,000 servers. Even Google gets that wonder speed on their super-duper servers. This number also differs by the type of content on your page. Static content may load in 100 milliseconds. Dynamic content (like ads) may load at a speed of 200 to 500 milliseconds. Remember the performance budget is 2000 milliseconds (2 seconds). 500 milliseconds is 25 percent of your budget. Ouch!

So who is most respected? Kinsta for TTFB. Because they have the gumption to publish their time-to-first-byte specification. Most hosts refuse to commit or publish those numbers. Because they suck.

Except for Host Huski who publishes their TTFB response. And they are only $9 per month. You get a whole year of hosting for what you’d pay Kinsta in one month. With 169.8 milliseconds TTFB, Host Huski is 5.8 milliseconds slower than Kinsta. Insignificant difference. Think about the cost differential.

Kinsta: $1200 annual hosting fee for 164 milliseconds average Time To First Byte (TTFB).
Measured TTFB – server response time is fast at Kinsta.

So. What’s a typical ordinary TTFB response time?

GoDaddy: Well – not so good – over a half-second.

Ordinary (inferior?) TTFB is something like 678 milliseconds on GoDaddy. That would be close. In the 500 to 700-millisecond range. Cost: $9 per month ($108 billed annually). Hey! Same price as Host Husky – but Host Huski bills monthly. That’s good for cash flow..

Can you buy Kinsta’s TTFB for a GoDaddy price?

Yes. How? We told you … Host Huski.

Host Huski: $9 monthly hosting fee for 168 milliseconds average Time To First Byte (TTFB).
Host Huski TTFB – server response time is faster than Kinsta.

Wait? We get $1,200 Kinsta-like TTFB for $108 annually from Host Huski? Hey! Isn’t that the same price as GoDaddy’s lousy 600+ millisecond TTFB?

Amazing. Do we need to say this again? Kinsta speed at a GoDaddy price.

Host Huski brags with justifiable cause.

1CLAIM: Host Huski provides secure WordPress hosting with extraordinary customer service.

“From the moment I talked to someone all the way through the setup process. It was super easy and they helped me understand what I did not. It was truly refreshing and lifted some anxiety off of my shoulders to have this kind of amazing customer support and help. So happy I found them … Amazing experience!”

— Nick Larson

2One reason customers choose Host Huski is when we say “unmetered bandwidth,” we mean it.

Host Huski: We don’t limit bandwidth. If you use too many resources, your host slaps you with a 503 error for all your visitors to see. That’s a predatory tactic we don’t do. We do what we can to preserve server longevity. But we’re gonna do it in a way that’s almost unnoticeable to you, or your users. If you are using too much CPU your site starts to slow down, but only while you’re using too much CPU. If you’re using too much CPU within a second, that’s very different than too much CPU within a month. So, that’s why this works so well. Not everybody is gonna have traffic up the wazoo all day, every day, all the time.

PagePipe: They’re gonna have spikes.

Host Huski: Yes. And when those spikes occur. Pretty much 99% of the time, nothing happens, because the server doesn’t flinch.

PagePipe: So, they never get kicked offline.

Host Huski: They don’t get kicked off. They don’t get a 503, or up-charged – nothing.

PagePipe: On GoDaddy, when you get close to limits, they email a notification scaring the clients to buy more. It’s terrorist upselling tactics.

Host Huski: Sales tactics like at GoDaddy are, “We’re gonna upsell you until you wanna kill us.” Forget that. Not our style.

Processors (CPU) have performance limits. If you’re consuming CPU, it means you’ve been hacked, or you got some kind of viral offer that no one can ignore. Either way, it needs some action or attention. We don’t kill anyone’s bandwidth. We give everyone a terabyte because we know no one’s gonna use that much headroom.

We monitor bandwidth usage, and if we see anyone who is astronomical, we check it. It could be a virus, or it could be they need a little more help.

PagePipe: Case by case?

Host Huski: Yeah. We’ve not seen anyone hit 50GB of data transfer. But, we’ve seen people hit 30GB though. That’s not too bad. But we’ve not seen anyone hit 50 ever. So, when they hit 100, that’s when we’re gonna be a little concerned..

So, back to resource allocation. CPU, IO, memory, and process. We don’t limit any of that except CPU, because CPU is what slows everything down. So, what we do is, we say “This percentage of CPU resources is available.” So, we start at 150%, which means 1.5 CPUs worth of processing power, and that’s their hard cap. As your server grows, as we add more CPUs, resource allocation increases over time. As we grow, you grow.

The more people we have on the server, the more CPUs, the more memory we need, and the more we provide. No cramming. We don’t use it as an opportunity to force upgrading to an expensive Virtual Private Server. We don’t offer VPS.

3CLAIM: Our prices/packaging remains consistent for new members and long-term customers alike.

PagePipe: Hey, the American government’s printing a lot of greenbacks as bailout money. The U.S. coronavirus bailout is trillions of dollars. That dilutes the money supply by over a third. And the meter is still running. A lot of egghead economists predict hyperinflation is looming on the horizon. Will Host Huski take that in the shorts? Or will they renege on fixed-price deals when profits suffer? If you stay true, this is the inflation-hedge deal of the century.

Host Huski: Any product with a price-lock is price-locked forever. Anything that doesn’t, isn’t locked. Maintenance plans and domains cannot be price-locked because those have variable overhead. That’s life.

PagePipe: What if you discontinue the service we’re using?

Host Huski: We support even the stuff that’s canceled. Anyone who still has it still gets it, and continues to use it, and have it at the same price. We’re not punishing anyone for the future. If they make a decision now, it’s not gonna bite them. They’re locked in.

4CLAIM: Our North America-based customer support team answers questions 24/7 in a language our web hosting customers can understand.

PagePipe: How is this exorbitant overhead magically covered? How do you keep costs low? Are you saying you don’t subcontract with India or Philippine web workers on Fiverr?

Host Huski – Our North American support team is available around the clock. We answer any questions you may have and create and escalate tickets to our experts. We provide the support you want when you need it. And it’s no secret. It’s not Fiverr. It’s magic.

5Host Huski has two WordPress plans that interest us. Both with unmetered resources:

Siberian: $9 monthly, 5 GB Disk, 3 Databases, 1x SSL, Pro-rata Billing Available

Malamute: $15 monthly, 10 GB Disk, 3 Databases, 3x SSL, Pro-rata Billing Available

Why the dog names? We’re curious. A theme or motif? We’re no Husky experts. But the word husky has good implications: strength, robust, sturdy. Corrupted English spelling (Huski) helps protect it as a unique trademark. OK. We accept it.

Husky: hard workers, reliable, durable, tougher.

Host Huski: Our expansions are available above the three-site limit for Malamute and Siberian. The site limit is from the MySQL database limit.

We don’t consider databases a resource, because they’re not consumable. They’re an asset that you use and fill.

Our limits apply to anything impacting storage space, such as gigs of storage and database count.

If you need more than one plan, the partner program comes into play. Because then we’re saying “thank you” for buying so many plans with us. Here is a tier-sliding discount on future purchases as you continue to grow with us.

So, the partner program starts at 15% off, and the only requirement is that you have more than one plan. There’s no membership fee. We’re saying, “Please, become a partner, and enjoy the savings” – and keep adding more hosting plans. The discount is an incentive to buy more. If you need more than 3 sites in your plan, then you should become a partner – and get discounts.

Goodies included with each package.


Solid State Diskspace – The expectation of SSD drives are becoming pretty common. $0.25 per extra gigabyte. “Unmetered resources” doesn’t mean unlimited disk space. There is a charge for extra space above the plan. But if your site uses even 4 gigabytes of space, you’ve got a weird site problem. PagePipe’s entire blog and media library fit in 330 megabytes of space.

LiteSpeed Server – We like this feature. Exclude eCommerce transaction pages from caching. We know LiteSpeed already covers WooCommerce by default. But not other eCommerce plugins – like Easy Digital Downloads. So it’ll break transactions for anything that’s not Woo-related if you aren’t aware. It’s fixable with exclusions. But PagePipe found out the hard way years ago – lost sales.

CloudLinux OS – You know we hate Cloudflare. But that isn’t what this is. It sounds like a CDN. But it’s not. Then it feels more like a virtual server than a shared hosting account.

Cloud Linux is what’s called a localized virtual environment. It compartmentalizes accounts as if they were their own VPS (Virtual Private Server). Virtualization technology splits one powerful server into many virtual servers. One piece of physical hardware then functions like several separate servers.

The benefit is no one hogs server resources at the expense of their neighbors. Everybody’s compartmentalized into set limitations. You’re still sharing with neighbors. If someone malicious is on a server, the only one affected is themselves. No one else is affected because they’re all isolated.

It’s secure as well. So, they cannot get outside of their folder. No matter how hard they try. They’re not allowed to. So, CloudLinux protects the server as a whole, too.

You get reliable performance without interruptions. No matter what else is going on with other sites on the server, your site will run at full capacity. No more outages and crashes to worry about.

Cpanel – We love Cpanel access.

C-panel servers only run with the Lightspeed paid version. Performance is better in the paid version as well. Host Huski pays for that. Not the customer. You can write to the HT Access file for speed tricks like selective plugin activation.

US Data Centers – OK. Good to know. A well-optimized site loads fast globally without CDN. Geographic server location isn’t a problem then. CDN isn’t required.


Host Huski has many ways to find malware and remove it quickly. The normal fee for Host Huski to do virus removal for you is $250 per site infected. Now, this is something you request. They don’t just do it without telling you. Keep in mind security needs attention. Host Huski may suspend services on infected accounts that are doing malicious things like spam mailing or phishing.

Server Firewall – OK. Nice. That eliminates a plugin.

IP Blocking, Whitelisting


One-Click WordPress Installer – Most popular hosts offer this. WordPress is easier with cPanel. One-click is all you need to get WordPress installed or cloned for staging your latest changes. Installs and staging are available from your cPanel dashboard.

WordPress Staging/Cloning – Many hosts don’t offer staging for testing. Not on low-cost hosting anyway. We love this feature.


Host Huski catches infections and alerts people they’re happening. We suspend PHP mail for hacked accounts sending spam at rates of 1000 an hour.

HuskiMail for $3 per month per inbox.

Questions About Host Huski

How am I billed for my hosting?

Host Huski charges your card every month. No manual payments are required.

Do you offer/register domains?

Yes! You can register your domain when you buy hosting (or separately). Host Huski offers .com for only $12 per year. Other domain pricing may vary. You can see our domain pricing when you search for one. We try very hard to keep our domain prices low. If you aren’t seeing the domain type you want, contact us!

Is Host Huski a reseller for someone else’s hosting?

Nope! We’re your host. We are not a hosting reseller. We provision a virtual dedicated server on the cloud. A data center is providing hardware but we provide everything else! That includes software, firewalls, security, etc.

Does Host Huski advertise low prices and increase costs later?

Nope. That’s the reason we started Hos

t Huski: to rescue people from shady tactics like this. We even guarantee our prices won’t go up for specifically marked products. Ever. Period. Guaranteed.

Do I get free SSL with my hosting plan?

Yes. Siberian and Malamute plans include lifetime constantly-renewed SSL, for no charge.

NOTE: This is a big deal when you consider what GoDaddy charges – $70 to $100 per year per domain. They will eventually offer it free. But for now, they’re making too much money to let go of it. They use scare tactics to sell it to saps. They called PagePipe and said, ‘You’re no longer compliant with Google recommendations. Your ranking will be damaged.” The only reason we need SSL is to comply with PayPal requirements so we can get paid.

Does Host Huski secure their servers so I won’t get hacked?

Host Huski works hard to keep everything safe. Being careless with WordPress updates or using easy passwords isn’t good. But we will *educate* you on how to keep things safe.

Do you perform free site migration?

Complicated Website migrations are time-consuming. It depends on the size of a website and how it links up with your new creation. You need an expert to handle it. We do a free migration with your hosting purchase.

What does Host Huski technical support cover?

We assist with technical issues related to DNS settings, server up-time issues, website transfers, and more. We will not be able to assist you with questions about WordPress or other more advanced topics.

Host Huski web hosting plans

  • Secure WordPress Hosting
  • Unmetered Bandwidth
  • Free SSL for life
  • Faster speed than a dedicated server.
  • One-click WordPress staging and installs
  • North American-based customer support agents available 24/7
  • Free migration.
  • 24/7 support

PagePipe is not an affiliate of Host Huski or Kinsta.

Google AMP fizzled 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.

Now all the sites have a choice. If you want higher rankings and more traffic from search engines, you need to optimize your site for a better, more performant, and faster user experience. Google AMP is no longer a requirement to create a fast-loading website.

the Top Stories –OFFSITE LINK

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

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

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.

We’ll tell you what’s big look at the size of those plugin downloads. That says complicated and bloated.

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?

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.

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.

When working on a distressed website floundering for better speed, we pull the AMP plugins and — voila! — instant speed. Isn’t AMP compliance supposed to make your site go faster? Not from our experience. AMP is on slow, fearful, novice sites.

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


A bash on AMP from various sources as being only beneficial to Google.

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


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.


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.


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.


PagePipe discusses fallacies and fantasies about low-cost shared hosting. Choosing a web host. Perils and pitfalls to avoid for speed.


PagePipe tells how to setup LiteSpeed Cache plugin.

Click to download free 16-page PDF ebook. No signup required.

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


Imitate Elementor with Gutenberg block editor – and be faster.

Can Gutenberg imitate Elementor?

We build some client websites with the Elementor page builder plugin. It’s fast enough with judicious use on fast host servers.

Elementor plugin file weighs 5.7 megabytes compressed. And 21.5 megabytes decompressed in version 3.1.0. For comparison, WordPress core weighs 15.8 megabytes compressed (and 16.5 megabytes decompressed).

Elementor is now almost 5 megabytes heavier code when decompressed than the WordPress CMS platform it runs on. Ironic. And it’s still growing.

Elementor version 0.1.0 – when it was first introduced – was 1.2 megabytes compressed file size. That decompressed to 3.4 megabytes. It is now 6X larger than when it began in 2016. That growth of package size indicates complexity and code bloat. It’s lost simplicity attempting to become all things to all people.

Elementor bugs and increasing bloat pressured us to check our reliance. Are we being foolish? The vulnerability caused us to give the Gutenberg block editor another try. Would it be faster loading?

We selected four relatively lightweight block plugins to increase the Gutenberg block editor’s basic functionality. This is so we could imitate Elementor’s basic desirable features. Gutenberg is not a full page builder – yet. But it obvious that’s WordPress’s ultimate goal.

Gutenberg, at present, needs extra plugins to add Elementor-like features.

The page layout features we most desire are:

Columns and Nested Columns
Building columns with the Classic Editor is a pain. Creating columns – and columns within columns – makes designing and building smooth.

Negative Margins
Sometimes, we need things to be closer together. Negative margins make this possible.

Set Responsive Margins and Paddings
Layouts don’t always look right on small screens. The ability to set specific margins and padding based on screen size (without) CSS code is helpful.

Show or Hide Element Based on Screen Size
Sometimes you want to hide an element if it doesn’t look right on a particular screen size.

Ability to create columns on mobile screen sizes
Because sometimes we want a column on a mobile screen.

We tested these plugins for usability and speed. What features do they offer, are they easy to use, and how much does each slow down the test website?

This isn’t an exhaustive point-by-point comparison. We needed a quick real-world solution for a client’s speed website. So our tests are quick and dirty. We built a sample mock-up page with each candidate block plugin. What follows are our findings:

Test Limitations – Here’s the basic setup for the client website:

KnownHost shared hosting chosen by the client.

WordPress Twenty Twenty default theme (our choice).

34 active plugins – plus 8 inactive plugins used for maintenance events. The average number of plugins on a WordPress site is 25. It’s quality – not quantity – that makes a difference for speed. We chose only free plugins from the WordPress directory.

BEFORE: GT Metrix speed test results for test site. 1.1 second load time baseline.

The site’s baseline speed, before adding block plugins, is lean and fast. We optimized the images. There are no speed-enhancing plugins.

Four Free Plugin Candidates

Genesis Blocks Review

AFTER: GT Metrix speed test results for test site. Still a 1.1 second load time after adding Genesis Blocks plugin.

Speed Test Results
The speed stayed the same – 1.1 second load time. Genesis Blocks added 16kb and 3 requests to the page. No complaints there for speed.

Genesis Block has limited pre-built sections or layouts. This is not a big deal for us. It does offer containers, an important feature for building nested columns. But you can’t specify negative margins, which was a deal-breaker.

No negative margins meant there was no future for us and this Genesis Blocks plugin.

We don’t recommend Genesis Blocks.

CoBlocks Review

AFTER: GT Metrix speed test results for test site. Now a 1.2 second load time after adding CoBlocks plugin. We can live with a 100 millisecond gain at this speed.

Speed Test Results
CoBlocks added 100 milliseconds, 21 kilobytes, and 2 requests to the page. No complaints there for speed.

  • CoBlocks has a pretty good feature set considering it’s the lightest weight of the 4 plugins.
  • It’s not as intuitive to set up containers as Generate Blocks or Stackable plugins.
  • The individual blocks are not as good as Stackable plugin.
  • It does have a pricing table block, which is nice, but not enough to make this our choice.

We don’t recommend CoBlocks plugin.

Generate Blocks Review

AFTER: GT Metrix speed test results for test site. Now a 1.2 second load time after adding Generate Block plugin. We can live with a 100 millisecond gain at this speed.

Speed Test Results
Generate Blocks added 100 milliseconds, 25 kilobytes, and 2 requests to the page. No complaints there.

  • This is the minimalist choice. It only includes basic elements such as container, grid, heading, and button.
  • No pre-built sections. (Not a big deal for us).
  • Can set exact width of the container. Important.
  • Can set exact width of grid columns. Important.
  • Can use specific margins and padding for desktop, tablet, and mobile screen sizes.

Some options with the “Container” block feature.

  • Spacing options include minimum height, margins, and padding.
  • Can set negative margins. Very nice.
  • Can change typography based on tablet or mobile.
  • Can build columns on a mobile device. Very nice.
  • Can’t hide elements based on screen size. (This would be nice).

Spacing options within the “Container” block.

Generate Blocks gets a lot right. Don’t let the few numbers of 4 blocks deter you. You can get a lot done with these. And the settings contained within each block are well-rounded and comprehensive.

We use Generate Blocks to build client sites, and we recommend it.

Stackable Review

Speed Test Results
Stackable added 27kb and 2 requests to the page. No complaints there.

AFTER: GT Metrix speed test results for test site. A 1.1 second load time after adding Stackable plugin. Same speed as the baseline.

  • Has everything that Generate Blocks offers and more.
  • Lots of advanced settings. Most like a page-builder experience.
  • Padding, margins, min and max widths, etc.

A look at the settings in the “Header” block of Stackable plugin.

  • Responsive options including hiding elements based on screen size. Very nice.
  • Can’t build columns on mobile screens. (Generate Blocks can).
  • Has global color and typography settings. (Very nice).

Decent pre-built design library. 83 in the free version.

We use Stackable blocks to build client sites, and we recommend it.

Which plugin did we use for this speed site project?

These plugins are all fast. So it came down to which had the features we needed and which we enjoyed using. Generate Blocks and Stackable fit the bill.

Stackable was a contender. But Generate Blocks had one indispensable feature: creating columns on mobile screen sizes.

Can Gutenburg replace Elementor page builder?

Yes. And no.

Gutenberg has come a long way since its introduction in June 2017. Here are thoughts based on a few general categories:

Elementor is easier to use. Creating complex layouts with Gutenberg still feels clunky, though it’s manageable. Most, unfortunately, what you see on the back end of a Gutenberg page does not match the front end. So there is a lot of fiddling to get the page to look right.

Out of the box, Elementor has more features than Gutenberg. But Gutenberg add-ons are plentiful. You can match the feature-set.

Elementor Pro is a page builder. It’s hard to compare it to Gutenberg. However, themes such as Astra are offering visual header and footer editors that help Gutenburg compete with Elementor Pro.

Speed is where Gutenberg shines. It’s faster than Elementor free version and much faster than Elementor Pro.

What about bugs and future-proofing your site? It’s important to think about your website 3 to 5 years in the future. Elementor gets fatter and buggier with time. Will it continue in that direction?

Gutenberg is still buggy but improving. It’s part of WordPress core. It isn’t going away anytime soon.

What are the benefits of using Gutenberg today – even though it’s still in development?

We’ve used the classic editor for a long time. We’ve been resistant to adopting Gutenberg. We don’t change because someone says it’s the future. Or because it’s mandated by WordPress default. Or that it’s trendy. We disable Gutenberg on sites often.

Are we Luddites? We don’t like learning curves and troubleshooting. Does that mean being a late adopter is bad? No. It reduces risk. Entrepreneurs believe in risk reduction. They don’t like big risks – even though that is the business myth. They also want to get a decent return on investment of website expenditures. They don’t have enough resources to mess around.  Learning a new operating system is wasteful. They’d rather stick with something they’ve already mastered.

WordPress has abandoned the classic editor in new themes and updates of old themes. It’s not easy editing blog posts anymore. The editor control bar now scrolls off the screen. It’s a pain to add a link or italicize.

Is this a deliberate crippling of the classic editor – or a casualty of oversight by WordPress? We don’t know. But the annoying flaw gives us an impetus to change. As we’ve experimented, we’ve discovered a more pleasant writing and editing experience. They improved the user experience. At first, Gutenberg was horrible. After 4 years, it’s improved. It’s usable and even better in many respects. Gutenberg continues to improve.

About The Author

Matt Stern is a web designer and sometimes writer based in Southern Oregon. He designs and builds landing pages and websites that convert visitors into subscribers and customers.

Learn more at


Adding Columns and Moving Blocks in Gutenberg Editor

2:32 minutes – Matt Stern


Adjusting Blocks Widths in Gutenberg Editor

3:56 minutes – Matt Stern


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 Brian’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?

8 futile web myths about speed.

Certain falsehoods about web speed are repeated over and over on blogs that should know better. They drive us crazy. Can we get rid of these mythical speed ideas? We doubt it. But we’ll feel better if we inform you of propaganda that’s unwittingly passed along.

Here’s our list of chronic speed misinformation:

1Speed affects your search engine optimization (SEO).

While Google pays lip service to speed, it clearly isn’t a major concern. They send out mixed messages about speed’s importance. The most notorious third-party widgets slowing down websites – other than Facebook social links – are Google’s Cloud-based API services, Google Fonts, Google Maps, Google Analytics, Google Adwords, etc. Most modern WordPress themes incorporate these things. Research studies show that speed affects Google page rank by less than 1 percent. Insignificant. What improves SEO most? Plain and simple: relevant content. Relevant to who? To people trying to solve problems!


2Fast websites enjoy high conversion rates and a healthier bottom line.

Really? Then, where’s the long line for speed optimization services? Where’s the market pain?
There is evidence speed makes a significant difference in profitability for very-large, big-name sites – like Amazon, Ebay, Mozilla, and Apple.
For most low-traffic sites, there is no measurable monetary gain. What does change is visitor perception of how credible website content might be. This is first impression or UX. Speed is a subconscious indicator of someone valuing content enough to deliver it quickly and efficiently. It’s the opposite of apathy and bloat. It’s web hospitality, etiquette, and caring.

3Running a successful website starts with choosing a good host. Hosting makes a difference in SEO.

Baloney! Wrong again.
Hosting may add conveniences and security for site management. But speed is dependent upon optimizing and limiting the number of website components. Hosting can make a difference in Time-to-First-Byte (TTFB). This is the parameter Google uses in it’s search algorithm. But we repeat, TTFB only influences SEO by less than 1 percent. Is special, costlier hosting really benefiting SEO? No. Remember, content relevance is more important – always! The average web page now weighs 2.3 to 3.0 megabytes. It doesn’t matter how long it actually loads for SEO. It does make a difference in how frustrated a site user feels. The upper tolerance seems to be 2 seconds. Even though the average page load is now 8 seconds. Horrible! Those load times have nothing to do with hosting and everything to do with extravagant and out-of-control developers and designers.

4Caching WordPress is so effective that it can result in a 10x speed gain over a non-cached website.

The reason web builders see improvement from caching plugins isn’t from caching features. It’s from the activation of Gzip compression, far-futures expiration, and minifying Javascript and CSS files. Those extra features have little to do with caching. In fact, most modern hosting has already activated Gzip server-side. On a well-optimized website, we’ve rarely see benefits from caching plugins – such as the oft-recommended, free W3 Total Cache plugin. Or even WP Super Cache. Both very popular plugins with millions of installs. They are the emperor’s new clothes. Only a small percentage of your site traffic benefits from caching. This is usually around 20 percent returning visitors.

5Too many plugins slow down your WordPress website.

Bogus information!
How many plugins are too many? We’ve installed over 70 active plugins on websites that load in under 2 seconds on shared hosting. Not all plugins are created equal. Sure some will slow down your website – especially if they call offsite using third-party Javascript. Facebook real-time social links are the worst offender for slowing down a website. Why include this unprofitable baggage instead of using a static image link or CSS text link? Craziness.

6The best tool to measure web speed is Google PageSpeed Insights.

No! NO!
For WordPress, if you use this Google tool, you’ll be very frustrated. The “defer Javascript error” message will light up as a fail every time. WordPress relies heavily on Javascript – especially the jQuery library. Google doesn’t even use these test-scoring criteria in their own page ranking algorithm. If they don’t care, why should you? A better test is (also owned on-the-down-low by Google). This comprehensive test is open-source, free and tells a more in-depth story. Our second favorite speed test tool is


7Google says I need to have a performance goal of 400 millisecond page load times.

Google is full of idealistic waste matter.
The average load time today is 8 seconds. That is bad but there are many slower sites. Most website-optimization professionals agree a 2-second load for WordPress is doable with good optimization discipline. That is our goal. The saving grace is user-perceived load time – not actual load time.

8Content Delivery Networks (CDN) always speed up load times.

Maybe for international locations, but we’ve never seen improvements inside the USA. We have seen CDNs (like CloudFlare) actually slow down load times and cause missing content errors. Again, a well-optimized site rarely benefits from CDN. Caching and CDN are band-aids for sloppy web design.

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

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

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.

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

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

Load-time curse from Elementor page builder temptation.

Because you like Elementor page builder, 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 page builder massive pages. It’s like a compulsive addiction. More is better is the assumption.

Elementor is the fastest and best of breed page builder. But we don’t endorse page builders!

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 page builder, use Elementor. But realize it may not future-proof your site. We have a suspicion WordPress will “break” all page builders soon. On purpose? No. But they want to own that page builder space.

We don’t use page builders on principle. Mobile sites don’t usually need them with only one column of content. We find page builders 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 page builders.

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 page builder 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 page builders 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 page builder, 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 page builder 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 page builder features.

Progressive Web Apps (PWA) won’t save mobile WordPress speed.

Are Progressive Web Apps a remarkable phenomenon? Or another fad touted as rescuing mobile experiences?

Should you convert to Progressive Web Apps? Not today. And maybe never.

Progressive Web Apps salvage loser applications. These are the ones buried in oblivion on Apple store and Google Android store. Market noise grew loud – an ocean of app offerings. No one gets discovered. Lost in the wash. Thus the “brilliant” idea of converting apps into mobile websites hatched. A website with regular-old organic SEO may give a better chance of attention and adoption.

Android store contains 2.1 million apps. Apple’s App Store is the second-largest app store with 1.8 million available apps. – Source

Typical free-download iPhone apps are:
  • Bitmoji.
  • Snapchat.
  • YouTube.
  • Facebook Messenger.
  • Google Maps.
  • Netflix.
  • Spotify.
  • Uber.

Apps are heavy. They convert to heavy slow websites. There’s no advantage for users – only SELLERS. PWAs consume about 50MB of available space. It consumes the user’s bandwidth. And Apple purges the PWA from cache after two weeks. That’s bad news for PWAs.

This alternative idea reminds us of the failed Google AMP propaganda. Another solution without a problem? Simple site source optimization is always a better strategy.

It’s touted PWA – Progressive Web Apps load instantly, respond to user clicks, and include an immersive UX. Wow! Really? Are they saying web pages don’t achieve these simple goals already?

PWAs are currently not supported by Safari on iOS. Fifty percent of mobile browsing is on Safari. Standalone PWAs use the weird process and That means it’s not 100% Safari compatible so it has its own bugs and issues. PWAs on iOS can’t make use of camera streams as there is a several-year-old bug.

Some people see PWAs as the dawn of a new era in mobile technology. We view it as another future bone pile. It’s creative but not an innovation. There’s no audience applause.

The most used and popular mobile apps are Facebook, Instagram, and email apps. The average page weight of native apps is 30 megabytes while the average size of a PWA is only 2 megabytes. And they think 2 megabytes is cool? Weird.

That reported PWA “optimization” is no miracle. This isn’t an improvement for the Internet! It’s average performance optimization. Ordinary, average page weight is 2.3 to 3 megabytes. Optimized web pages are much lighter – less than 1 megabyte – in the 350 to 750 kilobyte range. PWA weight is mediocre. Their main goal is converting loser and drowning apps to web pages. Trying to get submerged apps to float to the surface. The hope is salvaging investments lost in the sea of iOS and Android store apps.

Installations from app stores have a negative and cumbersome user experience. The PWA idea is increasing app installation using URL access. User experience is not the main motivation of PWA authors. The goal is the sunset of mobile apps. App authors replace them with PWAs to reduce costs and the hope of increasing usage. PWA is a marketing bandaid. A mere salvaging ploy.

There is no redeeming value in PWA for users.

Turns out there are already about 15 plugins for WordPress PWA conversion. Half of those only have less than 100 active installs. The largest has around 20,000 installs. Insignificant. We don’t have the time or interest to test the PWA plugins since we see them as bogus or faddish.

The idea is loading your site as an app into a mobile device – then it’s a permanent download into the device. You get a supposed instant load with a click. Faster than a website? Doubtful.

Who is willing to clog their smartphone memory that way? Would you download a bulky website on your mobile phone? The potential blowback on PWA ignorance hasn’t occurred yet. Aren’t people afraid of risking precious device resources? The horror stories will unfold.

Google scared site owners into thinking SEO is now dependent on being “mobile-first.” Google states responsivity (screen-size adaptation) is claimed the number one priority. And speed number two on the mobile-first criteria list. Do those SEO signals outweigh relevant content? Google wants to manipulate and keep us in the dark. As usual.

Our answer is relevant content is still more important than speed.

Google claims the big switch to mobile-first listings arrived in July 2018. But geeks employed by Google say mobile-first rankings “won’t count” for SEO. At least not until 70 percent of the Internet adopts the practice. Why? They can’t afford to tick off their big advertising income. Big account’s ranking-damage would be bad for Google business. So do as Google says, not as they do.

Google employees think they’ve achieved a 30-percent mobile-first adoption. Uh? That’s the same stat they brag about for SSL adoption. But other sources like BuiltWith say it’s only around 4 percent of the Internet. We suspect this propaganda is a plea for “get-on-the-bandwagon” bias.

Mobile-first ranking doesn’t matter as much as relevant content. It may never matter. Google dogma sometimes has no teeth in the real world.

And PWAs waste energy and resources. Period. We’ve got bigger fish to fry.

Best WordPress Performance Tuning

Site Tuning Services

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.

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

Rebuild your desperately slow site for mobile speed.

You’ve done everything to make your site fast. You don’t want to start over and ruin your investment. You could buy expensive CDN services like . But there’s no guarantee of success. You’ve maxed out and from here forwards there isn’t a good return on investment in tweaking speed.

At this point, the only reason to start over is if slow speeds affect your quantifiable sales. In other words, justify repairs or new construction for profits. Don’t tweak speed for mere speed’s sake. Do it only to increased profits.

The bad news: nothing will create further speed improvement without spending money.

WordPress is the CMS to work with. Not because *it’s best* but because there are so many solutions and people who can help. You can build a fast site with WordPress. But not usually straight out-of-the-box when loaded with images and widgets. It takes care and attention to details.

The speed problem usually isn’t WordPress. It’s the whims of the site owners. Or worse – committees!

We often recommend modifying WordPress default themes. They have longevity. They will have updates and support for years. Themes vendors can’t say that. There’s a shakeout in process among theme authors. That means mergers and acquisitions. It’s a volatile place. Businesses vanish overnight. WordPress won’t. Not soon anyway.

Simple WordPress-authored themes usually load in about 50 milliseconds. A twentieth of the time of premium themes. Even the ones who claim speed is their main feature don’t match that time. Premium themes authors can’t restrain themselves. They throw in the kitchen sink with gold-plated features.

We’ve seen a trend for theme authors to now offer two versions. One is the desktop, nice-looking version. The other is a stripped-down mobile version (usually removing Font Awesome and Google Fonts). The stripped down Premium version still isn’t as fast as free default themes for a foundation.

Even with a bare-bones theme, it still requires more removal (with plugins) to make it fast. These include removing icons and fonts and emojis. Baggage.

The more popular a plugin is – or if it’s a premium plugin – the slower it will load. It’s true in 99.9 percent of the cases. One popular plugin usually weighs more than the theme itself. Sometimes more than the theme and WordPress core combined – like Yoast SEO plugin.

You can duplicate the multi-features of paid plugins with free or open-source ones. Sometimes, you have to load several plugins to create all the needed features. But it’s still faster. A typical single-purpose (we call it *discreet*) plugin loads in under 1 millisecond. A discreet plugin usually has few or no settings – it’s plug and play. We can load 80 discreet plugins if we don’t use popular Yoast SEO free plugin. The load time would be the same or less. PagePipe has 70 active plugins with 6 on “standby” for maintenance. The homepage loads in under 1 second on GoDaddy hosting. We don’t use any SEO plugin.

But Yoast SEO has millions of active installs! That’s right. Poor fools.

Developers and site owners don’t understand plugins are often global loading. We call this “site drag.” Let’s say you install Contact Form 7 plugin’s shortcode on your contact page. You’d think, “Well, it only slows down that page.” That, unfortunately, isn’t true. Contact Form 7 slows every single post and page of your site by 42.8 milliseconds. That’s site drag.

Contact Form 7 has millions of active installs! Yes, popular. Let’s all follow The Herd?

Site drag is never revealed anywhere in plugin specs or files. You have to test. Contact Form 7 is the same as adding Google Fonts or a large header image to every page. But the plugin author doesn’t tell you that bad news. There are ways to selectively deactivate plugins on URLs. This is a good trick to learn. It requires using more free plugins. But they don’t add site drag.

We test the site drag of plugins and report it. We always focus on the 20 percent of plugins that cause 80 percent of the load. This is Pareto’s law or the 80/20 rule. The worst, of course, are page builders. Not all page builders are bad. Elementor can be fast. The problem with page builders isn’t the plugin itself. It’s the fact they encourage bloat. It’s too easy to add more features without design pain. The site then has organic growth instead of strategic growth. The pain comes after the fact when speed is finally measured.

Now everything we’ve told you for speed benefit can be undone by adding one third-party ad. Or a real-time social media “likes” counter. Ads and real-time counters are death to speed. You have no control over their connect time or weird delays. You can’t cache these assets. They don’t belong to you. They reside on other servers.

The more third-party assets you dump on your site – the worse it gets. They are unpredictable for delays. These include:

  • Google Analytics
  • Google Maps
  • HTTPS / SSL server handshaking
  • any offsite signup like MailChimp or iContact
  • adding Google reCaptcha to forms or logins
  • Google YouTube videos
  • podcast services
  • many popups like OptinMonster and ChatBox
  • any API
  • on and on

You have to figure out what you need for survival and dump the rest – or use some creative trickery. That’s value analysis. It’s an industrial discipline that applies to page speed optimization. It includes:

  • combination
  • simplification
  • elimination
  • standardization
  • substitution

The biggest thing affecting speed is deciding up front what you’re not placing on your site. Then disciplining your team to stick to the goals. A performance budget must be set in advance. Can you simplify?

Image optimization opportunities are small.

Sometimes there’s an opportunity in converting non-transparent PNG images to JPEG format. You can compress JPEGs at a quality between 70 and 82. 82Q is the WordPress default. It’s the same as a Photoshop compression of 50Q. That “grade” passes the criteria of “goodness.” It’s a good benchmark. This will reduce page weight. Page weight reduction isn’t always proportionate to speed improvement. We measure speed in milliseconds.

Convert non-transparent PNGs to JPEGs to the WordPress 82-quality setting default.

Converting non-transparent PNGs to JPEGs (lossy-quality setting of 82) reduces the page weight. This classic error of choosing the wrong image file format is novice. But it happens all the time. PNG to JPEG image optimization changed a 6.5M, 15-second page into a 2.6M, 8.5-second page. Is that good? Hardly! Not when your goal is 2 seconds.
This is a free plugin that needs cautious use or you can ruin many things. Our advice is: after using the plugin on the media library, disable it. That will prevent any slow down. This is the same thing to do for any plugin that’s used for maintenance. They don’t have to be chugging server resources all the time.

Of the page weight, often 88 percent is images. All sites are image intensive. The average is 55 percent of weight is images. So you’d think, “Let’s optimize images and get better results.” What if those are already optimized images using a plugin service like Imagify.

Optimizing them more with “Ultra” settings only ruins them by making them fuzzy. We’ve tested it. It was worth a shot. But it failed to produce good-enough quality. It dropped the page weight but ruined the images. Did Ultra make a speed difference? No. The needle wouldn’t move. Image weight becomes transparent and gets a boost from browser parallel loading.

One goal is identifying the few plugins that add 80 percent to the total plugin load time. These are plugins causing *site drag*. Remember: Site drag is global loading of assets whether used or not on a page or post. Not all plugins do this but it seems heavy and popular ones always do.

Usually the more popular the plugin the worse it is for site drag. Why? We can only guess. It’s a correlation that is real and holds up time after time. *Popular* means an easy selection and fast-choice for functionality. It doesn’t translate into speed.

A fast (normal) plugin loads in one millisecond or less and doesn’t cause site drag. A heavy plugin loads in 50 milliseconds. 50 times slower. Some are much worse. It’s not the number of plugins that slow down a site but the quality. Imagine 100 bad plugins!

Remember it’s not quantity – but quality.

Ignore speed test scores. Watch milliseconds of load time. Accepting average 8-millisecond speed is not a failure. Excellence (perfection?) sometimes has too high of price tag.

WordPress core loads in about 500 milliseconds. The paid Humanity theme averages 1.1 second load time. Yes. Over one second. All stripped-down free themes load in about 50 milliseconds. Humanity theme is 20 times slower than a theme built for speed. The Divi theme which is notorious for slow loading beats that with a 679 millisecond load time. So not so bad, but still 10 times heavier than a “speed theme.”

Webfonts are heavy. A fast site may have 50k of fonts or best case *zero* (web-safe fonts). But some sites range around 250k to 300k in webfonts. Disabling these make a difference in speed. On a lightweight 1M site, we’d have lost 25 percent of the weight by pulling the fonts. But on a site with a 4M page weight, other page assets overwhelmed the font gain. It won’t matter.

The same goes for 250k weight of Google Maps. On a 1M page, it would be significant to remove it. But not on a 4M to 6M page.

HTTPS / SSL adds 500 milliseconds of site drag in the Time To First Byte (TTFB). Another slowdown.

The average web page today weighs 2.3 to 3 megabytes. Average-pages load in 8 seconds on desktop. A site weighing 4.6 megabytes is double the average.

Will CDN help? Not a free CDN like Cloudflare anyway.

Speed excellence is beyond the reach of misfit sites. They’re constructed with heavy themes, slow page builders, and third-party APIs. It’s not one thing or even a few things. It’s everything. Too many things.

What drastic changes would make a difference in speed? Complete site rebuilds. Is it worth it? Nope. You made a big investment getting these sites to where they are today. You must have a return on investment before you can overhaul the sites. They aren’t broken.

It’d be a rebuild from the ground up. That means:

  • starting fresh with a host with a TTFB of 100 to 300 milliseconds
  • avoiding HTTPS/SSL if possible
  • selecting fast themes
  • using fewer images
  • using Google Maps tricks
  • not using Google Fonts
  • lazy loading YouTube videos
  • no CDN
  • no sliders
  • focusing on written content for SEO
  • no live counters showing social popularity

It would be Spartan but it would be fast.

That’s too big of a sacrifice. You don’t want to go there and we don’t blame you.

Our pragmatic recommendation is don’t add any more features and let the site make money. Only make big changes if you start losing money. Mediocre speed or even average is good enough if you’re making money. The most important metric is sales. It’s quality of traffic, not sheer volume, that translates into profits.

Nowadays, SEO is about 2 things:

  1. relevant content
  2. page titles that arouse curiosity

That’s it.

If you use WordPress, don’t worry about:

  • machine SEO
  • tweaking snippets
  • keyword usage

Imagine people aren’t looking for what you offer. They don’t care. No amount of keywords or manipulation will change anything. SEO is about motive. What are the users motive to visit your site?

Market positioning is a creative communication strategy. It serves as a shortcut to the buyers motive. They 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.

Essential or core UX is also simple. UX is about overcoming three critical things for quality first impression (aka credibility):

Speed being prime. Why? If you can’t get past this hurdle the user won’t hang around to even see your cool presentation or offer.

2Next attractive aesthetics. We have an emotional reaction to what we see and determine in an instant if a site is “good” or “bad.” We base “stay-or-go” decisions on a 50-millisecond visceral design perception.

3And last, readability and findability (like navigation and text size, etc). Websites are still about reading content (or skimming at the least). People are foraging for entertainment or problem-solving. Pictures are nice. But it’s words that still communicate to humans and are also machine readable.

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 do you use for measuring that?

“Page speed” is a phrase searched for 10-times more than “performance optimization.” And mobile speed is synonymous to page speed in world-wide interest. For mobile users, page speed is a competitive differentiating factor.

Why the pain today? Because mobile devices flood the earth. Massive adoption is changing how people work and play. In remote third-world countries, smartphones are the main computer technology and communications devices. Don’t ignore small screens if you want your business to make money in new global markets.

Origin optimization is cumulative. 500 milliseconds here and 1 second there all add up.

To be in the top 1 percent of fastest sites requires drastic changes and self-discipline.

PagePipe contains many speed ideas. If you’d like us to help you on future web construction, we’re willing and (usually) available. Contact us.

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.

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.

Basic principles to improve your site speed.

From experience, speed deal killers include Activecampaign, Facebook Ads, and Google Ads. You have no control over what’s served nor the delays caused by third-party remote servers. You can cherry-pick the slowest ones and cut them or find substitute ad sources.

There is a paid plugin in existence that will lazy load ads. It is very complicated and we don’t use it. It’s targeted at mobile audiences. The goal is to load the ad below the phantom fold on mobile. It seems esoteric and desperate to us. But it exists. It doesn’t reduce data through the pipe. Only delays it.

A page that opens in 7 seconds on Firefox desktop browser could be double on a mobile device – around 14 seconds worst case.
Speed example: A matrix of 12@ 300-pixel square JPEG images scale to 259-pixel squares. Weight before compression and resizing: 16.6k > after 8.3k. That is a JPEG resized and converted to a 16-color, 8-bit PNG. So 8.34k per image x 12 = 100k savings. Is that worth the work? Not for most site owners.
Images load in parallel. But for mobile users this optimization reduces data usage. And the clutter through the wireless “pipe” by 5 to 10 percent. Would we do that on our own site? You bet. We’ll take 100k reduction for mobile users.
An image optimization plugin has no human brain. It will not optimize by converting JPEG to PNG – or PNG to JPEG. Switching formats when helpful is a human judgement call. This may be insignificant. Only “testing by fixing” will prove performance results.
Loading the wrong dimensions for an image is inefficient. Resizing images on-the-fly causes browser delays as it does the math. How much? It’s theoretical. There is no way to measure except fix it. All browsers act and respond different.
How many mobile users do you have? About half? The site owners who are sweating over mobile speed generally are in the 70 percent and up range. Maybe you’re forward thinking. Planning for the future. Or the big question: Is this anxiety about speed a real problem for your company? Are you losing profits? Or only a sales variable you’d like to eliminate?
Elementor problems – if there are any – are often corrected. The biggest problem is we can’t do selective activation of Elementor functions. It will white screen the site. The big gain with Elementor is removing it – or the paid version at a minimum. It’s not our recommendation. It’s done but it costs time (money). Functions and features you’ve added to pages are sped up using value analysis. These are not Elementor’s fault. You added them.
Elementor isn’t the problem. It’s other third-party gadgetry.
Value analysis is a borrowed discipline from industrial manufacturing. We apply it to optimizing site origin. It includes: combination, simplification, elimination, standardization, and substitution.
For example:
  • Why are you using Merriweather Google Fonts instead of a mobile system font stack?

  • Why are you using Google reCaptcha API?

  • Why are you using Akismet antispam API?

  • How much profit does Facebook API generate? Does it just take people away?

  • Are you lazy loading video on the page?

  • etc. etc.

If you are serious about mobile speed inspect features for value.


We love to teach origin-optimization speed strategy.

Our goal usually is to make Elementor (or any page builder) obsolete. It costs much more as a “repair” than as a strategy before building. This would be a site rebuild and would cost too much.
Our contempt boils over when suppliers, sources, or authors make fishy claims of speed improvement. But then publish mumbo-jumbo weasels words as “proof.” That bugs me the most. Cherry-picking numbers from best results is not evidence. Or giving the biggest credit to some gadget that’s a clandestine affiliate link. An unbiased report? No way. There’s a sucker born every minute.
The performance goal is always 2 seconds or less. Halving a 12-second Elementor page now load in 6 seconds is nice – but it’s not good enough.
Convert to creative and unconventional methods of speeding up websites for mobile. That means a bit of homework. It usually means sacrificing some holy features or functions.
Are you willing to invest time reading a few articles and PDFs? If so, we have specific materials that teach principles to improve your site speed. We avoid fluff that doesn’t benefit speed. Cram course. No padding. Not comprehensive. Focused.
Speed is about compromise.


Speed up MailChimp for fastest-loading WordPress.

You have many, many choices when it comes to adding an email sign-up form to your WordPress website. There are all-in-one plugins like Convert Pro, Thrive Leads or Mailchimp for WordPress. Then some plugins connect to an external service such as Lead Pages or Optin Monster.

These options have their merits, but each one has a cost. Some cost money, and all slow down your site. This occurs in two ways:

  1. Plugin load time

  2. Server delays with your email service provider or ESP (Mailchimp, Infusionsoft, etc.)

MailChimp emails services slow down your website – unless you know a few speed tricks.

What if there was a way to add a landing page to your site without any extra costs or sacrifices in load time? You can, and I’ll show you how.

I’ll also share some simple changes we made to our call-to-action. These improvements increased the click-through rate and conversions.

Why you should use Mailchimp’s built-in landing page builder

WP Subscribe plugin adds 6.2 milliseconds. Easy Forms for MailChimp plugin adds 18.8 milliseconds. Yikes Easy Forms for MailChimp plugin adds 93.0 milliseconds.

Most email service providers allow creating a landing page within their platform. You then link to it from your own website. The beauty of this set-up is that you don’t need an extra plugin to create a form. Then there is less server delay when someone signs up because the form is already on your ESP’s server.

Mailchimp may not be the most adept or feature-rich ESP on the market. But it’s free for up to 2,000 subscribers, and it gets the job done. This tutorial only covers Mailchimp setup, but the strategy applies to other ESPs.

1. Log in to your account and create a new campaign.

Click the image above to see a larger version.

2. Select “Landing Page” as the campaign type.

Click the image above to see a larger version.

3. Give your landing page a name and assign a list to it.

Click the image above to see a larger version.

4. Select a template. You can always delete the content and start from scratch if preferred.

Click the image above to see a larger version.

Interface components allow connecting your site to specialty services. These are sometimes called third-party integrations or API (such as MailChimp, Facebook, Twitter, YouTube videos, etc.). We call them annoying – because they usually slow down page load time. Under ideal conditions, they can be fast. But because you make a request to a remote server, that server’s engagement is unpredictable. There can be long, random delays. Then we’re at their mercy. These delays are essentially “waiting in line” for service. It’s peak traffic dependent. —Steve Teare, PagePipe performance engineer

Landing page design tips

Keep your layout simple and focus on the benefits of your offer. What’s in it for your reader? If possible, highlight a problem or challenge that your reader has. Then describe how your offer solves the problem.

Add some social proof:

  • a review

  • a testimonial

  • a quote for the author’s credibility.

A side benefit to hosting your landing page offsite is there are no other page distractions. There’s no navigation, no footer, nothing to click except the back button or the “Sign-Up” button.

Here is our landing page with notes:

Mailchimp landing page with annotations
Click the image above to see a larger version.

Once you’ve completed your design, add a page title and a URL.

Click the image above to see a larger version.

Click the image above to see a larger version. Add some text to differentiate from any other landing pages you create.

Click “Publish” and your landing page is live. Copy the landing page URL for reference.

Click the image above to see a larger version.

How to get visitors onto your new landing page

Now that you have a spiffy new landing page, you need to entice visitors to it. A simple text link will do. But we prefer to create a strategic graphic image placed all across the website. In this case, that place is underneath each of over one hundred articles on blog posts. See the Speed Library main navigation link. Most visitors enter our site via the blog.

This attention-getting graphic should stand out from the rest of the site. State the offer and its benefits in concise and clear language.

Here is our first version (note: this graphic is also the front cover of the free PDF itself):

Mailchimp cover with annotations
Click the image above to see a larger version.

How we increased sign-ups by editorializing the graphic

The version above increased our monthly signups from eight to twenty. (Compared to a different lead magnet)

After the changes are shown below, signups spiked to around forty per month. They have since leveled out to about twenty new signups per month. It’s an impressive page conversion rate of thirty-five percent.

Speedup Mailchimp Editorial with Annotations
Click the image above to see a larger version.

Remember these questions to evaluate effectiveness:

  • What is the problem your offer solves?
  • How can you communicate your offer’s value with details?
  • How can you reduce friction and address your reader’s hesitations?

Why Mailchimp’s limitations are a good thing

Mailchimp’s landing-page software is rudimentary. It has no bells and whistles like a page builder or standalone plugin. It has the basics:

  • text editing
  • drag and drop capability
  • simple column formatting
  • and a bit more.

This can be a benefit if you remember a few things:

  1. Your offer itself and the words you use are the most important thing.
  2. Bells and whistles can distract you from focusing on #1.
  3. Bells and whistles often increase your time invested because they invite tinkering.

Remember, *limitations* focus us on what matters most and getting the job done.

So, next time you’re wondering how to add a landing page to your site, consider using Mailchimp’s native landing page builder. Your page will load quickly, and you will save time and money using an excellent, free tool.

Matt Stern

About the Author
Matt Stern is a web designer and sometimes writer based in Southern Oregon. He designs and builds landing pages that convert visitors into subscribers.

Learn more at


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.

Name FCP JS Time Weight Chat displayed
LiveAgent 1.0s 309ms 79KB 2.5s
Zoho Desk 1.0s 259ms 67KB 3.3s
GetSiteControl 1.0s 315ms 106KB 3.1s
MyLiveChat 1.0s 430ms 67KB 5.0s
Crisp 1.0s 311ms 155KB 5.4s
Comm100 1.0s 295ms 220KB 5.4s
Userlike 1.0s 404ms 146KB 5.3s
Formilla 1.0s 590ms 181KB 5.9s
Tidio 1.0s 540ms 208KB 5.3s
LiveChat 1.0s 328ms 385KB 5.7s
Smartsupp 1.0s 1000ms 164KB 4.4s
Intercom 1.0s 514ms 301KB 5.5s
Jivochat 1.0s 612ms 299KB 5.5s
Drift 1.0s 441ms 464KB 4.8s
PureChat 1.0s 620ms 264KB 7.4
HelpScout 1.0s 660ms 379KB 6.6 1.0s 645ms 749KB 3.5s
Kayako 1.0s 628ms 364KB 9.4s
Olark 1.0s 778ms 405KB 7.3s
Zendesk 1.0s 991ms 533KB 9.3s
FreshChat 2.3s 361ms 564KB 2.8s

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

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

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.

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.

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

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.


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 page builder. 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 page builder 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 page builder 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 page builder. It’s OK.

Pagebuilders are not the speed panacea you seek.

Will your page builder 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 page builder doesn’t make you a skilled web designer.

Using a page builder doesn’t guarantee design quality. No surprise. There’s a page builder 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 page builder (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 page builder 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 page builders 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 page builder 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 page builder (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?

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 page builder. 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).

Free speed plugins duplicate Swift Performance Lite plugin – or paid services.

“I’m trying to make my website as fast as possible. I want to learn the best method and technical know how. I already watched video on udemy. But they use W3 Total Cache plugin. So many technical settings – and difficult.” – Adzalan Yanggang

Surprise! We’ve watched their video, too. We don’t agree with their shady speed philosophy. It cost too much. READ WPFaster review

They recommend W3 Total Cache plugin. It’s not a good choice. Complicated.

We recommend Cache Enabler plugin (20k download file size). And three simple checkbox settings.

What about Swift Performance Plugin? It has so many cool features. It’s a multi-function speed plugin. It’s compressed download file weighs a massive 2.8M zipped  – and 7.4M decompressed.

Very heavy plugins usually consume database and RAM resources on the server host. With these specs, we’re not interested in Swift Performance plugin. We prefer using single-function discrete plugins weighing about 4k and loading in under 1 millisecond. With discrete plugins, we do selective plugin activation on a page and post basis. This form of conditional logic significantly improves fine tuning a site.


The main valued functions of Swift Performance plugin:

  • Page Cache
  • Cache Preloading
  • Gzip Compression < This is activated by default on host servers.
  • Browser Caching
  • Remove Query Strings
  • Lazyload
  • Minify CSS
  • Minify JS
  • Combine JS/CSS
  • Async Execute Combined JS
  • Defer JS
  • Database Optimizer
  • DNS Prefetch
  • Plugin Organizer
  • Appcache
  • AJAX Cache
  • Proxy 3rd Party JS
  • Inline Small Images
  • Google Analytics Bypass
  • Heartbeat Control

You can add these features with single-purpose plugins with zero settings (no Wizard needed). Some are only used during maintenance and could be deactivated. But many don’t make a difference in speed at all. Just scores.


The Swift Performance plugin backend has animated advertising! Ugh!

Swift Performance Lite adds 131 milliseconds of site drag to every page and post of a website. Equally, we can install 131 discrete plugin instead. That’s the equivalent of adding the database-intensive Yoast SEO plugin (free version). Paid Yoast is even worse – 240 milliseconds. For the 20 features listed above, it should be a mere 20 milliseconds maximum: 15 percent of Swift Performance sitedrag.

Swift Performance Lite adds 6.2 milliseconds per feature whether it’s used or not.

And last – but not least – Swift Performance Lite plugin nuked the front end of the test site. All we had were gibberish characters. Our guess is this damage was caused by either concatenation in the minification process – or some caching weirdness – or a plugin conflict. Anyway. Not a fun plugin to deal with. We uninstalled it.

So how about using the monthly paid speed service? They charge $9 per month.

You can do all this for free – with plugins.

PagePipe’s homepage normal load time is 1.8 seconds according to the Pegasaas test. With their service tweaks, it’s 1.6 seconds. There’s easily that much drift for shared-server TTFB (time to first byte). The Pegasaas service essentially makes no difference – or a theoretical 200-millisecond potential improvement. You can get that gain by simply disabling Google fonts with a setting-less discrete plugin.

On a well-optimized page, minification rarely improves speed – only scores change. And test score are meaningless. Caching and minification are speed band-aids compared to website origin optimization.

‘I got a 100% score on Pingdom, GTmetrix and Google PageSpeed.”

Big deal.

Scores don’t alter SEO page rank or indicate good speed. Concentrate on milliseconds of load time as a better benchmark. Test scores are esoteric tweaks that make no significant speed difference.

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 server 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:

WP Remove Query Strings From Static Resources 3.6k
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.

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:

  • jQuery not enqueued.
    jQuery is a heavy Javascript workaround or shortcut (or crutch). WordPress programmers use it all the time.
  • Font Awesome unused (or includes a lighter substitute or subset).
    We hate heavy Font Awesome workaround for the artistically crippled. Read more
  • Google fonts disabled. Uses a system-default font stack instead.
    We always disable Google Fonts for mobile speed.
  • Includes a top-of-page button – without activating jQuery.


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 page builder 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 page builders for mobile speed.

Sedated Servers

People love to argue about which hosting is the best in the world. All hosts are pretty lame at some time. They’re for-profit companies run by fallible humans.

We apologize in advance for speaking ill of a host you may care a lot about. Can you tolerate trash-talk about your special-preferred hosting company? If not, you’re gonna be resentful. It’s a loyalty and pride issue for some team-type people. Hosting is a commodity product. We don’t get emotional about web hosts. But at the same time, we ‘hate” slow web pages. That sounds pretty emotional.


Servers at a hosting facility.

SLOW web hosting SUCKS

Let’s be upfront about our topic. We’re discussing common ordinary cheap shared commodity hosting. Not expensive specialty hosting like VPNs. And huge cloud-based services charging by the minute – or by byte volume.

A frequent question we’re asked is,

“What host do you recommend for speed?”


People are often surprised at our response, “We don’t recommend hosting.” Of course, you need a web host to build a website. But we don’t recommend hosts? Why? They’re cyclical from mediocre to bad to worse. That’s been the history.

If site owners asked, “What host should I avoid?”

Many diseased hosts — they’d sell their grandmother for $100.

It’s much easier to answer. We could give a long list. There are so many hosting problems people don’t know about. But there are easy ways to find out how good-is-good-enough.

A speed evaluation we do is measuring Time To First Byte (TTFB). There are three ways to determine TTFB. Two are using online tests and another is by uploading an HTML file into your media library.


We’ve talked on PagePipe about why TTFB is important. But we’ll review it here.

Consider TTFB the server overhead. It’s a delay in milliseconds. It’s how long it takes for the server to respond to a request for web assets. Then the browser can begin to construct your WordPress page in the device viewport. A good TTFB is 100 to 300 milliseconds. Ordinary is around 500 milliseconds, and poor is 750 milliseconds. Dismal is 1 second. And anything after 1.5 seconds is horrific.

How bad does TTFB delay get?

Worst case we’ve seen TTFB as long as minutes. This slowdown is often caused by plugins hammering on the server database. Or a plugin and theme conflict confusing the server. So it isn’t always the server’s fault. Plugins with heavy zip downloads are the most notorious for causing TTFB delays. They’re complicated plugins with lots of code – and lots of repeated calls to the server. That is bad for speed.

Hosts with impeccable service and wonderful uptime become bandits about their speed benefits. They brag about the quality of their magnificent servers. Boasting about superior SSD (solid-state drives) instead of mechanical spinner magnetic drives. As if these specifications matter for site owners. We’ve never seen the type of drive technology make any difference. Yes. SSD drives are faster. But in the end with all the other hosting variables, it isn’t significant. It’s not a measurable difference. The gain gets lost in the noise.

Who benefits most from SSD drives is the host company. SSD drives are quiet, smaller, cooler, and reduce energy consumption. They are good at reducing the server-facility overhead in floor-space and energy bills. But that has nothing to do with actual speed – or website load time. That is specsmanship hosts boast about. But the boasting never proves anything. Like bragging that your car can go zero to 60 in 3 seconds – but you use it for shopping at Walmart or driving in school zones. A waste of machine.

Because a host claims its servers are fast doesn’t mean you get fast. They exaggerate and omit details. They show perfect samples.

There are simple tests to find out if they’re deceptive. Here’s how:

Get the URL of the hosting company homepage. Plug that into You will never get a faster TTFB on their servers than they present on their homepage. That is simple. Compare them. Take 6 consecutive tests in a row. Are you surprised to find your favorite host gets 200-millisecond TTFB — but only once per hour? The rest of the time it’s fluctuating around 1.7-seconds TTFB. That is terrible. What host would be that bad? Er. SiteGround. Yeah. They suck for speed and there are reasons. Popular hosts don’t guarantee good speed. Neither do expense hosts Like WP Engine, $100 per month: $1,150 per year. Ouch.

So what about places like BlueHost ($71.40 annual rent)? We wanted to prove a point once. Even on super-cheap hosting like BlueHost we could load an eCommerce store in under 2 seconds. What kind of TTFB did our store get on BlueHost? Typically there was a 1.7 second delay.

That meant we had to load our store pages in 300 milliseconds. We made it work but we had no room for error. Those tight tolerances made us uncomfortable. The load time would push out beyond 2 seconds to 2.2 to 2.5 seconds. We wanted to maintain our reputation as speed freaks. So we moved the store to Rochen later ($227.40 annual rent fee). We proved our point, but we didn’t want to stay there any longer than necessary.

So is BlueHost so bad? it all depends upon what your goals are. To run a simple blog, it’s fine. All hosts are bad and good at different times. What we like is hosts with rock-stable servers. We prefer a predictable 500-millisecond TTFB at GoDaddy. Rather than a fluctuating TTFB at SiteGround ($300 annual rent). When we work with speed clients, do we move them off SiteGround? Always. Do the clients whine about that? Yes. They do. They think SiteGround gives them good service. When we call their service desk, we get a correct answer half the time. The IRS 800 helpline gives wrong tax advice answers half the time, too. Is that good enough? Heck, no.

But what we despise most is hosting companies with speed claims that are flat out lies. They give no proof. They start throwing around technobabble jargon. It’s a smokescreen that they out spec the competition.

We do not appreciate these tactics. We aren’t ignorant.

When you find a good host, will they stay good forever? Not for long. For example, we used to love Pressidium managed WordPress hosting ($1,798.8 annual rent). But they had some policy changes and now TTFB speed – that used to be spectacular – isn’t so good. And they locked us away from writing code to the server htaccess file with plugins.

The htaccess file is important if you do selective activation of plugins. A cool speed trick. That ruins speed Karma for us. Most managed hosting tries to keep the client as far away from server access as possible. Why? They say “security issues.” We know the real reason. Services costs rise as they get more clientele and they can’t keep up with the ensuing chaos. So they start locking people out to reduce the service calls.

What about Kinsta ($2,400 annual rent)? Aren’t they good? Their mantra is “Built for Speed.” Yeah, except they give out bad advice for speed. They don’t speak of cheaper alternatives. They perpetuate myths to their advantage making their specsmanship appear dandy. Propaganda machines. We criticize their claims and advice more than we do their actual performance. We feel it’s deceptive and shallow.

We’ve written quite a bit about Kinsta policies and advice. So we won’t repeat the potential insinuations and insults here.




We want a host with integrity. It’s often fine until a hosting company changes ownership – or gets popular. That’s right. Popularity ruins hosts. For example, HostGator, we were checking why a New York seller of woman’s perfume had such a slow site. We used a tool called YouGetSignal. That online tool told us it could only show the first 1,000 domains. Our client was sharing the server with at least 1,000 more domains. That was the problem. The server was crammed to the gills with over 2,000 domains. What is normal? Well under 100 domains – and more like a dozen.


Mystified speed clients ask why their host server is so extraordinarily slow. We check with YouGetSignal, and bingo, there’s an adult porn site lurking unknown on their server. Kiss speed goodbye if that’s the case. You don’t need an advanced degree to use these online tools. It’s a simple copy-and-paste of your URL. The tool then identifies in RED the offending adult site. Sharing a server isn’t bad – if you have the right neighbors.

Generally, you get better speed by throwing money at the problem. Or renting more expensive servers. We see this on sites so corrupted we can’t update to a current version of WordPress. Instead of rebuilding the site and fixing it, the lazy owners buy more expensive hosting to solve it. The site is a hand-grenade with the pin pulled out. But they don’t want to fix it.


Where do site owners go to host a damaged site? Usually Kinsta. Got a lousy site. Go to Kinsta. It fixes speed with money. Shortsighted. That site is ticking like a time bomb.

30 seconds or even 1 minute load times, inevitably it’s a huge plugin fighting to get control of the server database. Usually a security plugin, a caching plugin, or metric-gathering plugin. These plugins usually weigh more than WordPress itself. But – hey – they are popular. Did anyone ever think to look at the size of the popular plugin? And wonder if that monstrosity is detrimental? Obviously not. It’s installed because everyone (The Herd) is installing it. It must be good. Right?

After pulling these fat plugins, the server miraculously calms down to a fast load time. What good is a lame plugin like that? Your bounce rate goes through the roof. These kinds of sites are the easiest tune-ups for us to fix and create the most dramatic results. We’re heroes. When you go from a 30-second load time to under 1 second, it impresses the client. They think you performed an exorcism when all you did was disconnect a power hog plugin.

WP ENGINE is not a preferred host for speed. Their server overhead (TTFB) is often about 800 milliseconds. A good TTFB (time to first byte) is 100 to 200 milliseconds. The average is 500 milliseconds. Poor is 750 milliseconds and bad is over 1 second. Hosts like SiteGround have erratic TTFB. It sometimes is 200 milliseconds – but most often is 1.7 seconds. So they claim the cherry-picked specification and ignore the real speed errors.

WP ENGINE’s homepage TTFB is 107 milliseconds tested with ByteCheck. Impressive. That would fool our usual rule of checking the host’s homepage as an indicator.

But 6 consecutive test of a client site on WP ENGINE shows:

ByteCheck 831 milliseconds, 927 milliseconds, 878 milliseconds, 924 milliseconds, 866 milliseconds, 846 milliseconds.

WP Engine is using a sweet server for their homepage hosting – but not yours. You aren’t sharing your server with anyone. It should be fast.

Their speed secret: they are using Fastly CDN and Cloudflare CDNs on their page but not yours. Fastly services charge based on traffic and bandwidth usage. And Cloudflare is $200 per month estimated.

In other words, they throw money at their homepage speed but not yours. A deception. Official Recommended Web Hosting

There are hundreds of thousands of web hosts on the internet. WordPress recommends only three hosts: Bluehost, DreamHost, and SiteGround. Those companies “donate” a part of your hosting fee back to WordPress. That’s called an affiliate link anywhere else. Not a donation.

Listing is completely arbitrary but includes: “contributions” to – as their first criteria.

How much do those 3 companies pay WordPress?

They won’t tell you. But you can’t get listed unless you “contribute.” The WordPress endorsement is worth millions of dollars to these three companies. Uh? That’s more blackmail or hostage payments.

The recommended webhosting page on is incredibly lucrative. Based on conversations I’ve had with employees of hosts listed, it can generate millions of dollars in revenue.”

Are they good services?

Why are the top-recommended hosts in a Google search the worst hosts in the eyes of real users? Why can’t you trust WordPress hosting recommendations?

Most hosting recommendations are unreliable for a simple reason: money. Like many other things, money corrupts hosting conversations. Recommending bad hosting leads to large amounts of money for the recommender. How does that happen? It’s the reality of the affiliate marketing model that dominates the hosting space.”


Here are some facts about recommended hosts:


We’ve mentioned BlueHost to prove we could make a store work even on poor-quality hosting. The TTFB for our site was 1.7 seconds. We loaded pages in under 300 milliseconds. Then things got worse and we moved.


Bluehost received a wooden spoon award for being the bottom feeder in a review of web hosts. Winning a wooden spoon doesn’t sound like a very awesome prize for a high-tech company.

BlueHost is owned by Endurance International Group who owns the 20 largest web hosts. They have venture-capital ownership in Automattic, the mothership of WordPress. EIG is owned by Clearlake Capital Group L.P. a diversified investment firm.


We’ve never used DreamHost ($203.40 annual rent for one domain). We never were tempted. But here’s the scoop on their homepage: TTFB: 195 milliseconds. Hey! That’s pretty good. Load time: 5.541 seconds. Hey! That’s pretty bad with such a good TTFB.

So why are they so slow? Maybe it’s because they’re sharing their server. That would be walking the talk. Nope? They share their server with no one. So why so slow?

Here’s why: remote third-party services located on distant servers.

Amazon CloudFront : Google : Amazon CloudFront : Google : Facebook : Google

HotJar, a user experience metric service, adds 500 milliseconds.


YouTube video: DreamHost isn’t lazy loading the video – a simple speed trick. This adds 500 milliseconds. Are they speed experts? Uh. No.


Drift is a $500 per month chat feature. Chat adds 1 second to load time. Do they really need chat on their homepage? Other places, sure. But why add that slow down to the homepage?


Font Awesome


You get the idea. These guys need to do their speed homework.


We’ve already mentioned SiteGround as having fluctuating TTFB. Every client we work with moves if they are on this host. Do we make them move? No. They choose to after they see the speed reports. Do we tell them where to host? No. They choose. We don’t care where they go as long as they move away from this host. Then we can achieve our speed goals. The clients always say, “But everyone says they are fast.” Who is everyone?

Everyone” is bloggers with affiliate links to SiteGround. Of course [forehead smack].

But … But … what about all the impartial reviews on internet blogs?

Check those referral links again in the “impartial” reviews. They’re affiliate links.

When an affiliate recommends a product to you and you buy it, the affiliate gets a payment. Someone paid for an opinion isn’t a great judge of truth.

$50 for 1 to 5 referrals per month, $75 for 6 to 10, $100 for 11 to 10, and $125 for 21+ sales. (This is the affiliate structure of SiteGround, one of our least favorite hosts.)

So, most WordPress hosting advice is dishonest. How do you find honest, real information?

You can’t. You have to test.

Do some of the simple tests we recommend in this ebook. Check their homepage and gimmicks by running a speed test on Check their TTFB on See who shares their server with them Look them up on Wikipedia and see who owns the host company.

Can we trust PagePipe?

We won’t answer that. Do testing for yourself. Do not trust any reviews or testimonials. Even ours.

Ask yourself, “How good is good enough?” Don’t waste money.

Here’s a full and clear disclaimer: There’s one affiliate link in our hosting report. It’s not on this page – or in our blog. We recommend a host and we collect an affiliate payment if you buy from them. Not if you click the link. Only if you decide to buy.

Who is that host?


You go there and buy and we get a kickback. The link is in our 1.5MB downloadable PDF. Do we deserve it? Or will you punish us for being blatant and honest? They don’t charge you. You pay the same price either way. It’s your way of saying “thank you” and giving us some applause. Do we need applause? Absolutely.

If you abhor GreenGeeks, feel free to write and tell us why. Email us.

After all these years of restraint, why endorse a hosting company now?

Ironically: The reason is integrity.

GreenGeeks doesn’t brag so much about speed. They could.

We moved from GoDaddy to them last year. We still use GoDaddy servers for testing and have an account with them. We moved because readers were asking if we’d like to have our SSL fixed. You know that little shield in the corner of your browser address field that promises you’re “secure.” They thought we missed that. They didn’t realize it was a deliberate choice for speed. SSL is used to slow sites by 500 milliseconds. But hosts have found ways to speed that extra burden up.

For example:

PagePipe blog now has a Time To First Byte of 167 milliseconds using ByteCheck test. GoDaddy was typically 500-milliseconds TTFB or worse. Our blog loaded in under two seconds. But GoDaddy charged $70 per year per domain for SSL/HTTPS certification. Other hosts as GreenGeeks offer that for free.

Our load time on PagePipe’s homepage is demonstrated in this test:

PagePipe homepage on GreenGeeks. TTFB: 231 milliseconds, load time: 1.116 seconds.

How much does it cost for shared hosting on GreekGeeks versus GoDaddy?

We chose the Pro plan at $4.95 per month for the first year and $15.95 per month after that. Their features include:

Unlimited Websites

Unlimited Web Space
Unmetered Data Transfer
Free SSL Certificate
Free Domain Name for 1st Year
Free Nightly Backup
Free CDN
Unlimited E-mail Accounts
WordPress Installer/Updates
Unlimited Databases
2x Performance
LSCache Included
300% Green Energy Match
30-Day Money-Back Guarantee

LSCache is LiteSpeed server caching. 

LiteSpeed helps performance. We’ve written a snarky article about our experience here:


The downside is disabling your eCommerce WooCommerce or Easy Digital Downloads cart. There are special settings to disallow those pages. But we lost sales messing with the setting figuring things out. We got over it. Today, we are fans of LiteSpeed.

So how much is GoDaddy hosting?

For unlimited websites (Deluxe plan), it’s $4.99 per month the first year, and $8.99 after.

So after pricing settles in the second year, the annual difference is GoDaddy $107.88 US dollars. And GreenGeeks, $191.40.

But if we added the cheapest SSL fee +$69.99 per year, GoDaddy would be $177.87. And if we were registering a new domain that would add $17.99. Or $195.86.

The difference: $5.54 less for GreenGeeks. Does price tip the scale in GreenGeeks favor? Not really. It’s sixes. About the same cost.

So what does tip the scale to GreenGeeks favor:

GoDaddy doesn’t offer LiteSpeed server caching. That makes a big difference in performance for even our origin optimized websites. These speed sites don’t benefit from caching plugins because they’re so dang fast loading. LiteSpeed Web Server (LSWS) is a high-performance Apache drop-in replacement. GoDaddy uses Apache servers. Is this another useless non-reality-based engineering specmanship? No. LiteSpeed makes a real difference. A web page that loads in 2-seconds now load in subseconds with LiteSpeed.

Big deal who cares? Faster than fast? So what?

Mobile users care. Some site owners get 80-percent mobile traffic, it’s a big deal.

LiteSpeed incorporates selectable speed features we desire. We add free discreet plugins to strip WordPress non-features and make things faster. You don’t need those extra plugins. It’s unnecessary. The functions now reside on the LiteSpeed server. Much faster and efficient.

Adding LiteSpeed plugin is required. It causes 53 milliseconds of global site drag. But the loss is worth it – because it accelerates everything else.

But there’s another reason to use GreenGeeks. We admire their idealistic integrity. Even if it’s only a marketing differentiation ploy, we like it.


    • GreenGeeks started in 2008. They committed to being the most Eco-friendly green web hosting company in the World.
    • GreenGeeks is recognized by the United States Environmental Protection Agency since 2009 as a Green Power Partner.
    • GreenGeeks work with the Bonneville Environmental Foundation (BEF) in Portland, Oregon. “BEF” is a Green-e Partner.
    • GreenGeeks tell BEF how many servers, personnel, etc. they have. They calculate the yearly energy consumption and carbon footprint. BEF purchases 3 times what GreenGeeks consumes. They put that energy back into the grid.
    • They match the energy they consume as well as payback for 2 other companies their size. This is their commitment to the environment since the beginning.
    • GreenGeeks has an A+ rating with the Better Business Bureau.

They walk the talk.

We admire their idealistic values. We are idealists, too. We call it honest responsibility.

Endorsing GreenGeeks is mutually beneficial for our credibility.

People binge-read our entire blog. We are the “consumer report” of speed.

GreenGeeks is our only affiliate link. We don’t publishing that link here in our blog. It’s not on our website. You have to download our report, “SLOW web hosting SUCKS” to get it.

We’ve written about GreenGeeks competitors. But those bandits get zero links – only GreenGeeks get a link. It would be normal on an affiliate link farm to have links to even the hosting losers. Desperation to snag extra income. We’re not sending you there.

We move our clientele over to your GreenGeek servers as long as the TTFB stays fast. Our reputation as speed experts depends upon us recommending good solutions.

GreenGeeks is “the best shared-hosting deal.” GreenGeeks is our only hosting recommendation. We’re finished dating hosts. We want a long-term relationship with these guys. We’re engaged and hope to marry.

That’s our story. Thanks for listening.

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.

MYTH: I’ve installed Yoast, so I’m all set

Sometimes, this statement makes me want to spit out my coffee and laugh; other times, it makes me sad that new bloggers can be so gullible and clueless.


Because this is an utterly ridiculous statement.

First, some newer bloggers mistakenly think that Yoast “gives them SEO.” And, of course, it doesn’t. In fact, there is no plugin that “gives you SEO.” There is no such thing. Rather the blog posts you write and the activities you do for a post will get you organic traffic. There is no silver bullet and no easy way around this.

Rather, Yoast attempts to measure your SEO. It uses some basic formulas that “check off” some of the boxes. Notice how I say “attempts.” This is because it’s very formulaic. And, also, it’s not very accurate nor predictive. In fact, often it gives you bad advice because it will direct you to do things that will lead to keyword stuffing (which is very bad for SEO) as well as poor writing, and that is bad for user experience. And, if it’s a bad user experience, it’s bad for SEO.

Many people mistakenly think that if they get a green light that their post is SEO optimized and will rank well. This simply isn’t true. Far from it. It’s all based on the keyword phrase that you enter. It does not tell you if that’s a highly searched term nor your chances of ranking for it. And, it’s simply garbage in/garbage out.

–Debbie Gartner

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

MYTH: I’ve installed Yoast, so I’m all set

Sometimes, this statement makes me want to spit out my coffee and laugh; other times, it makes me sad that new bloggers can be so gullible and clueless.


Because this is an utterly ridiculous statement.

First, some newer bloggers mistakenly think that Yoast “gives them SEO.” And, of course, it doesn’t. In fact, there is no plugin that “gives you SEO.” There is no such thing. Rather the blog posts you write and the activities you do for a post will get you organic traffic. There is no silver bullet and no easy way around this.

Rather, Yoast attempts to measure your SEO. It uses some basic formulas that “check off” some of the boxes. Notice how I say “attempts.” This is because it’s very formulaic. And, also, it’s not very accurate nor predictive. In fact, often it gives you bad advice because it will direct you to do things that will lead to keyword stuffing (which is very bad for SEO) as well as poor writing, and that is bad for user experience. And, if it’s a bad user experience, it’s bad for SEO.

Many people mistakenly think that if they get a green light that their post is SEO optimized and will rank well. This simply isn’t true. Far from it. It’s all based on the keyword phrase that you enter. It does not tell you if that’s a highly searched term nor your chances of ranking for it. And, it’s simply garbage in/garbage out.

–Debbie Gartner

Snippets are history!

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

MYTH: I’ve installed Yoast, so I’m all set

Sometimes, this statement makes me want to spit out my coffee and laugh; other times, it makes me sad that new bloggers can be so gullible and clueless.


Because this is an utterly ridiculous statement.

First, some newer bloggers mistakenly think that Yoast “gives them SEO.” And, of course, it doesn’t. In fact, there is no plugin that “gives you SEO.” There is no such thing. Rather the blog posts you write and the activities you do for a post will get you organic traffic. There is no silver bullet and no easy way around this.

Rather, Yoast attempts to measure your SEO. It uses some basic formulas that “check off” some of the boxes. Notice how I say “attempts.” This is because it’s very formulaic. And, also, it’s not very accurate nor predictive. In fact, often it gives you bad advice because it will direct you to do things that will lead to keyword stuffing (which is very bad for SEO) as well as poor writing, and that is bad for user experience. And, if it’s a bad user experience, it’s bad for SEO.

Many people mistakenly think that if they get a green light that their post is SEO optimized and will rank well. This simply isn’t true. Far from it. It’s all based on the keyword phrase that you enter. It does not tell you if that’s a highly searched term nor your chances of ranking for it. And, it’s simply garbage in/garbage out.

–Debbie Gartner

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.

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

You’ll weep when you read Google’s 200 Ranking Factors: The Complete List. 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.

MYTH: I’ve installed Yoast, so I’m all set

Sometimes, this statement makes me want to spit out my coffee and laugh; other times, it makes me sad that new bloggers can be so gullible and clueless.


Because this is an utterly ridiculous statement.

First, some newer bloggers mistakenly think that Yoast “gives them SEO.” And, of course, it doesn’t. In fact, there is no plugin that “gives you SEO.” There is no such thing. Rather the blog posts you write and the activities you do for a post will get you organic traffic. There is no silver bullet and no easy way around this.

Rather, Yoast attempts to measure your SEO. It uses some basic formulas that “check off” some of the boxes. Notice how I say “attempts.” This is because it’s very formulaic. And, also, it’s not very accurate nor predictive. In fact, often it gives you bad advice because it will direct you to do things that will lead to keyword stuffing (which is very bad for SEO) as well as poor writing, and that is bad for user experience. And, if it’s a bad user experience, it’s bad for SEO.

Many people mistakenly think that if they get a green light that their post is SEO optimized and will rank well. This simply isn’t true. Far from it. It’s all based on the keyword phrase that you enter. It does not tell you if that’s a highly searched term nor your chances of ranking for it. And, it’s simply garbage in/garbage out.

–Debbie Gartner

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

Load Time: 70 milliseconds

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

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.

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 use 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:

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!

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 affect the 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





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

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.

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!

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

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.

Faster themes dump Google Fonts.

We *wish* browsers cached special web fonts. This would make fonts transparent and immeasurable in tests. One hopes jQuery is already in the cache, too. There are plugin workarounds for this. But they still aren’t as fast as no special font usage.

But the better conservative assumption is these assets aren’t ready. Webfonts never enhance performance. At best, they’re benign.

Why aren’t Google Fonts there in the cache? They are. But Google forces a 24-hour cache refresh of fonts – and reloads. Why? Duh? To gather data on usage. Is that spying? Maybe. The font files don’t change every 24 hours. Ridiculous.

We strip fonts unless a site is achieving under target speed goals. Then they’re not deleterious. But on principle, we disable them. Site users are oblivious to the font differences. Nondiscrimination.

A telling recent trend is new themes vying for mobile speed. Themes like GeneratePress, and the Twenty-wenty-one default. Out of the box, they load a mobile font stack 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.

Does it make prettier sites? No. Pretty on mobile is a moot point. Single-column, 350-pixel wide images or resized images are what’s served up. All that matters is legibility and readability. Color choices create mood.

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 a mobile user experience? More like roulette.

Onscreen fonts once again are back to the stone ages. Even though there are a few more mobile system fonts choices to add.

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 removed jQuery before but were seen as esoteric or fanatic – and not well received. Now it’s a mainstream trend. The Herd wants faster font loads. They think speed might save their site. Speed never compensates for poor content.

Discarding font baggage and jQuery are nuances for speed. They make for fast themes. But you can destroy that in an instant with a few popular plugins. Then the gain is minuscule by comparison. Dwarfed by thoughtless plugin abuse.

Websites are pretty generic on desktop and mobile. They’re mere containers serving content on little screens. And that is what matters most: relevant content. Fussing about choosing Google Fonts is wasteful.

Today’s cutting-edge developers desire mobile speed more. Theme authors retrofitted changes in the “font” loading. The demand was high enough and offered the chance to sweeten the deal.

Google Font usage is now seen as unfriendly to speed and UX.

You don’t have to install a plugin to remove Google Fonts on these modern 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. They then are more average than special.

Just say, “No!” to Google Fonts.

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.

MYTH: I’ve installed Yoast, so I’m all set

Sometimes, this statement makes me want to spit out my coffee and laugh; other times, it makes me sad that new bloggers can be so gullible and clueless.


Because this is an utterly ridiculous statement.

First, some newer bloggers mistakenly think that Yoast “gives them SEO.” And, of course, it doesn’t. In fact, there is no plugin that “gives you SEO.” There is no such thing. Rather the blog posts you write and the activities you do for a post will get you organic traffic. There is no silver bullet and no easy way around this.

Rather, Yoast attempts to measure your SEO. It uses some basic formulas that “check off” some of the boxes. Notice how I say “attempts.” This is because it’s very formulaic. And, also, it’s not very accurate nor predictive. In fact, often it gives you bad advice because it will direct you to do things that will lead to keyword stuffing (which is very bad for SEO) as well as poor writing, and that is bad for user experience. And, if it’s a bad user experience, it’s bad for SEO.

Many people mistakenly think that if they get a green light that their post is SEO optimized and will rank well. This simply isn’t true. Far from it. It’s all based on the keyword phrase that you enter. It does not tell you if that’s a highly searched term nor your chances of ranking for it. And, it’s simply garbage in/garbage out.

–Debbie Gartner

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.