Best WordPress Performance Tuning


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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You need speed strategy and value analysis.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

Scores don’t count – millisecond load times do!

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

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

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

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

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

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

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


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

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

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

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

Hire us to help you. Not those other guys.

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

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

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


6 suggestions for radical site speed surgery.

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

Setting limitations upfront determine what kind of theme you can use. And how many images you can have. We’ve found it’s best to steer clear of “premium” (paid) themes. Why? Because they’re loaded with unnecessary features (bloat). Achieve better speed from a stripped-down free theme. Then add only the plugin features you need. The number of plugins is not a problem. Plugin quality – not quantity – is the real speed issue. This recipe produces a faster origin site.

We prefer a free theme because they’re not loaded with features. Paid themes are usually gold-plated and over-engineered with non-features. Free speed theme recommendations include:

Many don’t activate code baggage like jQuery or Font Awesome. You can strip them of anything lacking substance.

NOTE: The pro (premium paid) versions of the above speed themes double the page weight. This is not super significant. But we find the inefficiency and lack of documentation annoying. They brag about the free version’s speed. Then don’t publish the extra drag added by the premium version. That’s an advertising sin of omission. So if you’re into extreme speed, use the free theme without the extras. That takes creativity.

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

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

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

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

With discrete plugins, activate features where most needed – instead of globally.

The Facebook like-box is another common slow down. It’s known to add 40+ HTTP requests. On a clients site, we saw that it added 700 KB to page weight, which is not good! – Source

Find ways to either not use Facebook – or using it in a limited way. Reduce the load as much as possible. Is Facebook making you money? Be honest. Or do you dream it might? We don’t hate Facebook because we’re demure introverts and antisocial. We despise Facebook for what they did to speed innocents. Dirtbag destroyers of velocity. Apathetic to speed.

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

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

Non-surgical extras for speed we place into the fine-tuning, tweaking basket. Testing tells which ones help your speed.

Do you suppose images are your biggest problem? They’re not. It’s rarely the case anymore. The two biggest factors are usually theme-related, slow plugins, and Facebook. Even worse than much-hated, third-party ads – but barely. NOTE– We optimize your image library for speed as part of our speed services. Every millisecond counts.


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

Let’s go – faster.
Our secret for fast, mobile-first, web pages: we surgically remove your slowest plugins. Our optimization services speed up your site – and save money, too. That’s origin optimization.

How expressive and classic design aesthetic affect mobile speed.

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

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

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

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

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

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

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

This pullquote is an expressive design element.

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

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

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

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

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

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



Carousels and sliders address two mythical universal design problems:

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

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

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

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

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

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

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

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

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

Get rid of:

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

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

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

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

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

Remove WordPress child themes for mobile speed.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Simple CSS
Active installs: 70,000+
Zip file size: 136k
All-time downloads: 154,782
Retention rate: 45 percent (very high)

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

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

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

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

Future-proof your web business with mobile-first speed to avoid traffic decline.

Is your site traffic declining? Speed and mobile strategy will improve your user’s experience. And “potentially” SEO. Other things influence traffic most. The biggest factors are content relevance – or economic conditions that create “need or motive.” This is frequently referred to as “market pain.”

Analyzing the popularity of your posts and pages is a good idea. You can drop or merge up to 20 to 30 percent of your site’s worst visited pages. This does more for better quality traffic than speed improvements.

Are you serving old-school, fixed-width web pages? Then at least 40 percent of viewers are having a bad user experience. When pages aren’t responsive and dynamic for small screens, we promise, it’s not good. Speed is secondary to that flaw for mobile. Making site changes to new faster, responsive pages, doesn’t yield immediate results. You must be patient. Making a site responsive and fast is a long-term investment. It future-proofs your web business.

There is no Google SEO improvement worth mentioning from making speed improvements. Honest! Their algorithm only takes into consideration less than 0.5 percent for TTFB. That’s all. They don’t even use their own PageSpeed test criteria. The irony. TTFB is something you pay for with your hosting. It has nothing to do with efficient, quality site construction.

Do you have expectations of SEO improvement from speed? Be aware it’s a myth spun by Google to manipulate web designers and developers. Google has their own ivory-tower, change-the-world agenda for bettering advertising revenue. But that’s another story (rant?). We’re all caught in the Google riptide.

Relevant content for good SEO.
Fast speed for good UX.

Our speed strategy is having subordinate pages and posts load in under 2 seconds. We measure with testing. Your more important pages (like a 50-percent-of-traffic homepage) need to be much faster. How much faster? Well, 1 second would be wonderful. Subsecond fantastic.

Fast speeds are difficult with a Home-page slideshow and third-party advertising. Disappointed? Sorry. Speed is usually about compromises.

How high is your anxiety level about traffic dropping? How would it affect your income? A drop of disinterested, unqualified leads is immaterial. It only counts if it influenced your income. A 50-percent traffic drop may only reduce income by 10 percent. What’s the damage estimate?

OK. So you have third-party ads. Any ads cause severe distress for speed. This is because we lose control over ads hosted on another server. We can’t cache the ads or use CDNs. They cause unpredictable load time delays. Ads are a necessary evil to make money. But not all ad suppliers are created equal. Some serve their ads faster than others. You must make business judgments. But eliminating the “noise” as much as possible helps with reducing load time. Only you as a business owner can make those value decisions.

Our recommendation is usually to remove all comments from WordPress. They don’t help SEO enough. But our opinion isn’t a hard and fast ruling. If you have a reason to keep comments onsite, it may have justification. Here’s our article:

READ: Does Akismet plugin help or hinder WordPress page speed

One reason to keep Facebook is comment-spam management. Spam volume can be horrific and loads down your server resources. That affects page speed.

With good image optimization, large images can be 10 times lighter weight. Not 10X faster but better anyway. Image presentation with slideshows (sliders) is inferior for speed. But strategic workarounds help. Sliders are not as cool as site owners think. And not only because of speed problems.

Handle future image optimization with automated plugin solutions. Some of the better ones are even free. Cutting down the number and dimensions of images is the main trick. That and using an image lazy-load plugin.


If a key competitor’s site is mobile responsive and yours is not, that’s their biggest advantage – not speed. Page speeds of under 2 seconds for first visits are good performance goals for your site. – a test owned by Google – is a good site for worst-case scenario speed testing.

Internet average page weight is 2.3M. Not fast pages – average pages. A few image loading tricks help. Visually-lossless compression for JPEG images is the goal. Optimization pre-testing will show images often are 10 times bigger than needed. If you’ve been conservative – it’s costing you speed. These “fat” images are usually in sliders, headers, and featured images.

HTTPS / SSL is the worst thing Google ever forced upon the web for poor speed. It doesn’t make your site secure. It only encodes transmissions. Your site can still be hacked or pirated. They’ve caused an unnecessary panic for compliance. All pages slow down by around 500 milliseconds with HTTPS / SSL. Even Google’s home page is now slower and they don’t have any e-commerce on the page. Ridiculous! Grr!

Google is not our friend when it comes to their edicts. We should definitely liberate ourselves from HTTPS / SSL costs and speed deterioration. Google is using terror tactics. They claim it will affect SEO. There is zero proof. Relevant content affects SEO. There’s no SEO benefit whatsoever from SSL. Another web myth.

Many are using LetsEncrypt for the HTTPS / SSL certificates. It’s not a plugin. That’s a free service/code a developer must install on the host. It’s faster than some alternatives. But eliminating it completely is better for mobile speed. Installing HTTPS / SSL is not something we do or recommend.


All third-party scripts affect speed a lot. We add helpful plugins to do lazy loading of Vimeo and YouTube. Widget links (APIs and third-party scripts) are always bad for speed. If you keep Facebook, use a static image link instead of a scripted widget. Much faster. Same with Twitter.

Google Maps is heavy. If you use Google Maps, use creative workarounds. But our recommendation for mobile is avoiding Google Maps at all costs. Very slow.

There are various ways to manage email signups. It could be simple or complex. MailChimp can be fast. But sometimes people use the wrong plugins and slow down the entire site.


Linode hosting is usually very fast. We mean the fastest we’ve seen with TTFB of less than 100 milliseconds in some cases.

Please. Do not move your hosting to SiteGround! Every client who used them had problems with mobile speed because of random, wild TTFB.


You can improve your web projects with speed strategy information. Or we can do actual speed optimization (hands-on). For that, we need WordPress administrator access to your site. In other words, we can do either before or after work – aka tweaking (speed strategy vs speed repair)

The strategy focuses on value analysis and avoiding or offloading heavy site features. Our approach uses creative workarounds. Speed skills get better performance for your business objectives.

OFFSITE LINK: Customers-are-increasingly-mobile-first-yet-mobile-websites-are-sending-visitors-away

Fix WordPress plugins and PHP brokenness.

PHP 7 is twice as fast as PHP 5.x and requires one fraction of the server memory.

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 occur during web projects. Client or website owner expectations are high. Their technical knowledge is often low.

A new monster arose on the WordPress horizon. New problems for PagePipe anyway.

The fragile nature of WordPress and PHP v7.1.

Why does adding PHP 7.1 break your site? Our recent GoDaddy-host-server transition rattled the nerves of even the initiated. It’s a good example of what goes wrong. Upgrading PHP version 5.6 to version 7.1 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 is 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.

74 percent of WordPress sites still use slower, obsolete PHP versions 5.x.

Above: Pie chart – Percentages of WordPress sites using different PHP versions.

Risk breaking my site? Why even care about PHP version 7.1?

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 by 2x. That’s right. Twice as fast is the typical gain in speed. For us, that’s phenomenal. We’ve 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!

PHP 7.1 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
Retention: 27 percent

With this plugin above, you can check your site for PHP 7 compatibility.

WordPress phpinfo()
Active installs: 20,000+
Compressed download: 8k
Retention: 10 percent

With this plugin above, you can check which version of PHP your site is using without using Cpanel access.

So what broke after the change from 5.6 to 7.1?

  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.
  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 downloads don’t need signup.
  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.
  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) but not updated for over 1 year. Why? It’s a pain to get things approved by WordPress. GitHub has version 4.0.0 free substitute – and it’s PHP 7.1 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.

How fast was PagePipe home page after the switch to PHP 7.1?
699 milliseconds unprimed cache and 440 primed. Super fast 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. He’d be better off economizing in other areas.

Why no big gains? Because we have optimized the Home page. 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 actually a test of site bloat. Big improvement from PHP means big potential for site optimization.

HTTPS / SSL and it’s negative impact on mobile speed.

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

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

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

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

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

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

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

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

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

So if you use SiteGround 1.2 second TTFB + 500 ms for SSL + 125 ms for CloudFlare redirect = 1.825 seconds TTFB total. Subtract that from 2 seconds and you don’t have much left (175ms). That’s the result on a desktop – not mobile.

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


SSL by Default Usage Statistics
Only 0.3 percent of Internet websites redirect users to a default HTTPS/SSL version. –

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

Less than 0.3 percent! Hardly the stampede of panic many bloggers claim. Some are saying 30 percent of the web made the switch. That inflated bump occurred after Wikipedia switched to HTTPS. This shows the impact one powerhouse site can have. The English Wikipedia includes 5,475,729 articles and it averages 650 new articles per day. You can see why it made a statistical difference in HTTPS usage. But that hardly means everyone is using HTTPS.

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

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

This information is found at

Google Speed-Irony Strikes Again

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

Please note: ByteCheck is an HTTP site – not an HTTPS site. They know the price. Shown above 407-millisecond delay on a Google page. Yes. Even Google’s home page for search has this new delay. Incredible!

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

Let’s look at a few more examples:

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

459 milliseconds wasted!

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

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

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

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

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

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

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

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

The argument is that the website owner is assured they’re going to the right website owned by the right party. In a perfect world, this would be correct. In the world we live in though, it’s incorrect. Not because the certificate doesn’t verify the owner – it does. If a website housing a phishing page has verified HTTPS, it will show the user the lovely green padlock. Everyday users see the padlock and trust everything else from there, even if it’s from a different domain. Deception!

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

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


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

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

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

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

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

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

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

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

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

PagePipe’s TTFB is 208 milliseconds on cheap shared GoDaddy hosting. No HTTP / SSL Certificate delays added to global load times. Our book sales are handled using secure PayPal transactions.


According to BuiltWith, the entire Internet has 0.3 percent SSL adoption. Hardly the massive exodus Google and hosts like GoDaddy would have us believe.

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

PagePipe is moving clients off shared hosting to Pressidium. Because they have a 100- to 200-millisecond TTFB. With added SSL overhead, that’s faster than shared hosts. The new hosting costs about 10 times more than cheap shared hosting. We can then tolerate the TTFB handshaking performance hit for mobile-dominant audiences.

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

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

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

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

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

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

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

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

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

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

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

Is the Internet going crazy? Completely!

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

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

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

Legal spying is called data collection, not spying.

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

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

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

1.4 Million new Phishing Websites are Created Every Month

Concluding thoughts:

Last week our host, GoDaddy, emailed and then called us by phone saying Google was making the *big* Chrome change real soon. We needed to switch to SSL right away. Emergency! And that had a price tag. We refused to pay the $69.00 dollars minimum per domain per year. None of our domains “need” SSL.

GoDaddy has 17 million customers. Do the math.

That’s over 11 BILLION dollars pure profit. GoDaddy loves customers drinking the Google Kool-aid.

More about the misinformation.

We loathe the pure absurdity of Herd Mentality.

It’s killing web speed.

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

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

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

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

Google Maps and mobile WordPress speed.

Something we see bogging down Home pages is the faddish inclusion of a huge Google Maps dynamic graphic. Often the trendy map isn’t needed on the Home page – or it isn’t needed anywhere! It’s gratuitous 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.


Will Cloudflare’s DNS affect mobile speed?

“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. Brand spanking new.

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’ll do testing when time permits and let you know what we find. 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? Time will tell. 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 for at least another 6 months and only after thorough research of real-life user experiences. Our intuition says there’ll soon 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.


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.!/byHQAx/ to Melbourne, Australia!/nyFCY/ to Stockholm

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 those 1-second reports above 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.

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?]

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.

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

How page builders encourage slow page loads.

Because you like Elementor page builder plugin, does that make you’re a speed fool? No. Lots of people like Elementor (200,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.

Page builders don’t cultivate essential or simple UX.

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

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

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

3.) And 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. Page builders don’t encourage you to put the wrong words. But we needed to include this for 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?

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?

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 a 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 to do some work to motivate sales.

Using anything but system fonts on mobile is a waste of bandwidth. Mobile screens needs readable type more than decorative Google webfonts. Web designers don’t realize the utility of system fonts and fast loads are important. Page builders allow the choice of many Google Fonts. It’s almost a pressure 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.

Enhancing mobile user experience with speed.

Remember, improving your profitability by enhancing user experience – that’s number one. And the top of the list for user experience is: speed. It’s the first step (or stumble) users encounter on your site. It’s the first impression and causes a halo effect for subsequent site interactions.

Speed attracts. Speed speaks the web body language of quality and hospitality at a subconscious level. Everyone hates a slow site. They are frustrating and annoying. Repelling.

The goal isn’t to fix everything. It’s finding the low hanging fruit. The 20 percent that makes 80-percent difference in bettering your website.

Are you big into SEO? Speed isn’t directly about SEO. It’s directly related to UX. But a fast site, especially for a mobile audience, causes two metrics to change or improve.

First over time, bounce rate goes down. What is your Google Analytics bounce rate for the last month?

The other metric, dwell time, goes up. People stay on your site reading longer and visit more pages. What’s your average time on page?

Now if you improve these metrics, they’re indicators to Google of user intent. That’s important. It affects authority. It’s not quality of visitors – but quality.

The only permitted gaming of the SEO system any more is user satisfaction and delight. It’s about the end customer.

The only super significant metric is improved profitability.

And lastly, to see how much speed impacts your site: what’s your monthly traffic count and what percentage are mobile?

Mobile users care about speed most.

Better speed test scores aren’t the goal. It’s milliseconds of load time. Milliseconds, not rank. That’s what we watch. Reduction in page weight is also significant for mobile users. Weight consumes mobile data bandwidth.

We evaluate unrealized potential or opportunity.

WP Engine ruins mobile-first speed strategy.

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

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

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

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

You can’t be sloppy or apathetic.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.htaccess is used for speed functions. Such as:

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

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

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

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

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

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

Is your WordPress theme pernicious for mobile speed?

Everyone wants to hear the truth about speed

– until Steve Teare opens his mouth.

Speed Truth Hurts – Sometimes

Your theme and page builder are half of page weight – and another 14 percent is Facebook overhead – can pages still load in under 2 seconds?

Maybe in Heaven.

There’s no way on Earth. Not on today’s Internet. Maybe tomorrow?

We help in the plugin department.

Removing 100 percent of your plugins isn’t an option either.

The more wasteful and diseased your plugins – the more we can help.


Theme as speed killer.

If you’re using the Divi theme, it’s doubtful to get good mobile speeds.

Or, say, Salient theme with Visual Composer (now called WPBakery page builder).

Or The7 theme.

Those “solutions” aren’t mobile speed solutions – never were. Their day in the sun is over. Appreciated and adored no longer.

Cursed instead.

With this bad news, we recommend rebuilding for speed. Insult to injury! Nobody wants to hear that! Horrible pain.

Make what you’ve got stretch for as long as possible.

Get a return on your investment.

We’re healers. Not bandits. Results are what count.

A diagnosis of terminal site cancer?

Do doctors bill for delivering such cheery news: “You’re gonna die soon, son.” Oh, great. They do charge for that.

We’re not that kind of doctor.

Sometimes healing requires chemotherapy or radical surgery or radiation treatments. Not a mere bandage.

Healing a website is painful. Painkillers, anyone?

Radical site rebuilds for mobile speed? Don’t they take time? Yeah. It’s expert, detailed work. Make mobile speed your goal and it eventually happens. Patience.

Our suggestions for radical site surgery:

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

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

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

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

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

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

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

With discrete plugins, activate features where most needed – instead of globally.

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

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

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

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

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

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

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

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

Let’s go – faster.

Our secret for fast mobile-first web pages: we surgically remove your slowest plugins. Our optimization services speed up your site – and save money.
Learn More

Online speed test scores are especially useless for mobile speed improvement.

Online speed test scores are especially useless. These include lame tests like Google PageSpeed Insights. Many test-result recommendations don’t make any measurable difference in speed. They’re not real-world practicalities. They sound rational and appeal to logic. But they’re a waste of time and energy. You’ll drive yourself mad attempting to achieve perfect test scores. Google doesn’t even use test scores in page ranking.

So if speed test scores don’t matter, what does? Forget scores. It’s load time in milliseconds and page weight. Cumulative file size (page weight) is expressed in kilobytes or megabytes. Load time and weight make the biggest difference – especially for mobile audiences. Speed is critical for good user experience (UX). Readable, relevant content is most important for SEO. But impatient visitors won’t wait for slow pages. Then you waste your hard-earned relevant content and it’s never seen. Most sites are “not good enough” for mobile users.

Google gives you technical speed suggestions. These are published in their web master recommendations. Few make any difference in mobile speed. Why? Is it sadistic torment of website owners? We wonder. The most infamous waste is testing with Google PageSpeed Insights.

Here are some weird things Google often recommends *fixing*:

1. Eliminate render-blocking JavaScript and CSS in above-the-fold content.

This imperious rule is a great waste of time. WordPress almost always breaks this rule. The return on investment in improved speed is impossible to measure. It’s so small and insignificant. And there is high risk of breaking your site. If this *fix* tempts you, you’re a programmer and should leave PagePipe. You’ll hear disturbing things you don’t like here.  Plugins don’t help much – like the oft recommended Async JS plugin. Work on others things that are more important like image optimization.

Deferring Javascript while loading means taking Javascript to the bottom of the HTML document. This will cause the Javascript content to load last. If you load jQuery last, you’ll blow WordPress’ brains.

2. Minify and concatenate CSS, JS, and HTML files.

These improve your score – but rarely improve your speed. Scores are meaningless. It’s milliseconds of load time that count. Minification plugins frequently break sites. We don’t use a minification plugin on PagePipe. We’ve experimented with many. They make no difference in speed and only cause problems with Easy Digital Downloads plugin – among others. Does that mean we never use minification? No. If nothing breaks, fine.

Trimming HTTP requests cut down on number of calls to your server. The big theoretical gain is from concatenation (combining or lumping) JS script, HTML and CSS files together. These can break your site – white screen of death. It’s not worth it merely for an irrelevant score improvement.

3. Reduce server response time (TTFB 200ms).

This goal is laughable. TTFB is time-to-first-byte. It’s a measurement of server response time in milliseconds. Even Google’s home page can’t produce 200 millisecond time-to-first-byte specifications. That is because of HTTPS / SSL certification which introduces an additional 400 to 500 milliseconds of handshaking delays on the server.

How much load time does take? Using online test (owned by Google), the result is: 2.196 seconds. The full-load time can vary from 1.270 to 2.204 seconds depending on test server location. That’s right: seconds. Not milliseconds.

Try on the *peerless* PageSpeed Insights test. They can’t even pass their own test on the simplest of pages. Enough said. Zero credibility.

4. Optimize images.

When is optimizing images worth it? Well, we tested a page and Google PageSpeed Insights said we failed. Why? Because we could still optimize two images by 2 percent. What!? That’s ridiculous. And it didn’t detect resizing one image dimensions to save extra weight. That was more noteworthy.

Is it worth optimizing to remove 2 percent? No. Why? Because images are loaded in parallel. Improving image weight doesn’t make as big of difference in speed any more. Browser image loading is faster now.

Should we still optimize images? Yes. It’s important. But we can’t only optimize images and say we’re done.

Imsanity is one of the best plugin solutions for automatic optimization. Why? Because it’s easy to set image size reduction to column-width size and also set the JPEG image quality to 70. WordPress default is 82 but only on cropped images – not on uploaded originals to the media library. Imsanity crops originals. Most other image optimizer plugins charge money once you pass a certain threshold number of images. So beware.

What’s better is plain-old, manual sizing and visual, save-for-web optimization in an image editor like Photoshop, GIMP, or pixlr.

It’s not enough to just compress the images. Specify the dimensions of the image, or else the browser loads the entire image and then resizes it to required dimensions. Stretching with browser math delays image rendering.

5. Avoid landing page redirects.

Simply configure your WordPress site. Go to the “Settings > General” page. See if “WordPress Address (URL)” and “Site Address (URL)” options include “www” prefixes. If they do, remove them, save the settings and that redirect will be gone. Tip: Use Redirection plugin when removing old post to protect SEO.

6. Leverage browser caching.

Browser caching is beneficial for return visitors. That’s about 20 percent of your traffic. On a well-optimized site, caching doesn’t help much. When an unprimed cache loads in 750 milliseconds, how much better do you need to get? Adding a caching plugin may get speed down to 400 to 500 milliseconds best case. That 350 millisecond gain is good – but not if the caching plugin is complex or breaks your site with concatenation. We only recommend one caching plugin and it’s Cache Enabler. Make one simple setting: change the far-futures cache expiry to 8760 hours (1 year). You’re done.

Now, will a caching plugin get your sluggard 20-second page load down to a wonderful 2 seconds? No way. You won’t even measure a noticeable difference.

Tempted to use paid WP Rocket plugin? Consider this first.

7. Prioritize visible content.

Ridiculous. How do tests propose we do that on a WordPress site? This is sometimes referred to as above-the-fold content. Over-optimizing for speed is not worth the frustrations fixing the problems. Run a PageSpeed Insights test on Wikipedia or YouTube. Bet the scores are crummy, poor, or *needs work*. Suggestion: Ignore this silly test result.

8. Enable compression.

This just means switching on Gzip compression. If it’s not already enabled on your server, it’s a piece of cake with a plugin like Far Futures Expiry Header.

Other odd recommendations that usually don’t help speed much include:

  • Content Delivery Networks – CDNs are servers located in various geographical locations. They are closer to the users’ location and can reach content to them faster than the original server. A well-optimized site doesn’t need CDN. It’s a band-aid. Cloudflare has a free plan that we recommend you avoid. That’s right. Don’t use it. It slows down or delays your pages.
  • Accelerated Mobile Pages – Ignore making your webpages Google AMP compliant. This wasteful gimmick was announced by Google in October 2015.
  • Database Optimization – A periodic check and spring cleaning of databases to keep them lean and easily searchable. Cleaner plugins remove duplicate data, unwanted post revisions and more. Do they help with speed? Not anything we’ve ever detected. But it sounds like a good idea. We do it regularly. But it’s a matter of being vigilant and sleeping well at night. We’ve never seen speed improvement.
  • Removing query strings from static resources in CSS and JS files – Developers use “?” and “&” to bypass cached files before they are purged. However, URLs with “?” and “&” are not cached by some servers. You can use a plugin to remove them. This removal improves your score but not your speed. Remember, caching doesn’t really help so much.
  • Combining Images Into One – CSS Sprites – CSS Image Sprites were born out of the need to reduce the number of HTTP requests made on a website. The typical use of image sprites are for icons. This is where you bunch multiple images together into one big file. This is not very helpful and frequently won’t work on mobile-size screens. We say, “Forget sprites.”

So if those test parameters and tricks only help with scores – but not speed differences. What does matter most for speed improvement?

1. Themes without bloat. Popular themes like Divi and The7 alone take seconds to load – without any content or plugins. A typical responsive, free, stripped, WordPress theme with no bells-and-whistles loads in 40 to 50 milliseconds. Simplify.

2. Good Hosting – And we don’t mean expensive. If time-to-first-byte is too long (over 1 second), the only choice is changing your hosting service provider. You can have fast TTFB on shared hosting. We get around 250 milliseconds on cheap GoDaddy hosting. Test at

3. Lazy Loading – enable lazy loading for videos and images.

4. Gzip A compression technique reduces code files for faster transfer. It also saves mobile bandwidth.

5. Reducing Redirects – Get rid of as many redirects as possible. Redirects are good for SEO traffic. But you slow down the browser a little.

6. Disabling Trackbacks and Pingbacks – Trackbacks (manual) and pingbacks (automatic) appear in content moderation to let you know that someone else has put a link of your post on another blog or site. Most of these links are spam. It there’s too much of it, it can affect site speed. Disable them under Default Article Settings > Settings > Discussions. Or we can use a plugin that can deal with spam, like No Self-ping. Or use XML-RPC deactivation.

7. Disabling Hotlinking – Sometimes other *web criminals* use the content hosted on your site’s servers for their own websites. This is simply an extra load on your server. To stop others from using your server resources, the recommendation is changing your server .htaccess file code. A plugin will do the trick.

8. Identify plugins slowing down the website. Use the P3 Plugin Performance Profiler for this purpose. How much will this help? Our experience is you may save up to a second. That’s great on a site that’s loading in 4 seconds. But if it’s a 20-second page, you’re still in trouble.

Remember, it’s not the quantity of plugins that slow down a site. It’s the quality. We have 56 plugins. Our home page and most others load in under 1 second on shared hosting.

Use the performance report generated by the P3 plugin to remove or selectively disable the worst plugins dragging down site speed.

9. Selective activation of plugins Our best secret weapon for speed.

PagePipe’s secret sauce for loading 53 plugins in less than 1 second for mobile speed.

We turn conventional speed wisdom on its head. Fifty-three active plugins – on our site – load in under a second. Amazing. What’s our secret sauce?

When we do a speed audit – whether for PagePipe or for a client – we dial back PHP 7.1 to version PHP 5.6. Then we can run P3 plugin. The goal is getting some feedback of where 80 percent of plugin speed goes – and reduce that load. It’s Pareto’s principle in action: the 80/20 rule.

We use selective activation or deactivation of plugins on URLs. That’s the real-top-secret sauce. Most people don’t know plugins can add weight globally to websites. Not just to the page where they’re used. For example, Contact Form 7 adds about 43 milliseconds to every page and post on a site. It’s global loading and we call it “site drag.” It’s best to activate that plugin only on the contact page.

Next, we remove plugins whose features don’t add much value. You’ll see in this audit we removed 8 test plugins for a gain of 194 milliseconds. “Good work, Steve!” [breaks arm patting himself on back].

But it’s theoretical. P3 isn’t that accurate. You have to check real gains in milliseconds with or

We labeled all deactivated plugins used during maintenance as “offline” in the table below. Deactivated, mothballed plugins don’t slow down a website. That’s a common myth. No harm.

So the total estimated plugin load time is 435 milliseconds (±30 percent). But that’s never loaded at the same time on all pages and post. Because  selective activation saves the day again! More tweaking is always possible – but go for the low hanging fruit first. We even use selective activation to rid us of nasty plugin conflicts.

A selective activation example.

Easy Digital Downloads is a heavy 158-millisecond ecommerce plugin.  It’s not activated on our high traffic pages. This accomplishes our main goals for now. We’ll tweak more later on that one. We repeat: selective plugin activation is the secret. It keeps the Home page fast on shared magnetic hosting with no CDN.

The plugins causing the most trouble to configure are Watu Quiz, Easy Digital Downloads, and  UpDraft Plus. They required serious thinking and a learning curve. What made the effort worth the trouble? These are complex functions and important site features. It’d be a nightmare and tedious to achieve any other way. We prefer plug-and-play plugins with no settings. But for these three that’s impossible. They need customizing and making many settings. Once you’re done, it feels great. Like when you stop pounding your head against a brick wall.

“Let me explain… No, there is too much. Let me sum up.” – Inigo Montoya in The Princess Bride.

Our original intent was writing about each of our 53+ plugins. That’s too much work. So we decided to summarize PagePipe’s speed strategy.


PagePipe uses the default Twenty-seventeen theme. We’ve studied it, tested it, experimented, torture-tested, and written a lot about it. It’s fast.

Deciding what not to do on your site is just as important for speed as what you do.

What you won’t see on PagePipe:

1. Social Links (especially *like* counters).


3. Third-party ads or affiliate links.

4. Google Maps.

5. Contact form plugins.

6. Google Fonts.

7. Font Awesome.

8. CDN (like CloudFlare). We don’t use CDN. Period.

9. Special hosting (instead: common shared cheap).

10. Hundreds of JPEG featured images on blog posts (rotation instead).

11. HTTPS/SSL certification.

12. Popular TOP100 plugins.

13. Paid premium plugins or themes.

14. Alteration to PHP code or server side programming.

15. Google AMP.

16. SEO plugins.

17. Minification.

18. Emojis.

19. Slider on the Home page.

20. Google noCaptcha Captcha.

Things you will see on PagePipe:

1. Add Search to Menu – necessary for this theme. No sidebars on pages.

2. Add Widget After Content and Simple Content Adder (for top of content). These two plugins allow two random rotators for images and testimonials on all posts. They are selectively deactivated on pages.

3. A bunch of magic security plugins.

4. Optimization plugins

5. Evergreen content enhancers

6. Every resource we use is free! WordPress, the theme, and the plugins.


Our PagePipe plugins below are ranked slowest to fastest. We then examine the 80/20 ratio and focus the cumulative cutoff at 80 percent. Offenders are shown in “red.” Their value must be justified. Notice we deleted some heavy and redundant ones.

plugin name ms percent cumulative activation/deactivation
Easy Digital Downloads 158.2 36.35% 36.35% Home & 2 conflicts
WP Experiments Free 0.00% 36.35% Deleted 109.9ms
Worth The Read 0.00% 36.35% Deleted 44.8ms
Simple Content Adder 40.3 9.26% 45.61% Home & 2 pages
WordPress Popular Posts 31.7 7.28% 52.90% Home & pages – posts only
Broken Link Checker 0.00% 52.90% Offline 28.3
WordPress 23 Related Posts Plugin 25.4 5.84% 58.73% Home & 4 pages
WP Image Refresh 23.4 5.38% 64.11% Home & 3 pages
WP Counter 0.00% 64.11% Deleted 19.8ms
Easy Forms for MailChimp 18.8 4.32% 68.43% one page
UpdraftPlus Backup/Restore 17.3 3.98% 72.40% run weekly
WP HTaccess Editor 0.00% 72.40% Offline 16.6ms
PDF Image Generator 0.00% 72.40% Deleted 15.3ms
Blog Manager Light 9.7 2.23% 74.63% blog listing directories
Redirection 9.4 2.16% 76.79%
Post Notif 9.4 2.16% 78.95%
WP Super Simple Speed 8.9 2.05% 81.00% ecommerce pages
Cache Enabler 8.6 1.98% 82.97% ecommerce pages
Limit Login Attempts Reloaded 7.7 1.77% 84.74%
Watu Quiz 6.1 1.40% 86.14% mailchimp conflict 1pg
WP Thor Heartbeat 6.0 1.38% 87.52% mailchimp conflict 1pg
Master Slider 4.9 1.13% 88.65% on catalog page
Block Bad Queries (BBQ) 4.7 1.08% 89.73%
Lazy Load by WP Rocket 4.7 1.08% 90.81% video lazy load conflict
Quotes 4.0 0.92% 91.73% two pages
Optimize Database Delete Revisions 0.00% 91.73% Offline 4.0ms
Simple Drop Cap 2.9 0.67% 92.39%
WP Editor Widget 2.8 0.64% 83.62%
Title Remover 2.7 0.62% 84.24%
Admin Post Navigation 2.4 0.55% 84.79%
Add Search To Menu 2.2 0.51% 85.29%
Disable Comments 2.2 0.51% 85.80%
Asset Queue Manager 0.00% 85.80% offline 2ms
Imsanity 0.00% 85.80% offline 2ms
WEN Responsive Columns 0.00% 85.80% delete redundant 1.9ms
Add Widget After Content 1.8 0.41% 86.21%
Beacon Plugin 0.00% 86.21% Offline 1.5ms
Disable Emojis 1.4 0.32% 86.53%
HW Image Widget 1.3 0.30% 86.83%
Plugin Logic Rules 1.2 0.28% 87.11%
Easy Table 1.2 0.28% 87.39% pages not posts
Perfect Pullquotes 1.1 0.25% 87.64% pages not posts
Pro Related Post Widget 1.1 0.25% 87.89% Home & 2 pages
Shortcode For Current Date 1.1 0.25% 88.14% Home & 2 pages
WP jQuery Plus 0.00% 88.14% Deleted redundant 1.1ms
Change Table Prefix 1.0 0.23% 88.37%
Email Address Encoder 1.0 0.23% 88.60%
Host Analytics js Local 1.0 0.23% 88.83%
Deactivate XML-RPC Service 0.9 0.21% 89.04%
Lazy Load XT 0.9 0.21% 89.25% Video & conflict pages
Tuxedo Big File Uploads 0.8 0.18% 89.43%
Query Strings Remover 0.00% 89.43% Deleted redundant 0.8ms
Remove Google Fonts References 0.8 0.18% 89.61%
Far Future Expiry Header 0.00% 89.61% Deleted redundant 0.6ms
Hide Featured Image 0.6 0.14% 89.75%
Simple WP Sitemap 0.5 0.11% 89.87%
WP Author Date and Meta Remover 0.5 0.11% 89.98%
Current Year & Copyright Shortcodes 0.4 0.09% 90.07%
Plugin Logic 0.4 0.09% 90.17%
Restore Image Title 0.4 0.09% 90.26% Home & 1 page
Enable Media Replace 0.3 0.07% 90.33%
One-Click Child Theme 0.3 0.07% 90.40% on two pages (2017 theme)
WENS Responsive Column Shortcodes 0.3 0.07% 90.46% where used
Restore Image Title 0.2 0.05% 90.51%
Server-Mail-Check 0.2 0.05% 90.56%
Simple back to top 0.1 0.02% 90.58% two conflict pages
CAOS Analytics 0.0 0.00% 90.58%
TOTAL milliseconds 435.2
active plugin count 53

Speeding up aggregator WordPress websites.

Aggregator websites getting 1 to 2 million visitors per month is pretty nice – and profitable!

Many agregator sites are somewhat “responsive” for mobile – but frequently don’t have good UX on small screens like an iPhone. It’s very cluttered and confusing. Aggregator sites have about a 70 percent bounce rate typically. Top aggregator sites are getting as low as 25 precent bounce rates with 2 million monthly visits.

Strategic monetization attempts forcing users to look at ads. It’s bad UX – but perhaps it pays out for your company. User’s generally have a low tolerance of anything that gets in the way of content. Perceived obstacles are bad.

Most aggregator home-page loads are between 8 and 10 seconds in the USA. Mobile speeds will be twice that. Our goal (performance budget) is a 2-second page-load time (4-seconds for mobile).

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

“Ads are always the worst code on the Internet, and once you include them you can’t really be accountable for performance any more.”
—Matt Mullenweg: WordPress founder, August 2015

Aggregator sites use many third-party widgets.

There’s esoteric talk and proposals in the “website-performance” community to solve third-party integration problems – but few actually provide real-world solutions. They talk about the web future – but not today’s resources. Third-parties are often apathetic about speed. This is a killer for mobile (and desktops, too).

How to manage and control third-party content is the critical factor for speeding up your website. What this means with present “tools” is using better strategy to decide what third-party provider content can be synchronously loaded, deferred (or lazy loaded) – or disabled on critical pages. And things like not updating user-facing Facebook stats in real time.

Landing pages, product pages, and pages on the “money path” are of most interest.

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

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

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

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

Is all of this investigation worth the grief? Common sense says, “Absolutely.” People hate slow-loading pages. Bloat is frustrating and annoying. But there’s also experiments (data) by large companies that prove speed affects profitability.

Speed helps you stay ahead of your competitors by differentiating your mobile UX. Optimization is best when it’s built-in with advance strategy – instead of after-the-build fixes. Measuring the impact of third-party content on a site’s usability is often an afterthought – if it even gets thought about at all.

Suggested links:

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

25 cool websites – a load-time analysis.

How could we resist a list of select WordPress websites reported as “cool” – as in neat-o or spiffy? They described the  sites as astonishing and perfect examples. Our curiosity got the best of us. We had to know how fast these “cool” websites loaded in browser windows. You can see the article and website thumbnails at:  25 Cool Websites Made with WordPress

urns out not all the websites were done with WordPress. Oops! They note these errors in the article’s comment section. There were only a few offenses – but demonstrated this wasn’t a well-researched article. Credibility in the toilet!

To make fast measurements of load time (speed), we used a Firefox Add-on. It allows us to get the page load time of any web page. That add-on is app.telemetry Page Speed Monitor. The Chrome browser extension equivalent is Page load time. As soon as you access a page, you’ll see the load time in the Firefox browser status bar. Is it a more scientific measurement? Not really. But it’s better than nothing and fast. We didn’t want to wait in line at or

We accessed each featured website’s home page. As expected, we saw appalling long load times. But just how bad were these “cool” websites for poor speed?

How good is good enough?

We’ve written before about the audience expectation for wait time. Here’s a quick summary:

Viewer expectation of page load time.

Usability studies established how long people expect “machines” to take. Passing seconds alter human perception. These human expectations have not changed for over 30 years.

Sub-second page loads have the illusion of instant response. This is often achievable on the web under excellent and pricey hosting conditions. Or use cheaper speed strategy and build a fast site – even on shared hosting.

A one-second page load, or page change when clicked, yields a seamless flow of thought. This meets an ideal criterion of having the user be “in the flow.” Changes are not noticed thus causing no distractions.

After 10 seconds of waiting, attention begins to wane. This is the point where users will bail out off a page. They may begin another search or hit the back button. At 11 seconds, the “visitor” is usually gone for good. Only the die hard who arrived with an exact purpose – or knows the value of the website content – will hang on – maybe? But at the least, it’s still annoying and frustrating.

We’ve suggested a WordPress standard of a two-second, load-time goal or performance budget. Especially for Google’s mobile-first indexing. This is for sites using low-cost shared hosting. It’s not perfection but it’s “good enough.” We’ve proven it’s possible.

So how did the sample of 25 “cool” websites measure up?

Eleven sites loaded in under 11 seconds and eight were under 10 seconds. None of the sites loaded in under 2 seconds. The fastest site (Facebook blog) was 3.44 seconds. They were trying to set a good example but still had poor performance.

The rest of the 14 remaining websites loaded anywhere from 12 seconds to 40 seconds. The medium being 15 to 20 seconds. These are horrible load times. Many sites showed spinner indicators. Users then wait and watch the little animated whirling icon. These are throwbacks to Flash animated websites that most everyone hated.

Our conclusion: the “cool” factor had too big of a performance price tag. It rendered a poor user experience – or even better said, “No user experience.”

Don’t use CloudFlare: build in speed quality instead.

Many 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 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 the Codium Grid theme, we found CloudFlare doesn’t guarantee consistent load speeds. During this project, we saw unpredictable and random page load times from 10 to 25 seconds. That’s unacceptable even if the average time is one second.

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 results in Our cached time improved from 750 milliseconds to a 500 millisecond load. We’re giddy from this discovery.

Christian Nelson, ally and web critic, saw this weird, random, delay phenomenon years ago – but not on CloudFlare. He’s maintained a low opinion of CDN solutions since. He’s right on the money. CDN response times can be unpredictable.

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.

Our complaint: Who cares about TTFB when CloudFlare throws a monkey wrench into the running engine and randomly gives 10 second to 20 second page loads? Hiccups aren’t acceptable.

Stop worrying about Time To First Byte (TTFB)
05 Jul 2012 by John Graham-Cumming of CloudFlare. (A rebuttal).

Our experience is Cloudflare CDN is notorious for slowing down your site with 500 and 501 server errors. That’s probably where your TTFB errors are coming from. Cloudflare uses NGINX servers instead of Apache. This causes lazy loading of all Gzip compressed assets. Unnecessary delays. TTFB is the only metric Google uses in their 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.

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

Offsite link: CloudFlare Makes Websites Slower, Not Faster “I noticed that my CloudFlare-enabled sites became much slower and they would often time out.”

[bscolumns class=”one_third”]

If you’re new here, start with our best primer speed articles.


[bscolumns class=”one_third”]

If you’re ready to give your WordPress site wings, here are powerful tools to speed up your site.


[bscolumns class=”one_third_last”]

Learn how the most popular plugins and ideas waste your time – and hurt web speed. Includes important tips for mobile speed without coding.


Why does SiteGround fail TTFB testing for WordPress sites?

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 crappy 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 sharing! With Solid-state Disk Drives (SSD) even! Are SiteGround customers paying for fantasy speed?

SiteGround claims the WordPress plugins are causing TTFB delays. They have to be kidding! PagePipe has 53 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

[bscolumns class=”one_third”]

If you’re new here, start with our best primer speed articles.


[bscolumns class=”one_third”]

If you’re ready to give your WordPress site wings, here are powerful tools to speed up your site.


[bscolumns class=”one_third_last”]

Learn how the most popular plugins and ideas waste your time – and hurt web speed. Includes important tips for mobile speed without coding.


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

Speed improves Google page rank less than 1 percent.

Studies such as those from Moz demonstrate site speed is a small part of Google ranking factor. Nothing suggests it improves SEO more than 1 percent. We agree that overall page load time is not the SEO killer many make it out to be.

While the Moz article seems stale (2013), nothing changed in the speed business concerning page ranking since 2010. The content is still valid today.

Backlinko’s detailed 2016 investigation of wider ranking factors shows relevance and authority remain the driving forces in terms of organic traffic.

Nevertheless, users demand fast-loading sites, and the potential negative impact of slow speed on conversions is well-proven. With the rise of mobile showing no signs of slowing, the need for speed  remains strong.

Google’s in 2010 announced site speed as a ranking factor, but the actual details revealed were vague. Citing previous internal studies, Google confirmed that site speed would be added into the mix of existing ranking signals, but stopped short of discussing how much weight it would actually carry. A number of points were, however, stressed from the outset:

  1. Site relevance would remain more important than site speed for SEO.
  2. Fewer than 1% of search queries would be initially affected.
  3. The site speed SEO signal would only be initially applied to searches in English on

We recommend reading this link for more details:

Does WordPress Site Speed Really Matter for SEO? >

“SPEED MATTERS” somewhat-lame, self-promotion for SiteGround.

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: Read about average load time on mobile >

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.

PagePipe: The problem with large Hero images for mobile >
PagePipe: Color as a mobile speed strategy >

6 Reduce the usage of external fonts. We agree with this suggestion but we go even further. There are various plugins that can “exorcise” this font fluff. Our recommendation is Disable Emojis and Remove Google Fonts or Disable Google Fonts plugins. We’ve used all these plugins.

Or choose a theme that doesn’t use any webfonts – just websafe ones. Yes! Those themes do exist. We’ve written about those, too;

PagePipe: Speed report: 35 theme candidates >
PagePipe: 15 free themes are prime candidates for testing aesthetics and customization >

To get rid of Font Awesome, you’ll need to use Asset Queue Manager plugin. This plugin can “break” your site with some themes so proceed with caution. But we love this plugin and use it a lot to strip down bloated themes.

PagePipe: Websafe fonts are still the hottest >

7 Manage the volume of comments on your site. This isn’t the first we’ve read about comments slowing down sites. But we haven’t seen any real data to prove it (yet). We know a few reasons why comments in theory cause slowness from database issues. SiteGround makes two plugin recommendations for comment management. But we’re more hardcore about achieving goals and streamlining sites. We say, “Get rid of comments completely.” Read about our radical ideas on comment management:

PagePipe: Should you use Akismet anti-spam plugin?

8 Enable Gzip compression for your pages. SiteGround recommends editing your .htaccess file but don’t say how to do that. So SiteGround must not have Gzip enabled like on some hosts. This .htaccess file edit is not an easy thing for newbies. We think it’s a pain. It’s easier to change the .htaccess file on your server with Far Future Expiry Header plugin. Read more about Gzip:

PagePipe: Update on Gzip Compression >

9 Enable caching. OK. Unlike the rest of the world, we don’t think caching helps much on a well-optimized website. We just never see speed benefits. SiteGround makes two plugin suggestions. WP Rocket, a paid plugin, and WP Super Cache, a freebie. We’ve experimented with both of them and like we said: “We aren’t sure they help much.” Yeah. They’re band-aids for sloppy-built websites. But don’t help quality sites.


The recommendations in this section are kind of silly or else just common sense. Someone must have been trying to fluff up the report with filler. SiteGround then goes on to tell us many things we’ve already covered:

10 Select a reputable theme from a solid provider. We only use free WordPress themes from their repository. That is our choice and self-imposed limitation. It speeds up our decision making and creative process. We don’t have time for shopping. We don’t spend money on complicated “premium” themes. Not us.

11 Avoid bloated themes. Their explanation of what is a bloated theme is good. Avoid sliders.

12 Always use a child theme when creating your website. This is common sense for safety sake. It prevents future updates from overwriting your customization. But what does a child theme have to do with speed? Nothing. Child themes load another CSS file. So this recommendation doesn’t make sense.

13 Optimize for mobile devices. Really? You need to tell people this? And they recommend the plugin WP Touch (non-native mobile conversion). This isn’t good. Even when they afterwards say, “Having a native mobile version is always preferable.” Even that isn’t a good idea. What’s preferable is using a responsive WordPress theme. A mobile version is  a second version of your website that sniffs to detect a small screen device and then redirects to the mobile version. Not the same as responsive which just serves one site – no duplication.

14 When using icons, use an icon font. We despise icon fonts. They are heavy and slow-loading – the bane of speed. We disable icons whenever possible.

15 Don’t overlap functionality with plugins. A good suggestion but isn’t this just common sense again. Don’t duplicate stuff. Simplify.

16 Always keep your plugins up-to-date. This is just good housekeeping. Staying updated and current helps speed? We haven’t seen any evidence yet. SiteGround claims it’ll give your site a huge performance boost. Serious? Got some experiential proof of that? Or is it just theory? Or exaggeration?

17 Cleanup your plugin options from your database. We do this as best practice. Again, it’s seems like just common-sense good housekeeping to us. We’ve never seen any speed boost yet from cleanup – even with big fat databases. There are several plugins to do this. We don’t make a recommendation. We’ve tried them all and it gives a nice feeling that you checked the databases and verified. But no speed improvements whatsoever measurable.


Now we’re into the promotional selling materials of the brochure. In other words, SiteGround specific features they hope to motivate us to buy.

18 Take advantage of sever level caching.

This is pure specsmanship and boasting about SiteGround’s capabilities.

19 Use a CDN. We’re not sold on CDN’s. They don’t help much for a  well-optimized site. Just like caching. If you need a CDN, it is indicative you didn’t build your site as well as you thought. Another speed band-aid. The author said in his video to test CDNs since they can slow down your site. Good advice. That’s our experience with free CloudFlare. Slowed by server 500 and 501 errors. Longer TTFB (time to first byte). Badness.

20 Use SSL and utilize HTTP/2. This is a nice way to upsell and make money for SiteGround. These aren’t necessary  for speed. SiteGround was kind enough to mention a free alternative. Secure third-party transactions like with PayPal means this stuff isn’t needed.

So what’s missing?

We think social links are a big culprit for site drag. That isn’t mentioned anywhere in the Ebook. Most site owners don’t realize social media gives little benefit. But they feel like an outcast if they don’t have it. Yes. There’s stigma to conform to the herd. Don’t give into this peer pressure. Social buttons and likes slow down pages.

Remember what your mother taught you about peer pressure and popularity. They can be bad news.

If you have to use social media, use static image buttons or CSS buttons links instead. The fastest loading social-sharing button is none. Do value analysis. What kind of return are you getting on your social media? Is it a time waste generating that social content?

Hristo advises on another blog against going overboard with Social Media widgets or plugins. He just forgot to include it here. Social widgets and plugins ping their respective servers, delaying page loads. Particularly, Hristo says not to use IFRAME. He recommends using one plugin that covers all the social networks. (Facebook, Google+, LinkedIn, Twitter, Pinterest etc). Don’t use a separate plugin for each network. Again, we think social media is as useful as a cast-iron paddle in a chicken-wire canoe.

We disagree with this ebook, web hosting isn’t key to great performance.

We’ve seen sites on great hosts (including SiteGround) with lousy speed tests. It’s more essential to use speed strategy for balancing aesthetics and speed.

They said nothing about failing some basic Pingdom tests and the simple plugin solutions:

Query Strings Remover 1.5k
Removes query strings from static resources like CSS and JavaScript files. This plugin claims it will improve scores in Google PageSpeed, YSlow, Pingdom and GTmetrix. Just install and forget everything, as no configuration needed. Note: WP Rocket claims removing query strings doesn’t improve speed, just scores. We suspect they’re right.

Speed Booster Pack 82k
Speed Booster Pack allows you to improve your page loading speed. You’ll get a higher score on testing services. (GTmetrix, Google PageSpeed, YSlow, Pingdom, or Webpagetest). We’ve tested this plugin. We found it’s minification features succeed where other minification plugins caused conflicts or white screens. It’s not for everyone but worth noting here.


The SPEED MATTERS ebook is better than most with good speed suggestions. But plainly selling services. At least it doesn’t perpetuate the myth that speed improves search engine optimization (SEO). That’s always a disturbing lie told by many site optimizers.

PagePipe: Page speed doesn’t affect SEO rankings much >

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 Home pages.
  • 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 blogs.

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

WPMU DEV Checkup Speed Results are worthless and a waste of time.

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 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 like this plugin. The test told us none of the above-the-fold content could be render until this CSS file got out of the way. Now from experience, we know above-the-fold rendering blocks are a deceptive waste of time. It’s pure crock. They gave us a red-alert alarm on this little thing. Why? Instilling fear.

Where is the fold on a mobile device anyway?

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

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

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

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

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

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

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.

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

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

6Optimize 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 which slows down TTFB by up to an additional 500 milliseconds. We don’t need it. All our transactions are via PayPal. 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 and WP Super Simple Speed. Two caching plugins? Really? How odd. Are we paranoid? No. We’ve just found these two together do a nice job for us. 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.


How to interpret and for mobile WordPress speed.

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

How to interpret and speed test results.


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

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

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

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

UNDER 9-minute video:

And this link helps: is for quick-and-dirty best-case scenarios. First test is unprimed cache and second test (click again) is primed (faster). is for worst-case scenarios. It’s more reliable but takes longer to test.

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

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

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

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

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

Roasting Google for mobile speed fraud.

Attempting to dictate the rules of speed quality, Google made the mobile Internet worse. How did they shoot their own foot?

Well, it didn’t happen overnight. Google shot over and over again. Destructive repetition. Foot target.

Google’s speed misadventure began in 2010. They announced speed as a factor in ranking websites. But Google was vague how much speed would affect SEO. Nor would they tell which aspects of speed made a difference. Everyone got excited. Lots of wild guessing. And soon, a web myth emerged. Never spoken by Google but assumed by the herd: “Speed is now critical to good SEO.” A blatant lie people use to sell speed services, addons, plugins, themes, and books. Panic in the air.

The truth is “page speed” never made much difference at all. Not for SEO anyway. It did for UX. It’s bad user experience to keep visitors waiting – especially on mobile devices. Google even said relevant content and UX were more important. But many website owners and bloggers ignored or missed those important words.

How much load time does take? Using (owned by Google) the result is: 2.196 seconds. The full-load time can vary from 1.270 to 2.204 seconds depending on test server location. That’s right seconds. What? That naked page only has a logo and a search field. Tell us more: 16 HTTP requests. 471k page weight. Time to First Byte is 593 milliseconds.

Improve Server Response Time: This rule triggers when PageSpeed Insights detects that your server response time is above 200 milliseconds. –

Google TTFB (Time to First Byte) is 593 milliseconds?! Surely that’s a mistake. Nope. Their TTFB alone is almost triple the 200-millisecond Google rule.

Google doesn’t even keep their own edict of 200-millisecond TTFB (server response time).  Their homepage TTFB ranges from 369 to 774 milliseconds depending upon where in North America the test server is located. So results fluctuate and vary.

Faster TTFB size is a benchmark of a well-configured server application.

TTFB is server overhead. An unfortunate delay caused by mechanical or physical parameters. It has nothing to do with page content or web code. TTFB is mostly hardware dependent. It’s usually beyond your control. TTFB is the duration after calling for server assets until the arrival in the browser. Good TTFB is under 200 milliseconds. Bad TTFB is one second and up. Terrible is above 4 seconds. Yes. Some servers are just that rotten.

So TTFB is something you buy. You pay for it. Your host owns it – not you. You can’t build or code it into your WordPress website. In other words, the poorer you are, the worse your TTFB. The richer … well, you get the idea. So much for web equality and democracy.

Yet, TTFB is the only parameter Google uses to check your site speed in their secret algorithm. And it improves your ranking less than 0.5 percent.

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

But, Google has the fastest servers in the world. Correct? Wouldn’t their TTFB be the best and faster than 593 milliseconds? I mean, our cheap GoDaddy hosting gets better than that. Why the difference? It’s Google’s SSL Certificate. Read more below how this causes speed delays.

PagePipe doesn’t use SSL certification. We don’t need it. We’ll save our 500 milliseconds. Sales transactions are managed securely and efficiently by PayPal. Yeah. We sell a downloadable ebook, Toxic WordPress.

Well, here’s another place Google shot themselves in the foot: Their HTTPS / SSL initiative in 2015. It wasn’t moving along like they wanted after a few years. So they again said, “SSL certification will not only affect security – it will now affect page ranking.” Everyone got excited again. People started adding this non-feature to their websites in droves. Did they all need it? No. Did it help SEO? No. Did it kill speed? YES!

HTTPS / SSL server handshaking creates an initial stall in making Internet connections. There’s a slow delay before anything starts to render on your visitor’s browser screen. This delay is measured in the Time-to-First-Byte information (aka TTFB).

What is the typical TTFB delay caused by SSL certificate handshaking? 500 milliseconds. That’s 25 percent of a 2-second performance budget.

Learn about the gory details of this silly blunder by Google:

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

Are we done bashing on Google and their weird speed policies and practices? Not yet. We want to mention Google AMP (Accelerated Mobile Pages).

In 2015, Google said articles served from its Internet network were four times faster. That’s right. But developers disagree. Engineering or “designing in” page optimization gives the same or even better results. That’s right. It appears Google has a hidden agenda not-so related to speed. That’s their mask.

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

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

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

PageSpeed Insights is the worst speed test on the web. Why? It’s usually impossible for WordPress to pass this test. WordPress almost always has jQuery enqueued. That causes goofy warnings. But Google doesn’t use PageSpeed test scores in it’s ranking algorithm. They use TTFB (time to first byte). It’s a frustrating waste of time.

READ more PagePipe: Google PageSpeed Hypocrisy

We’re almost done! We must discuss Google Fonts and their impact on mobile speed:

External font scripts like Google Fonts slow down your site.  We guarantee websafe fonts are faster. According to HTTP Archive, as of October 2016, web fonts (like Google Fonts) are just over 3 percent of an average page’s weight.

Disabling with Remove Google Fonts References plugin makes an average difference of only 53 milliseconds. But in the extreme, one theme had a 300 millisecond gain in speed. In some cases, there was no change in speed at all.

The difference in weight is anywhere from 60k to 300k. Again, it’s wasted mobile bandwidth.

Would we delete Google fonts and go with default browser fonts to save 300 milliseconds? You bet. When we’re working on getting under 2 seconds or even 1 second, that can make a big difference.

Again, there are times requesting Google Fonts will throw a 1-second delay. Why? We don’t know. Go ask Google. And, of course, the more fonts you call the slower things get. There’s a plugin that combines the Google font requests. Google WebFont Optimizer finds every Google Font request. It bulks them all together. Then your website only asks Google once for the fonts, instead of multiple times. Still, our preference is to delete Google Fonts completely.

OK. We’re finally done bashing on Google ruining speed. We may get blacklisted. It was worth it.

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

Investigating Vertikal theme with Visual Composer for mobile speed.

Visual Composer is a $34 page builder for WordPress.

We don’t review paid plugins – unless it’s a roast or exposé. Visual composer is a page builder that adds Javascript and CSS files. Your site is faster loading built without it. How much would it improve speed to dump it? We guesstimate between 500 milliseconds and 1 second. Not too bad. Visual Composer plugin does consume limited server resources on shared hosting. That can get your site suspended temporarily.

We don’t use Page Builders. Mobile sites don’t usually need them with only one column of content. We find them too frustrating (slow) and in the end we can get the same results (only faster) using discrete plugins and other workarounds.

We did an investigation of a PagePipe reader’s site. It was built with Visual Composer using the $25 paid theme Vertikal:

Vertikal (built on top of Bootstrap).
Vertikal theme is a multipurpose theme.
Author: PremiumLayers.
Features left, vertical, animated navigation menu.



Load time: 3 seconds
Page weight: 925k
Requests: 52


Load time: 874 milliseconds
Page weight: 473k
Requests: 51

NOTE: You can hit subsecond testing with Run it twice. The first pass is the unprimed-cache load time (first visit) and the second is the primed-cache time (return visit).



Load time: 4.4 seconds
Page weight: 918k
Requests: 53
TTFB: 1.35 seconds < This is a killer. Time To First Byte is the time it takes to start rendering your screen.

Time-to-first-byte is a measurement (in milliseconds) indicating the responsiveness of a web server. It’s the server “speed overhead.”


Load time: 1.993 seconds
Page weight: 465k
Requests: 51
TTFB: 364 milliseconds

TTFB was improved with Cache Enabler plugin.

More about TTFB here.

Cache Enabler and WP Super Simple Speed combined. WP Super Simple Speed enables Gzip for you – among other things. Don’t be afraid of the two-year staleness warning on WP Super Simple Speed plugin. It works fine with PHP 7.1.

Cloudflare CDN, the free version, doesn’t always help – or worse – is a detriment:

Try and get speed without a CDN – using strategy and plugin tricks. CDN is a last-ditch rescue.

Contact Form 7
Appears to be globally loading.

Google fonts
Open Sans and PT Sans Narrow.
see link below next item.

Activated (enqueued).
Your theme is using FontAwesome for little icons (phone, envelope, etc) better not mess with it.

Popup Magnific loading but not seen.
Responsive lightbox plugin available on GitHub.

Activated (but not used on home page).

Regular jQuery

WP jQuery Plus is undetectable. It depends upon if the Google version is in the cache. Which it probably is. But no speed test will reflect the improvement of an asset that is already present. It’s transparent. But you will see changes in the “waterfall” of page elements. Check that for file name changes. This helps you verify where the jQuery source is coming from.

Images: 7 PNGs and 1 JPG. Low-hanging fruit

60% of page weight is images (pretty typical). Three optimize-image suggestions:

Reduced to actual dimensions of PNG 250px wide instead of JPG 2,048 px wide. File size reduction: 166k to 8k = 158k savings.


Convert from PNG to JPG. Reduction: 267k to 35k = 232k savings.


Convert from PNG to JPG. Reduction: 80k to 18k savings = 62k savings.

Changing those three images reduce the page weight by 452k. The original image weight total was 552k. So this reduces the image weight by 81 percent. With no loss in image quality.

Unfortunately, even drastic image changes often won’t reduce speed by half.

Free download about optimizing JPEG images >

To replace the images, we suggest Enable Media Replace plugin (200,000+ active installs).

Comments are “on.”

Emojis are “on.”

What made the biggest improvements? Cache Enabler plugin reduced TTFB from 1.35 seconds to 364 milliseconds. Image optimization did the rest of the heavy lifting.

“How good is good enough” depends upon percentage of audience visits via mobile devices. They need better speed than required by desktop visitors. Google recommends below 3 second load time. We recommended 2 seconds.

Here is our reader’s question:
“What is your recommendation for developing WP pages? Is there an editor that can make developing pages more time effective while still enabling a fast loading website?”

WordPress is adding Gutenberg editor to WordPress 5.0 core. It will change how pages are built. Study about it or test with the Gutenberg plugin.

TOP100 plugins are slowest and most bloated.

If you search the phrase “Essential WordPress Plugins,” you’ll get about 1.8 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.

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

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.

New eBook, 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