When you’re working hard to optimize a website, you learn that image file size is an important detail for speed. Many online publishers haven’t the time to learn Photoshop or other image editing programs. Automated optimizers are the next best thing and can speed your production. But which ones do a good job and how good is good enough? Big questions.
We’ve tested some nice online utilities for optimizing images, but only three stand out. These can be as frugal as optimization done in standalone programs like Photoshop. Don’t just ignore image speed issues. Sadly, halving the image weight on your home page will not make it load twice as fast. There are many other things to take into consideration. Nonetheless, image size and weight are the biggest contributors to site bloat. It’s worth your time to learn a few compression tricks.
Images are the biggest lump of sluggish web page weight. Everyone hates slow loading pages. Automated image workflow is an effortless way to improve user experience. Without difficulty, you can achieve the right balance of image file size and best quality. Optimizing images helps reduce your website visitor’s frustration.
We did a simple test of online optimizers with just two images. We weren’t interested in the nuances. We only wanted to know if the optimization tools met a minimum processing criteria. We describe our goals below under the section “PagePipe’s quick-test criteria.” Here are the two test images:
Test Banner JPEG Image
trees-rocks.jpg, weight: 122.2k, dimensions: 1024 x 300 pixels
Test Camera Output JPEG Image
wood-test.jpg, weight: 5.5MB, Dimensions: 4378 x 2916 pixels
PagePipe recommends only three web image-optimizer utilities.
Please try the 3 image utilities and see if they have value for the web file sizes you use.
DynamicDrive image results are displayed by Quality-10 increments. We liked this simple, still-image visual feature a lot. DynamicDrive had an upload size limit of 2.86MB. That is too small for images straight out of a digital camera. We couldn’t upload the larger test JPEG because it is 5.5MB. We still like this browser-upload utility best for most web work because it shows all ten results for comparison. No fiddling with controls. Visual selection is easy.
Web Resizer Results: trees-rocks
19.29k, -83% savings
wood
63.94k, -98% savings
Size limit = 10MB, 2,000px wide, Cropping or resize option.
PagePipe’s quick-test criteria.
We’re only interested in compressing photograph files. The online compressor is best if it works for two different samples: a large digital camera file and a smaller web banner. Both JPEG images. Specifications for test images are below:
The software needed for image optimization must be only the browser. No other programs or plugins; such as Adobe Air, Windows Only, Flash, etc.
We want to upload the test images by browsing or drag-and-drop.
We consider it a bonus if the browser imaging tool has an image resizing option.
The tool must work. Seriously? If it fails, it’s off the list.
We’re only interested in lossy compression for the most page-weight reduction. Lossy is a type of compression where a certain amount of information is discarded. It is best. 50 to 70 percent reduction in file size.
We prefer optimizers with reduction control in steps of 10-increment quality settings. 90Q down to 10Q range. We pushed down to 10Q for testing when possible.
The 7 random losers.
We’ll share these just so you don’t wonder if we tried them or not:
Smush
We’ve used smush before. It’s part of Yslow performance measurement tool by Yahoo! It never makes much of a difference. There are better alternatives. Many swear by this method. We don’t think it’s that cool by comparison. On the test, it failed to upload the images. We tried again – and gave up. We didn’t care that much. You only use lossy settings on the pro version. The free plugin has 10 percent reduction. That isn’t good enough.
Kraken.io
We think Kraken has potential with the WordPress plugin version. But the online browser version doesn’t allow you to make quality settings. Our trees-rocks test image only compressed by 12.4%. Unimpressive. And the larger “wood” image wasn’t allowed. They said for that size we’d have to upgrade to Pro version with an upper limit of 16MB. Forget it!
RIOT (Radical Image Optimization Tool)
For Windows only. Disqualified.
Puny PNG
FAILED uploading and gave an error message.
“Sorry, there was a problem with the image(s) you are uploading. Please ensure your image is a supported format and complies with your quota.”
Our images worked fine everywhere else? Go figure. Yes. We tried more than once.
Shrink O’Matic
Desktop app for Adobe AIR. Disqualified because it requires more than a browser.
TinyPNG – 5MB limit
Has a 5MB limit and made no difference. “Zero Percent” change on the trees and rock image.
Compressor.io
Compressor.io didn’t cut it either. trees – rocks only compressed by 24%. That’s not good enough for us. The “wood” image was better (-72%) but no resizing option. It wasn’t of much value for those big, fat digital camera images.
Slow speed is caused by images that aren’t optimized. It’s a trade-off between file size and image quality. Learn about proper image optimization. Heal the Internet.
72k, 8-page, 8.5 x 11 inch, printable b&w
There is no one-size-fits-all solution for image optimization. No common formula. That’s why robot-plugin optimization is usually too conservative and overcautious. They don’t compress enough. The human eye is the best judge of how much is enough. Every image is different in potential gain. Only optimize on your 10 most important landing pages. You don’t need to worry about every image site wide.
Even though you could squeeze an additional 200k of image weight from the homepage, it wouldn’t make a significant difference. Why? Browsers load images in parallel.
If you enjoy our caustic speed articles, you’ll love our pithy bi-monthly newsletter. Discover what matters most for mobile WordPress page speed. Fast load times require more than just installing a caching plugin – or CDN.
We’ll share with you our latest speed experiments and discoveries. Stay up-to-date with what matters for mobile WordPress page speed.
2
LEARN HOW TO MAKE MOBILE WOO FASTER 9 WooCommerce Speed Tips
1. Remove global SSL bloat.
2. Disable AJAX cart fragments.
3. Defeat minimum password strength.
4. Disable Auto-Embed script.
5. Avoid these cache problems.
6. Effective trust signaling.
7. Improve your call to action.
8. Relevant custom product photography.
9. Selective deactivation.
WooCommerce is a slow, lumbering beast. Discover 9 ways you can speed it up today.
Our controversial free report challenges a commonly-held web belief. That’s the falsehood you need an SEO plugin (like Yoast) to succeed online. Discover why SEO plugins won’t save your business and what you can do instead. And speed up your site!
Today, PagePipe uses 70 plugins. About 30 of those not updated for over 1 year. Some for many years. We’re not embarrassed about that. It’s not a mistake.
Plugins listed in our ebooks are currently used on PagePipe. And also on client sites.
So the question is “Outdated? By what definition?”
Some think outdated plugins produce a warning like:
“This plugin hasn’t been tested with the latest 3 major releases of WordPress. It may no longer be maintained or supported and may have compatibility issues when used with more recent versions of WordPress.”
Being orphaned or abandoned doesn’t mean “bad or rotten.”
These lonely plugins still work. And often for over a decade without complaints. That isn’t brokenness.
“Does 8 months since an update concern us? Not in the least. There are plugins that are 8-years old in the directory that work fine. Those “best if used by” freshness dates are silly. They throw people off with their arbitrary “expiration-date” warnings.”
WordPress places warnings when a plugin isn’t tested with recent versions. Does that mean it won’t work any more with new versions of WordPress? Nope.
WordPress’ motive is their legal protection against liability and lawsuits. C.Y.A. If a plugin doesn’t work any more or presents security hazards, it’s removed fast. And some are. In particular, malicious plugins. They call those “take downs.” Plugin authors remove some because they didn’t get the market results they wanted. But generally plugins stay as long as there isn’t any noise about them. Retired or dead author’s plugins stay in the WordPress free directory.
No plugin is safe. Not paid (premium) plugins. Not obsolete plugins. And not recently updated plugins. A common plugin problem is automatic updates loading onto managed WordPress sites. Bugs in the new version mangle the site or causes conflicts.
It happens.
There’s no such thing as a risk-free plugin or theme. Even reckless WordPress messes up with their own Automattic-authored plugins.
Good-old “Plugin Logic” is our secret, speed-weapon plugin. It’s used on every site we touch. SELECT.ME issue #11 talks about it. It’s an amazing plugin.
Want to keep a specific plugin from updating? We recommend “Block Specific Plugin Updates” plugin. There are times this is handy.
There’s plugin churning in the 55,000+ plugin database. Don’t let silly warnings discourage you. They aren’t for your protection. They’re protecting WordPress.
Don’t fear old plugins.
How many plugins is too many?
PagePipe is hosted on cheap GoDaddy magnetic servers with no CDN. GoDaddy hosting is the second most hated provider in the world. The first is BlueHost. We’re out to prove even “bad” hosting can get fast page speed. (We host our store on Bluehost! Our blog on GoDaddy!) PagePipe.com is living proof these recommendations for speed actually work.
PagePipe now use 70 plugins on the blog (GoDaddy) and 24 plugins on the secure store (BlueHost). Even with this many plugins, load time is under 2 seconds on cheap, shared hosting. It’s not plugin quantity, it’s the quality that makes a difference. Web designers can’t be arbitrary in loading and activating plugins. The result is slow pages. And all our plugins are freebies from the plugin directory.
It’s a myth using many plugins slows down your website. Being sloppy in judging plugin quality or necessity is the culprit. That’s within a web designer’s control. It calls for wisdom and speed testing. The best plugins add no page weight at all – weightlessness! (In reality, about 1 millisecond – or less – per plugin to the initial page load.)
PagePipe saw a drop in 2022 sales. The reasons vary.
Everyone did a lot of speed repair and web construction during Covid. Even overspent because of Google mandates for page-experience compliance.
WordPress versions and new block features change every week. No one can keep up with the noise, confusion, and chaos.
WIX stock out-of-the-blue dropped 80-percent last quarter. They are a WordPress competitor for online stores. An indicator of big changes for small web businesses.
Last summer, WordPress plugins saw a drop in installations for the first time ever. Weird stuff going on.
And after all the panic, Web Core Vitals never did anything good or bad. Google says, “Well, we never promised it would make a difference.” Clowns.
With war and hyperinflation chaos looming, site owners aren’t investing. Fear is in the air.
But this is the time to change and invest in yourself and your web business. Why?
Would you believe Warren Buffet (an excessively rich old guy) says it’s a good strategy during hyper-inflationary times?
14:20 minutes 1,480,131 views Jan 31, 2022 The video explanation is simple. There are two ways to invest against inflation. Increase your earning value by leveraging your position as an expert. And owning a non-capital intensive business. Like selling digital products.
Pagepipe fixes the nastiest sites around the globe. Most are sites getting horrific load times — like 10 to 30 seconds. Not a good user experience. Why do you need to fix your slow site? Because everyone hates a slow website. Our goal is a 2-second page load time on desktop browsers. And a 3-second load on mobile devices.
When times are hard, often the right thing to do is something counterintuitive. That means to reach out from the inside, rather than doing what most salespeople do – pound from the outside.
When sales drop for WordPress services, a business might attempt an emergency sale.
We did the nonsensical opposite. We raised prices on our tuning services. We offered more speed ebooks and plugin products. That illogical and unreasonable change worked. It saved our bacon.
Counterintuitive strategy is not following the fearful herd — but proactive action. Invest now to restore your site to health. Achieve faster page loads. Be kind to your visitors.
Selective activation of plugins is a favorite strategy for speeding up WordPress websites. Now you can use plugin skills to speed up WooCommerce e-commerce sites – without coding!
Selective activation in a nutshell:
Many plugins slow down every single page on your site, even if that plugin is only used on specific pages. That we call site drag – or global loading.
For example, installing Contact Form 7 plugin adds 37k of weight to every page. Even if you only have one page with a contact form. Or for that matter, no CF7 shortcode used anywhere. Weird unpublished specification. But lots of plugins don’t tell you the speed cost of adding their plugin. It’s not required for plugin submission. Summing all plugins site drag is the aggregated plugin overhead – a liability.
Selective activation speeds up your website. It allows you to deactivate a plugin where it’s not needed.
WooCommerce is the most popular e-commerce plugin for WordPress. It’s clunky and one of the slower-loading plugins we’ve tested. It adds at least 250 milliseconds of unneeded global weight – and slowdown your site.
Before August 2019, attempting WooCommerce selective deactivation resulted in the white screen of death. Yes, it would break your site. But a plugin code revision changed that. And it is now possible to selectively activate WooCommerce. Thanks, Automattic!
Below, we show you steps to speed up WooCommerce using selective deactivation. You can use a control panel to make the magic happen. Entering the page or post URL activates or deactivates any plugin you choose. You can turn extra drag off-or-on for specific pages or posts on your site.
SpeedSwitch Plugin
SpeedSwitch is the exclusive PagePipe plugin we use for this job. It’s available for purchase through SpeedHospital.
1. Install SpeedSwitch
After downloading SpeedSwitch, install it by uploading the zip file from your computer.
Click to enlarge.
Click to enlarge.
2. URL Set-Up
Find the plugin settings in the “Plugin” sidebar menu. You’ll see a list of your activated plugins, a radio button for active/inactive and a box to add URLs.
Scroll down to the WooCommerce plugin. We want Woo to remain active by default, so select “Inactive on,” then add the URLs where Woo is not necessary. In our example, that’s the homepage, blog archive pages, about page and a few others.
Click to enlarge.
Click to enlarge.
3. Test Results
We use SpeedXRay to assess the speed overhead of plugins (and themes). Here are the example results from our test site.
WooCommerce is the heaviest plugin on the list. It’s responsible for over 20% of the cumulative plugin load time.
Deactivating other Woo-related plugins will save over 300 milliseconds.
NOTE: Free Disable Cart Fragments plugin isn’t in the WordPress plugin directory. But you can get a bootleg download link from us. Sign up for the free WooComa download below. We include the link in the PDF content.
EVEN BETTER
https://wordpress.org/plugins/disable-cart-fragments/
In-Browser Timer Test Results
SpeedXRay is a useful speed-assessment tool. But real-world load times are what count most. Here are speed results from our in-browser timer test:
With WooCommerce: 1.4 seconds
Without WooCommerce: 920ms
You can save about 500 milliseconds by deactivating the WooCommerce plugin. That’s significant when you’re aiming for sub-2-second load time. It’s 25 percent of your performance budget.
About the Author Matt Stern is a web designer and sometimes writer based in Southern Oregon. He designs and builds websites and landing pages that convert visitors into customers.
Where is “above-the-fold” on a phone or desktop? Repairing render-blocking is wasteful ivory-tower foolishness. Not a real-world problem. But the anxiety sells lots of speed services like CDN and paid plugins.
Removing render-blocking elements like Font Awesome frequently breaks the hamburger menu and search magnifying glass and social icons, etc.
Are we saying that trying to eliminate render-blocking resources as identified by GTMetrix (and similar speed metric software) isn’t productive, useful, or a ‘real-world problem’?
That is correct. It is a waste of time and energy.
Anything that reduces resources should be considered for removal – but how good is good enough? Load times under 2 seconds are good enough.
PagePipe doesn’t chase render-blocking. It is sold by speed scammers often.
Render-blocking resources are only considered because there is a theoretical concept called: above the fold. Where is that exactly on a mobile phone? Abstraction!
Render-blocking is usually not important.
Who are these people creating wasteful test criteria? Steve Souders coined the term “web performance optimization” in 2004. He started the criteria for web speed for Yahoo Performance group and later Google PageSpeed insights. He no longer works for either company. He now works at SpeedCurve.com.
Who else are these speed experts making the test requirements?
No one ever knows. “Invisible people” get to dictate what is good and bad. Does it solve or cause real-world problems? We have seen no documentation that proves fixing render-blocking is a worthwhile real-world practice for small- to- medium-size businesses. It doesn’t change UX, SEO, or profitability. It’s like bragging, “My music system reproduces music flawlessly beyond the range of human hearing.” If you can’t hear a change – so what? Who cares?
Perfect is not practical.
PagePipe practices the Pareto principle and industrial value analysis. 80 percent of the speed effort only yields 20 percent improvement. We look for the 20 percent that will give 80 percent improvement. Render-blocking removal falls in the esoteric.
Font Awesome render-blocking should be avoided during website construction – but if it gets inadvertently built-in. Do not remove it. Doing so causes problems for most sites. We try to avoid themes that use Font Awesome – always.
A freelancer on Upwork offers speed optimization. He has excellent reviews. He also has multiple recommendations from Facebook groups. He has an impressive profile and offers a guarantee of 95+ on the Google PageSpeed insight test.
He claims the following techniques increase the speed of websites:
Time to First Byte
Unused JavaScript and CSS removal
Image optimization and webP implementation
Render-blocking script and above the fold optimization
CDN and Cloudflare implementation
Cache implementation
How can he guarantee 95+ speed optimization only US$30/hour?
Simple. He’s a scammer. We don’t recommend any of those methods.
The first clue of a scam: TTFB is hardwired into the server’s physical properties. It can’t be easily fixed. But few know that.
All these wonderful scam specs make no difference in SEO, UX, or profit.
Measuring with Google PageSpeed Insight test scores are not an indicator of a speed professional. Those are tools used most by pretenders and wannabees. Sorry.
Competitor Analysis
How is PagePipe different from WP Faster WordPress optimization services?
Glad you asked. WP Faster optimization services sound great. While the market stats they quote are true for big companies – they’re irrelevant for our audience. We work with small-to-medium size International web businesses.
People visiting PagePipe need a speed doctor. They know it already. We don’t have to do any convincing of speed benefits. WP Faster wants speed converts. Our audience already is made of speed evangelists. We suspect WP Faster produces similar performance results in the end … but you pay double to triple the cost. The sky’s the limit with their pricing.
So the price is a big difference. But our speed philosophy is different, too. We use the Pareto principle – 80/20 rule – as our guide. This is value analysis. Or cost-benefit analysis. We discover unrealized speed improvement opportunities.
Not everything is important or makes a significant difference in speed.
Anything you want that isn’t The WP-Faster way voids their refund policy. They, also, specifically say they “don’t teach how to do what they do.” We teach. Our goal is technical obsolescence. We want you to understand how to fix speed yourself and avoid future problems. WP Faster won’t even talk to you on the phone unless you pay a $6,000 deposit.
What WP Faster says confuses. They have abnormalities and contradictions in their FAQ section. For example:
WP Faster requires a mandatory installation of the $200 per month Cloudflare plan. They say not using Cloudflare voids their warranty. What warranty? And what host do they recommend? The speed-despised, $35-per-month SiteGround hosting!
PagePipe makes your site fast on your existing shared hosting without CDN. We don’t add costs using extra affiliate services for kickbacks. We reduce your annual overhead.
The flimsy WPFaster.com pseudo-guarantee:
“The sale is final, even if we were, through no fault of our own, unable to install, in full or in part, the performance architecture we have devised for your site.” – WP Faster
They repeat over and over: no refunds. With legal ferocity and verbosity.
Do better UX and speed improve profits?
It’s documented proof for BIG companies. But will it help you? That depends. Are you selling something perceived as good? If the answer is, “No, I sell rubbishuseless unwanted stuff.” Then don’t waste your time tweaking speed.
But, if your offer and content are good, speed helps. Faster load times make visitors happy. No waiting.
Speed Band-Aids and Quick Fixes
Build with Empathy – GIVE SPEED
Many WordPress speed optimization services charge too much for applying band-aid fixes to slow sites. They promise improved test scores. But not guarantees of improved load time gains in milliseconds. Test scores are esoteric tweaks that make no significant difference. The test results recommend score improvement with technical services such as:
Leverage browser caching.*
Use a CDN (content distribution network).
Plugin prioritization and load order.
Remove above-the-fold render-blocking.
Lazy loading images.*
Minification of HTML, CSS and JavaScript files.*
Improve server response time (TTFB).*
This list above is one of minor improvements. We do some of them* but only if it doesn’t break your site – or cost you an arm-and-a-leg in custom coding.
Now don’t get us wrong, some scores help site speed. We use these techniques from time to time. But there are glaring wasteful issues when using quick fixes:
Because scores are superficial, real speed gains are often unrealized.
Speed gains don’t last because site owners aren’t taught the root causes of slow site speed.
Band-aid plugin fixes are easy to do yourself (and often free). Don’t waste money.
Substitute popular WordPress plugins with low-cost, faster alternatives. Get super performance, free price tags, and no annual renewal charges (plugin rent).
Using the Pareto Principle (or 80/20 rule), helps us make your site leaner and faster. We discover unrealized opportunities.
Want a 100 score on Google PageSpeed Insights? WordPress themes won’t pass those silly speed tests.
We’ll propose a speed strategy and then, with your approval, we’ll do it.
Installing WP Rocket caching plugin – and charging suckers $100 for that is not a service. WP Rocket is a plugin you can buy for $49 annually. But speed tricksters don’t pay that price.
They buy all-you-can-eat “unlimited installations” of WP Rocket plugin. That has a special $199 price tag. Meaning: it costs them almost nothing per-site installation. The client-gotcha is this: a scammer doesn’t pay for future annual renewals. This leaves the client holding the bag the next year.
WP Rocket homepage
These frauds list each automated feature of WP Rocket plugin as a separate ala carte service item. This deception is snake oil.
These overpriced practices don’t produce minimal load time improvement. They give real speed professionals a bad reputation. If you think marking up a mere plugin installation is a good business strategy, have mercy! Don’t do this to site owners. It’s a ripoff.
Competitor WordPress Speed Optimization Services
Eight common observations of speed-service competitors:
1Prices start low. Typically around $100. The high end is around $1,000. But many insist on bidding services and won’t give a fixed price. For some fees, the sky is the limit. Or they insist on expensive add-ons increasing the annual site break even. They usually get an affiliate reward for pushing clients toward these extra services. These are things like:
paid plugins
paid themes
paid services like CDN
special hosting
2All 35 homepages have a title saying, “WordPress speed optimization services.”
But one said, “Turn your slow WordPress site into a supercharged powerhouse.” Better promise but still not quantifiable. Unprovable claim. “Optimization” sounds like a jargon buzzword. They don’t have a motivating benefits-oriented headline.
3 Tons of rocket logos. And the *second-place* cliche logo is a timer or gauge.
With flames, of course.
4The slow irony. The page-design quality of these speed optimization service’s websites is fluffy and low credibility. Lots of popups and chats. Most sites advertising speed services – actually load very slow. We list the initial load time of each one below using a browser timer. Not “walking the talk” is evidence of inferior services.
5 They don’t teach speed strategy. They just do site tune-ups. Hands – but not shared brains. You don’t get consultation or education.
6Competitor services focus on Google PageSpeed Insight test scores. Improving scores doesn’t necessarily improve speed. We’ve seen pages that get all-green 100 scores that load in 12 seconds. Crazy slow!
The only performance metric that counts is improving speed in milliseconds. Not a cached speed. We’re talking about unprimed cache. That’s a first-time visitor’s experience. That’s what counts – first impressions of site quality. Some speed competitors focus on reducing the number of requests a page calls. They consider that a good-enough metric indicating speed improvement. Again, request reduction doesn’t guarantee improved load time in milliseconds. Vanity scores and requests are secondary compared to actual load time in milliseconds. The goal (performance budget) is loading a real page in under 2000 milliseconds.
7Bait-and-Switch Tactics They attract potential customers by advertised low-priced items. But then encourage buying a higher-priced speed option. Nasty!
8Bogus SEO promises.
Speed service competitors in error claim speeding up a website improves SEO. There’s only a 0.5 percent benefit in page ranking algorithms from speed. Google speed mythology is not a valid reason to spend money on speed. The better reason is providing an excellent user experience. Speed is the primary and principal component of UX. Everyone hates a slow website. Speed is about the halo bias caused by a visitor’s first impressions.
pagepipe-ebooks.com – 750 milliseconds – $500
There are at least 8 noteworthy WordPress speed service competitors:
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).
Barely. While Google pays lip service to speed, it clearly isn’t a major concern. They send out mixed messages about speed’s importance. The most notorious third-party widgets slowing down websites – other than Facebook social links – are Google’s Cloud-based API services, Google Fonts, Google Maps, Google Analytics, Google Adwords, etc. Most modern WordPress themes incorporate these things. Research studies show that speed affects Google page rank by less than 1 percent. Insignificant. What improves SEO most? Plain and simple: relevant content. Relevant to who? To people trying to solve problems!
2Fast websites enjoy high conversion rates and a healthier bottom line.
Really? Then, where’s the long line for speed optimization services? Where’s the market pain?
There is evidence speed makes a significant difference in profitability for very-large, big-name sites – like Amazon, Ebay, Mozilla, and Apple. For most low-traffic sites, there is no measurable monetary gain. What does change is visitor perception of how credible website content might be. This is first impression or UX. Speed is a subconscious indicator of someone valuing content enough to deliver it quickly and efficiently. It’s the opposite of apathy and bloat. It’s web hospitality, etiquette, and caring.
3Running a successful website starts with choosing a good host. Hosting makes a difference in SEO.
Baloney! Wrong again. Hosting may add conveniences and security for site management. But speed is dependent upon optimizing and limiting the number of website components. Hosting can make a difference in Time-to-First-Byte (TTFB). This is the parameter Google uses in it’s search algorithm. But we repeat, TTFB only influences SEO by less than 1 percent. Is special, costlier hosting really benefiting SEO? No. Remember, content relevance is more important – always! The average web page now weighs 2.3 to 3.0 megabytes. It doesn’t matter how long it actually loads for SEO. It does make a difference in how frustrated a site user feels. The upper tolerance seems to be 2 seconds. Even though the average page load is now 8 seconds. Horrible! Those load times have nothing to do with hosting and everything to do with extravagant and out-of-control developers and designers.
4Caching WordPress is so effective that it can result in a 10x speed gain over a non-cached website.
Hogwash! The reason web builders see improvement from caching plugins isn’t from caching features. It’s from the activation of Gzip compression, far-futures expiration, and minifying Javascript and CSS files. Those extra features have little to do with caching. In fact, most modern hosting has already activated Gzip server-side. On a well-optimized website, we’ve rarely see benefits from caching plugins – such as the oft-recommended, free W3 Total Cache plugin. Or even WP Super Cache. Both very popular plugins with millions of installs. They are the emperor’s new clothes. Only a small percentage of your site traffic benefits from caching. This is usually around 20 percent returning visitors.
5Too many plugins slow down your WordPress website.
Bogus information! How many plugins are too many? We’ve installed over 70 active plugins on websites that load in under 2 seconds on shared hosting. Not all plugins are created equal. Sure some will slow down your website – especially if they call offsite using third-party Javascript. Facebook real-time social links are the worst offender for slowing down a website. Why include this unprofitable baggage instead of using a static image link or CSS text link? Craziness.
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 WebPagetest.org (also owned on-the-down-low by Google). This comprehensive test is open-source, free and tells a more in-depth story. Our second favorite speed test tool is Pingdom.com.
7Google says I need to have a performance goal of 400 millisecond page load times.
Google is full of idealistic waste matter. The average load time today is 8 seconds. That is bad but there are many slower sites. Most website-optimization professionals agree a 2-second load for WordPress is doable with good optimization discipline. That is our goal. The saving grace is user-perceived load time – not actual load time.
8Content Delivery Networks (CDN) always speed up load times.
Really? 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.
“A single YouTube embed can load up to 400KB of data before you even hit the play button.”
Is a 2-second differential important? Not if your target is an average 8-second page load.
It’s not really about measuring speed. It’s about human attention span and expectation. 2 seconds is the sweet spot for page loads (today). But one second feels seamless. User experience is then optimal.
If you want excellent pages (we mean in the top 1-percent quality range or under 1-second page loads), you have to take the video into consideration. What if a form is also on the page? And there is HTTPS/SSL? Then videos just add to the speed overhead.
Howgood is good enough is always a compromise. Can you get 2-second load times on shared hosting? Yes.
Speed is just a feature. Make your website fast and useful, too. If it’s not useful, who cares if it’s fast.
Average load time for mobile sites is 19 seconds over 3G connections.
Do website owners have anxiety about a half second? Yes. That’s a major problem (they think). But not for someone on a desktop with fiber connections.
Lazy Loading YouTube or Vimeo videos
Set up a Youtube account to host your videos. Place the YouTube link in your page or post body text. You don’t need to move video down the page. That isn’t necessary. Lazy loading videos occurs anywhere on the page. It doesn’t have to load below the fold. It’s different from lazy loading still images like JPEGs or PNGs.
We experimented with Lazy Load for Video plugin. We like the plugin. But have found it can conflict with other plugin’s shortcodes on a page or post. Sadly, it doesn’t work with Elementor page builder.
Using the Lazy Load for Videos plugin can save 500 to 700 milliseconds in page load time. Studying plugin blog reviews about the Lazy Load for Video plugin, we learned the following about the settings:
There is an option to load CSS/JS only when needed. It should improve the load time. It is not declared but is apparently a minification technique since the blog author warns that it could break the site. Just like any other minification plugin can. If so, we just deselect the option.
Responsive Mode: It is recommended.
Play Button: The author gives 5 different options. We prefer using the one with the most “YouTube-looking” interface. But it’s not the fastest. “CSS only” setting means code is loaded (faster) because there is no image to load. We don’t know if the speed gain would be significant.
Thumbnail Size: It can be set to “Standard” or “Cover.” We couldn’t tell any difference and used “cover.”
“Update Posts” button at the bottom. The blog review said, “If you are having trouble seeing your video change then you probably need to click this button. Especially right after configuring the plugin for the first time.”
If should be labeled, “always push this” instead of “if nothing is wrong” push this. We suspect it’s some kind of purge of cataloged pages or posts (like a cache or database).
After installing, we did have trouble with plugin activation on some videos. We clicked the button and it fixed the problem. We knew nothing about this button’s purpose. It isn’t mentioned in the plugin read.me documentation!
One thing we’ve found is an option to “Hide-related Videos” with a checkbox. This sounds like a good thing if you don’t want to send viewers off to watch competitors YouTube videos. This function is available in Elementor’s video provisions, also (see below). Update: Google removed the ability to turn off recommended videos. There is a workaround to only recommend videos on your YouTube channel. So plugin authors are in process of reworking how to suppress taking visitors away from your site. More on this as news develops. You should still do lazy loading of videos for speed.
End of YouTube video attempts to entice visitors away from your site. Sometimes to competitor sites. Bad! Defeating this *non-feature* is an option with the Lazy Load for Videos plugin. There are other methods but we’ve found this the simplest way to keep visitors engaged with your site content.
The Lazy Load for Videos plugin read.me file claims videos on posts and pages are both activated.
Of interest:Jetpack by WordPress.com offers an extension called Shortcode Embeds. It makes Lazy Load for Videos break. The cure is simply to disable the extension. Or like us, don’t use Jetpack! This is a known issue published in the read.me file.
BEFORE: Lazy load for video plugin installed. The test page has 13 one- to seven-minute duration videos. Pingdom is a best-case scenario. Load time is 3.15 seconds. Using WebPagetest.org, the test page loaded in over 7 seconds (worst-case).
AFTER: lazy load for video plugin installed. Same test page. Pingdom is a best-case scenario is now 1-second with an unprimed cache. With cache, page load is 853 milliseconds.
We’ve also found this good lazy load plugin:
★★★★★ Lazy Load XT
Active installs: 3,000+
Zip file size: 29k
The plugin author claims this is the fastest and lightest lazy load plugin in the WordPress Plugin Directory. You can lazy load images, YouTube and Vimeo videos, and iframes. We’ve been testing it for several months and find it a good alternative when the other Lazy Load for Videos plugin conflicts with other plugins. We find this a common problem and it explains the low retention rate. Lazy Load XT appears a little slower in the view screen when loading images and video. It uses a fade-in method. This plugin does work with Elementor page builder.
Both plugins enqueue jQuery, a negative effect for speed. If your theme isn’t loading that JavaScript library, we recommend selective activation of these plugins only on the pages where needed. This will keep your site running fast. Also, use Instant jQ to keep things fast.
Here’s a comparison on a bare-bone GeneratePress theme with Gutenberg page-builder plugin – and a YouTube video embedded.
NOTE: If you use a page builder like Elementor, Lazy Load for Videos will load but doesn’t work to reduce load time. But LazyLoad XT, works fine. Go figure. Both work with Gutenberg.
No lazy load baseline.
Page load time: 1.5 seconds. Page weight: 720k. The video weight is 526k – 72 percent of total weight.
Page load time: 691 milliseconds. Page weight: 724k. Using Elementor instead of Gutenberg as on other tests.
Even though LazyLoad XT and BJ Lazy Load are faster loads, their page weight and bandwidth consumption for mobile are 7X higher. This makes Lazy Load for Video plugin more attractive for a mobile experience. All these plugins video preview and play button are scalable and optimized for mobile devices.
Lazy Load for Videos plugin is our preferred plugin between these two. Both work and if one has a conflict – try the other one. You can use both these plugins with selective activation if your posts have shortcode conflicts. We prefer the UX behavior of Lazy Load for Videos.
If you activate both plugins simultaneously, Lazy Load for Videos will take precedence since it loads first. Page weight is increased by these plugins. Both plugins load globally. Loading an embedded YouTube video without lazy loading doesn’t enqueue jQuery. But this small gain is swamped by the huge video load time.
There’s not too much overhead for a single video. What happens when you have a video library or a blog with multiple videos?
YouTube loads a number of files (8 requests) with each iframed video. Web pages with multiple Youtube videos slow down due to these multiple HTTP requests and downloads. Preventing or delaying embedded YouTube video player loads is the speed goal.
The fastest websites have no JavaScript, no CSS, and require no database calls. YouTube does all this and preloads third-party ad stuff you’ll see at the end of the video (related videos).
Video-loads slow a page down by a half-second typically. It’s only a big deal if a half second is important to you. Our goal is a 2-second load time. If you put a video on a home page, boom! Potentially, 25 percent of the performance budget is shot.
One example is the very video page where you saw the robots. Before plugin: 3.15 seconds. After: 1.03 seconds. Supposedly, it should be worse – but caching seems to help YouTube somehow. There are 13 videos on that page. Do people do that cramming? Yes. A video library page is a common practice.
LAZY LOAD YouTube VIDEOS WITH ELEMENTOR
This is a basic widget. It’s included. No purchase necessary.
Elementor basic widget for adding video to a page.
Image Overlay section: Find it at the bottom underneath the video section. (It’s practically hidden. Scroll down to the end of the Elementor video section)
Image Overlay at bottom after scroll.
Settings
Image Overlay: Select Show
When Image Overlay is set to Show, the following options become available:
Image: Set your static overlay image from the media library (an optimized JPEG you choose).
Lazy Load: Set to YES.
Image Size: Set to full.
Play Icon: Slide to YES to show a Play Icon (triangle in circle)
Lightbox: Leave off.
This defers loading of video resources until the user clicks the Play button. Lazy load replaces the video embed code with a lighter weight static image of your choice. And an optional play icon on top of the static image. The video is only loaded when the user clicks the image.
This speeds up the initial page load time by 500 milliseconds (typically per video on a page).
Note: Videos will not autoplay if an Image Overlay is set. You don’t want autoplay anyway. It’s considered intrusive and bad user experience. Let the user choose to activate the video sound and play.
From surveys, the top three biggest challenges for WordPress users are: 52% performance issues, 41% security issues, 35% site-breaking updates. NOTE: These are all fear related – not reality related.
Choosing a plugin would be easier if WordPress permitted a little more repository information. Author-generated advice is untrustworthy because it’s biased. Popularity (number of installs) is, also, a lame indicator. Newer plugins sometimes are better. We can’t search on freshness.
We seek indicators of credibility (which is composed of expertise, trustworthiness, and leadership). These findability cues are sometimes referred to as information scent. These things are inferred in the plugin repository – or are discovered by downloading. They include:
1. Download file size. This is a potential indicator of plugin efficiency. Not always but frequently. If we have alternatives, we recommend the smallest plugin package to avoid bloat. Why doesn’t WordPress just tell us file size before downloading or having to click? Editorializing download links is considered polite and good web etiquette.
2. Date of first approval or submission. Longevity in the market is an indicator of credibility. At present, we either must open the download package and examine the readme.txt for a change history – or figure it out in the repository by compatibility to the oldest version of WordPress. Like a reverse-lookup. Do we have to use Wikipedia? That still doesn’t really tell first-release date of the plugin.
3. Similar or newer plugins should be listed as linked options. Popularity doesn’t always mean “best.” It may just mean old or antiquated. Inference from similar plugins (if listed) helps cue us for plugin usage and adaptation (workarounds).
4. Does the plugin require a signup or registration? In other words, is it bait?
5. Does the plugin interrogate an offsite database or cloud information? This is an indicator of slower load times (page speed) and HTTP requests.
This information and more would make for better productivity using the repository. There isn’t enough information when making choices.
There are a few other things we’d love to see. But we’re being idealistic in our wish list. These include answering plugin questions such as:
Does the plugin have hidden non-features? For example, some image optimization plugins have limitations of image-conversion quantity. The repository says nothing about it. Nor does the readme.txt file. You must install first to find this bugaboo out.
Are there known incompatibilities or conflicts with other plugins or themes? Sometimes authors only reveal this in the readme.txt file. That wastes our time.
Does 8 months since an update concern us? Not in the least. There are plugins that are 8-years old in the directory that work just fine. Those “best if used by” freshness dates are silly. They throw people off with their arbitrary “expiration-date” warnings.
Plugin quality can’t be judged by “last updated” any more than “active installs.” Perfectly good plugins appear artificially abandoned in the directory. Most don’t need updating EVER unless they break. They’re evergreen plugins. And should they break, they’re removed by WordPress. We use 8-year-old plugins without problems.
Age isn’t an indicator of low quality. Ask my wife. –Steve Teare
Plugins are backwards compatible. Until you install PHP7 or Gutenberg then they must be verified by the site owner. Gutenberg’s predicted to break 15 percent of all plugins (per Automattic core developer blogs). That includes paid plugins. They aren’t exempt.
This is one reason why it’s important to install “Disable Gutenberg” plugin today.
The plugins causing bigger problems are recently updated with bugs in them. They can unexpectedly nuke an entire site. Old “dormant” evergreen plugins are safer than “fresh” plugins that churn weekly – like some page builder plugins and SEO plugins. This is historical fact. Those plugins cause problems for 100,000s of site owners. Do they recover? Of course.
There’s no such thing as a risk-free plugin or theme.
Some sites we evaluate for speed testing are using free Cloudflare CDN services. A CDN (content distribution network) is a way to get servers geographically closer to the user and thus reduce latency. That’s the goal anyway.
Cloudflare is a US-based website performance company founded in 2009. Cloudflare claims to improve page load times and performance.
In the recent past, we’ve used free Cloudflare CDN services and their plugin to bulletproof our WordPress websites. Testing, we found Cloudflare doesn’t guarantee consistent load speeds. We saw an unpredictable and random page load times from 10 to 25 seconds. That’s unacceptable even if the average time is one second.
Typical server error message presented by Cloudflare after connection failure. Makes it sound like the blame is your fault. Excuses. Wrong!
Cloudflare uses a modified version of NGINX – a key Russian-created technology. Nginx (engine-x) is an optimized open-source server software used in the LEMP stack (Linux, Nginx, MySQL, and PHP).
We first thought there was traffic congestion on the shared hosting server. We checked using yougetsignal.com and found only three domains resided on the shared server. One was inactive and the other two had benign, low-traffic content. The server wasn’t our offender.
After plugin testing, it was clear that Cloudflare was the culprit throwing in random delays. We canceled the account and removed the plugin. Then things stabilized. We also got better speed test results in WebPagetest.org. Our cached time improved from 750 milliseconds to a 500-millisecond load. We’re giddy from this discovery.
We’re against any CDN paid or free services. Build with origin optimization. Then there’s no or little benefit from edge optimization. CDN is a band-aid for sloppy site owners. You can’t speed up a site that’s already fast. It’s a waste of money.
One more bad thing about Cloudflare CDN.
Cloudflare’s Nginx servers cause failure on time-to-first-byte measurements (TTFB). Usually shown as a red “F” as in failure or flunk using WebPagetest.org. This negative flag generated a brouhaha, and Cloudflare responded with a special blog entry about the topic and why they think it not a real problem. We agree. TTFB isn’t a problem. Cloudflare flakiness is the problem.
Cloudflare’s claim is “Gzip compression of web pages reduces the time it takes a web page to download, but the compression itself has a cost. That cost causes TTFB to be greater even though the complete download is quicker.” But only on Nginx servers. Apache servers are just fine.
Nginx waits until compression has started before sending the HTTP headers; when compression (Gzip) is turned off it sends the headers immediately. Nowadays, all files are Gzipped for speed.
Our complaint: Who cares about TTFB when Cloudflare throws a monkey wrench into the running engine and randomly gives 10- to 20-seconds page loads? Hiccups aren’t acceptable.
Our experience is Cloudflare CDN is notorious for slowing down your site with 500, 501, and 520 server errors. That’s probably where your TTFB errors are coming from. Cloudflare uses NGINX servers instead of Apache. This causes the lazy loading of all Gzip compressed assets. Unnecessary delays. TTFB is the only metric Google uses in its SEO ranking algorithms.
Using Cloudflare would explain the reason for your speed fluctuations. We do not recommend them – nor any CDN for that matter. CDNs are band-aids for poorly optimized websites. It’s better to build quality into your site. That is called origin optimization. CDNs are edge optimization strategy.
Cloudflare ran a test and concluded that time to first byte (TTFB) does not matter. Except, it absolutely does. As they say: if you’re experiment contradicts intuition, check your experiment. —Ilya Grigorik, Web Performance Engineer at Google
“When you put a CDN in front of your website, it will add latency to the TTFB of your dynamic content. Accessing the origin server directly is faster than routing traffic over a CDN. The CDN will improve performance for cacheable elements, but a dynamic page will have to be fetched from the origin server no matter what.” – OFFSITE RESOURCE
You know you need a web host, but you feel overwhelmed by all of the choices available to you?
Are you wondering how in the heck one chooses a super fast host and at a good price?
Here’s the deal…
The web host you choose is one of the most important and early choices you must make to get online.
We want to help, so let us share our somewhat checkered past with web hosting companies. We hope that what we share in this article helps you make an informed choice for your web hosting needs.
Domain names are purchased from a domain registrar, which is an accredited company that allows you to buy and register domain names.
Early in our online career, it just made sense to buy our domain name and hosting from the same company, so we did from Namecheap.
We found Namecheap to be an excellent domain registrar with reasonable prices. The customer service was 24/7 live chat.
They were nice and helpful.
As for the hosting, we were new. We had no understanding about or expectation of site speed or even what a web host’s ultimate responsibility is to a website owner.
But at the end of the first year, we decided to leave Namecheap web hosting in search of a “better” web host.
And do you want to know why?!
Well, we were running a WordPress website. And all of this website stuff was foreign to us and we needed a lot of hand holding — we mean support — on all fronts.
And at the time, Namecheap’s hosting was a new offer for them and their WordPress support was just less than stellar. So we hit a wall. We needed more and they could not deliver at the time.
So after the first year, we decided to keep them as our domain registrar and move on to a “better” host.
Lesson: Choosing a web host needs to be a thoughtful decision. Don’t be lazy and take the easiest path.
InMotion Hosting: Were They “Better?!”
After doing much research, we decided that the “better” host for us was: InMotion Hosting.
They “claimed” to be WordPress experts.
They had not only 24/7 live chat, but also 24/7 phone support.
For a still relatively new owner of a WordPress website, 24/7 phone support was sweet music to our ears.
And at first, all was well. We were happy. And boy did we use that 24/7 phone support.
But can you guess what happened?!
Well, it came to an abrupt end when John, a InMotion Hosting customer service rep, rudely informed us that helping us with our WordPress questions was, well, not their concern.
It was his insulting tone.
We felt stupid and we were upset enough to call InMotion Hosting back and ask to speak with a supervisor. To the supervisor’s credit, he apologized for John’s poor customer service. And then, said, “There are always going to be customer service reps that aren’t quality.”
He’s right, of course. We understand that, but it did not make us feel confident or “better.”
So before the year was even up, we were searching for a “better” web host again.
Lesson: Customer service can make or break a web host.
SiteGround: But Aren’t They the “Best?!”
So after we left InMotion Hosting, we landed at SiteGround.
They offered web hosting at a very sweet deal of just $70 a year for the first year — actually, you could lock in this sweet deal if you could afford to pay for three years up front. Truth is, most beginner website owners don’t have a clue where they will be in three years, so that’s an unrealistic commitment.
We did have the good sense to ask about what the pricing would be after the first year. And we were told, “Not to worry. There are always coupon discounts.”
Plus, they had 24/7 ticket support, 24/7 live chat, and 24/7 hour phone support. All this potential hand holding was a dream.
Plus, everyone – everyone – loves SiteGround.
Plus, everyone online shared how super fast they were. Everyone.
Honestly, they seemed like a web host made in heaven.
Until…
The first year ended and our web hosting was up for renewal. This is when we got the sticker shock.
Coupon discounts?! That was a total lie. (To be fair, nine out of 10 web hosts give you a sweet first year deal.)
Our annual budget for web hosting went from $70 to $240. That’s a lot.
But we were still clueless (and lazy) about how one chooses a good web host.
Why?!
Because we had absolutely no idea how you even begin to choose a new host after you’ve been with the “best.”
So we stuck around for another year, paying their inflated web hosting prices of $59.85 every three months. That’s $19.95 a month for their Grow Big hosting plan.
This all came to a screeching halt, when they jacked up the price to 89.85 every three months. Now we are up to $29.95 a month. Interestingly enough, their website says $24.95/month for the Grow Big plan, so why did charge us $29.95?
But here’s what added insult to injury…
SiteGround’s proprietary Client Area and Site Tools are provided to new customers, while many of their old customers like us were still stuck using cPanel, the standard web based control panel many web hosting companies use.
We ask you this…
How fair is it to jack up the price from an already over inflated $19.95 per month to a ridiculous $29.95?!
And how fair is it that this price gouge happens to old, loyal customers, who SiteGround still haven’t migrated to their new Client Area and Site Tools a year after it was first rolled out?
Our wallets could no longer handle the steal and our self-respect made us get busy looking for a new web host again.
SiteGround can’t be the only “great” web host, right?!
There are two things that SiteGround is known for: Speed and Customer Service.
On the subject of speed, here is what SiteGround promises: “Our hosting platform is built on Google Cloud and uses its ultra-fast network and SSD persistent storage.”
Sounds nice, right?!
And along with caching implementation on their servers, they also provide a proprietary caching plugin called SG Optimizer.
But we were not convinced that SG Optimizer provided any meaningful speed boost.
Plus, like most caching plugins, it is not an easy plugin to configure. And it’s implementation on our website was never a smooth experience. So we deactivated and deleted it.
In fact, we go so far as to say that a lot of SiteGround’s server caching optimization tools were disconnected from each other — at least for the average website owner.
We would accidentally discover yet another server-side caching option that required manually flipping a switch even after talking extensively with a customer service rep about website optimization.
We think that if you are a web host that prides itself on being super fast, shouldn’t your server speed optimization tools be cohesive and intuitive for the average website owner?!
Fair question, don’t you think?
And on the subject of customer service, here’s what SiteGround has to say: “Our Customer Care team is among the highest-rated support squads online, fast, multi-skilled and helpful.”
Here’s what our experience has been…
Of all the web hosts we had tried to date, SiteGround was the most proficient at providing support on WordPress itself.
And, honestly, they were really nice and usually super helpful. They would actually offer to complete many site changes on our behalf.
But towards the end, the accuracy of the support was sometimes suspect and, at $29.95 a month, that seems unforgivable.
We think you deserve consistent, accurate information from web hosting customer service reps, especially at SiteGround’s price point. Don’t you?!
Lesson: Don’t believe the hype. Dig a little deeper and test for yourself.
Tip #2: You want a web host that is committed to security. Yes, while there is much you can and should do from your end, website security begins with your web host.
Tip #3: You want a web host that delivers 99.9 to 100% uptime. Because a down website can reduce your bottom line.
Tip #4: You want a web host that allows you to edit or write to your .htaccess file, a critical configuration file. You just might need to do that someday.
Tip #5: You want a web host that provides 24/7 customer service. These days, with the right web host, ticket support and live chat are just as good as phone support.
Tip #6: Don’t automatically install caching plugins, even proprietary ones from your web host. As with all plugins, please do your homework. Test your site speed BEFORE and AFTER installing any plugin.
Tip #7: You want a web host with a stable Time to First Byte (TTFB) of less than 300ms. And if you can find a web host with a TTFB of 200ms or less, sweet.
TTFB is the time it takes a web host’s server to deliver the first byte of data for a requested page to a visitor’s browser. This is an important qualifier.
Knowing a web host’s TTFB is how you can verify if their speed claims are true. To check for TTFB, go to ByteCheck.
And run the web host’s homepage through ByteCheck six times. Then, you’ll know if you’ve got a winner or a dud.
Conclusion
There is likely no “perfect” host, but now you have information to help you choose web hosting more wisely.
More than half the top 1 million websites use Google Fonts. This is not the best practice for mobile speed.
The inaccurate Web Font defense:
“Without Google Fonts we’re limited to a handful of system fonts installed on our user’s device.”
So what? Is this a bad problem? Since when? Web safe fonts are not recognizable to the average web visitor. Google web fonts caused internet dilution. That doesn’t mean web fonts are better. Variety reduces imagined stigma from using “ordinary” fonts.
There is a justifiable condition for using Google Fonts. That’s when there are no other graphics differentiating your page. The font is then the only thing. It’s the bottom-most design consideration for mobile devices. Color combinations are a much more important factor.
Unaware clients talk about their logo size. Then it’s “What font will we use?” Please select one that’s readable and fast on a mobile device.
For speed, GeneratePress theme uses the default mobile system font stack: -apple-system, system-ui, BlinkMacSystemFont, “Segoe UI”, Helvetica, Arial, sans-serif, “Apple Color Emoji”, “Segoe UI Emoji”, “Segoe UI Symbol”.
This method makes practical sense.
System fonts or ‘Web Safe Fonts’ are common and pre-installed across operating systems. For example, Arial and Georgia come with Windows, macOS and Linux distributions. They load fastest.
Default fonts are utilitarian. That’s good for mobile speed. We do not consider decorative body text important for small mobile screens. Readability and legibility are what count.
Web safe fonts are still preferred over requesting cached Google Fonts.
Google Fonts come with a speed cost. Each font carries a weight that the web browser needs to download before display. In worst case conditions, users wait seconds. That should be reason enough not using Google Fonts. Do Google Fonts cause delays or failures every time? No. Only sometimes. Why? Because they’re hosted from remote servers getting millions of simultaneous API hits.
Claiming “Google Fonts Are Already Optimized” doesn’t buy much in our book. Even optimized they’re never as fast as system fonts. Never.
The Google Fonts API does a “smart check of browser type.” That’s to see how it can deliver files in the most optimized and compressed format. For example, detecting the latest Chrome browser may need only one font type. Google then sends only one font variant instead of a whole font family. That is a speed improvement. Yet that still isn’t faster than system fonts. This is a workaround (kludge?) not providing any improvement over web fonts.
“Google Fonts maintains 30+ optimized variants for each font and automatically detects and delivers the optimal variant for each platform and browser.” — Ilya Grigorik, Web Font Optimization
Wow! Big hairy Google deal.
Does that cool technology specification make us feel better? Google has performant font formats for old browsers. It’s not a feature – it’s a bug fix.
“As the Google Fonts API becomes more widely used, it is likely visitors to your site or page will already have any Google fonts used in your design in their browser cache.” — FAQ, Google Fonts
Because half of websites use Google Fonts, it’s often claimed there’s no waiting. What? There’s no waiting for web safe fonts either. In fact, there is no “first-time-view” without cache for websafe fonts. Web safe fonts are always available.
Google Fonts aren’t completely cached for far-future expiration for more than 48 hours. Why? Google says it’s because they may change something and the fonts need “refreshing.” Wait?
Is Google saying there is a benefit to not caching older versions? None whatsoever for you. Only Google benefits gathering data more often. Every single visitor need a new fresh font file within 48 hours? No way.
Each font can add up to 400 kilobytes to your page weight. Multiply that by a few different font families and fonts weigh more than your entire 2- to 3-megabyte page. That is never a problem with websafe system fonts. They have an instantaneous load time. Zero seconds. Zero page weight.
For example, the Google Roboto font family weighs 144 kilobytes. But if you only use the Regular, Regular Italic and Bold variants, that number is 36 kilobytes. That’s good savings. Right? No. It’s still slower than websafe fonts. Get serious.
Web fonts need calls to Google’s servers (example: fonts.googleapis.com), that’s called an HTTP request. The more HTTP requests, the longer it takes your page to load.
You can call more fonts in a single request. There is no limit to how many fonts and variants a single request can hold. There are plugins to do this trick. But we’ve seen no speed benefit over using websafe system fonts. Even if you use a plugin to host Google Fonts locally on your server, they aren’t faster than system fonts. It’s a weak method to try and hang on to the sluggard.
It takes time for the browser to download Google Fonts, but what happens to the text before they are ready? Showing nothing at all is jarring to the user. A better experience is to show a system font as a fallback and then “swap” the fonts once they are ready. This is possible using the CSS font-display property. This is a ridiculous strategy. Why not avoid the hassle and use the system font? That’s right.
Forget Google Fonts.
There’s not enough time to test all new free WordPress themes for speed potential. So we set easy limitations to reduce our workload. We look for signs or clues of author sloppiness and wasteful shortcuts.
The ideal speed theme is a download file of under 1M-compressed. This is our arbitrary threshold and indicator for speed potential. Once decompressed – and with the demo screenshot subtracted – it will total between 1M and 2M. These generally create 500-millisecond to 2-second page loads. And that’s on cheap, shared hosting.
It’s plain many themes above this 1M-download cutoff may be fast. But we don’t want to mess around searching. It’s also rare for a theme to make written guarantees. Nothing about speed, page weight, or even the number of HTTP requests. Many imply they’re fast. But they don’t give specifications.
A 1M cutoff drastically reduces the number of theme candidates. This is a quick-and-dirty filter. It prevents you from wasting time on themes with low-speed potential. The package size is indicative of the theme author “caring” about performance.
Note: A lite theme means it has crippled features or stripped down from the “pro” paid version. Lite doesn’t mean lightweight.
The nine free themes listed below all have commonalities. We won’t put them on any preferred list. Even though some are attractive. We’re using them to prove some font facts. For us, they’re toward the bottom of the speed barrel – but still pass the 1M limit barely. They have 1-to-2 second page-load potential. They aren’t as forgiving as other less “feature-rich” themes.
Why aren’t they so good? They have built-in site drag. They weren’t authored with speed as a priority. That’s indicated by the frivolous, slow “non-features.”
What are non-features? Unnecessary bloated decorations. Expressive aesthetics like animation. They all use cloud-based Google fonts. And they all have Font Awesome icon font onboard. Four use sliders. Sliders activate JavaScript and are heavy and easily abused. (Read our article about sliders and why they are bad for speed.)
But in spite of these infractions, the themes still pass.
We ask ourselves, “How much speed difference does font baggage make?” So we did some testing with the help of free plugins.
Asset Queue Manager
This plugin is almost a secret. Only 900 installs. It’s used for hardcore performance optimization. It allows us to switch off (dequeue) Font Awesome. Of course, it’s used for dequeuing other scripts, too. But we’re just using it for our Font Awesome experiment.
Font Awesome is a font and icon toolkit released in 2012. And quickly became a crutch for theme authors to create “cheap art.” Twenty percent of websites with third-party fonts use Font Awesome. We find it on half of the new theme releases. It ranks second place after Google Fonts. We hate it because the lightest version uses 70 to 80k of page weight globally. And it has no websafe system font fallback like when using a CSS font stack. That means if we disable it, the site may look broken. Not always. Just especially mobile pages.
Frequently, Font Awesome loads on every single page whether there are any icons used or not. That’s bad for mobile bandwidth usage. Font Awesome may be loaded in parallel with other page assets. That makes the drag invisible to users. So why do we even care? Requested font data is still transferred on each page. And that costs someone time and money.
The inclusion of Font Awesome is a solid indicator of a slow theme. Authors who care about speed don’t include it ( Astra, GeneratePress, and Twenty-seventeen default theme are good examples). They let the site owner decide to install it with a plugin if needed. Like Better Font Awesome plugin.
Our other beef with Font Awesome is that only three icons are traditionally used. These are:
the magnify glass for search fields
the mobile navigational “hamburger”
the up-arrow on top-of-page links
(Also social icons. But that story we’ll save for another day.)
You could make 70 PNG image icons with the same total weight – or less – than Font Awesome. It’s equal to a hero header image. We’d rather not see any icons – either font or image. Overused and boring.
It’s possible for a theme to load Font Awesome – and then a plugin may load it again, too. This duplicates the global load. Doubling the additional page weight by around 150k. Wow. That sucks.
Is it worth removing or dequeuing Font Awesome? Nope. You might save 50 to 100 milliseconds. But, it usually will break something somewhere. Not always. Some theme authors don’t use Font Awesome for the hamburger and magnifying glass. They are merciful. Those authors deserve a medal for going the extra mile.
Is it worth finding a theme that doesn’t use Font Awesome? Yes. We think so. We hunt for those jewels. Remember half of new themes don’t use this iconic boat anchor. (The same statistic goes for unneeded sliders. Half do. Half don’t.) But leaving out Font Awesome is usually futile. It won’t make any noteworthy perceived speed difference in tests. It makes a difference in how much data goes back and forth from server to browser. And if you think that browser caching might help, sorry. Font Awesome comes in many oft-changing versions and flavors. That means browsers probably aren’t storing the right one for your users.
Font Awesome sometimes does weird fluctuations and delays loading by an extra second. Why? Voodoo! Why even take this speed risk?
So does removing Google Fonts make a difference in speed?
External font scripts like Typekit or Google Fonts slow down your site. Typekit is the worst for speed. Websafe fonts are guaranteed to be faster. According to HTTP Archive, as of October 2016, web fonts are just over 3 percent of an average page’s overall weight.
Disabling with Remove Google Fonts References plugin makes an average difference of only 53 milliseconds in our tests. But in the extreme, one theme (Martial-Lite) 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 just 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. Just like Font Awesome. 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.
Finally, there are a bunch of elements that have become something of a standard with a modern website design that, while not offensively intrusive, are often unnecessary. I appreciate great typography, but web fonts still load pretty slowly and cause the text to reflow midway through reading the first paragraph. REFERENCE
So our speed recommendations are:
Find a 1M or less compressed theme.
If it doesn’t have Font Awesome, it’s best.
If you can bear turning off Google Fonts, that’s even better.
Avoid sliders.
Only about 20 percent of new themes meet these criteria. No surprise.
Another plugin alternative for speed: Google Fonts cause slow external requests to Google’s servers. You can host the fonts locally on your server instead. Hosting fonts locally won’t always make your site load faster. If the font is popular (like Lato or Roboto font) and already cached in a visitor’s browser, those fonts load pretty fast. But a plugin exists to help optimize local Google font hosting. It’s CAOS for Webfonts (11.5k zip download). The plugin decreases page load times, leverages browser cache, and minimizes DNS requests.
When it comes to fonts, there are many web myths and unsaid facts. Especially concerning mobile speed.
The Google Fonts API serves the fonts listed in the Google Fonts directory. You cannot control Googles headers (including expiration headers). According to the Google Fonts FAQs, their font files are cached for a year. If so, why the PageSpeed Insights render blocking error?
Google’s CSS files associated with the font are only cached for 24 hours. Speed test expiration information shows this. That is how long browsers store the asset in the browser. Best practice is setting a 1-year expiration. Far futures expiry plugin controls this or you can hand code your .htaccess file on your server. We prefer the plugin.
Google calls/requests its CSS files every time. This is for “font freshness” – updated versions. But that’s a Google smokescreen. Google says, “It’s for fast support of font changes.” Every font changes every day?
Daily updates? Really? It doesn’t churn that fast.
Ironically, Google Fonts fail Google’s own PageSpeed Test. It generates an error: “Eliminate render-blocking JavaScript and CSS in above-the-fold content.”
There is a plugin for hosting the fonts on your own web server (local). Not on Google servers (remote). Then you can do “far future expiration.”
Google, claims to encourage PageSpeed. But they don’t even cache their own fonts Why? A nice data collection opportunity for them. Wake up. It’s for their benefit – not you. There’s also a plugin to merge all font files into one – concatenation. This combines many webfonts into one request.
We’ve messed with this plugin and never can see it working in speed tests. So we’re not believers yet. But 6,000 other suckers believe.
It’s theoretical. When millions of websites all link to the same fonts, they are “ideally” cached. After loading the first font, it should appear “instantly” on all other later visited sites. But that isn’t true in all case or even in most cases. Google sees 1 CSS request per font family, per day, per user browser.
That request occurs most often on the most critical first impression. Those are visitor landing pages from the SERPS. Secondary pages don’t have the same visitor expectation for speed. So don’t decorate your main top10 pages. Keep those lean.
A single font request may take only 50 milliseconds. To put that in perspective, that’s the same speed as GeneratePress (free) theme.
“Web fonts are likely to enhance the performance, maintainability, and accessibility of your page” is a quote directly from Google.
That isn’t even a partial truth. Another Google deception. They aren’t that stupid to propose fonts improve site performance.
When you use a Google Font, you may load the entire set in the font family. Not a single style like “regular.” There may be many weights. This usually adds around 300 milliseconds to a critical first page (guesstimate). Now that doesn’t include delays caused by loading extra languages of the font set.
If you use an <i> tag (italic), which is quite common, that loads the italic font variant. Another 100 milliseconds wasted. If you call 10 font variants you produce a 1-second cumulative delay for fonts. That is very possible on branded sites (H1, H2, bold, italic, etc). Half the 2-second performance budget gone.
Google downplays the impact of their fonts on page load time. Especially for mobile phone users.
Font loading behavior varies depending on browser type. Some browsers only display text after font files load. Others will use the fallback font from the font stack and then refresh the page when the font is available. This behavior is the “flash of unstyled text,” or FOUT.
Websites include 3 fonts on average. These fonts are around 100K in size each. Fonts load after the HTML and CSS sources.
Staring at invisible text – or at font-swapping shifts – is unacceptable. The best option is giving up on custom fonts and relying on web-safe fonts. That’s our choice and preference.
We can’t describe the loss felt the day we threw our print type collection in the trash. It was something we loved. It was part of orchestrating the mood of a well-designed printed page. We let it go for a better mobile user experience. Gone but not forgotten.
Major content platforms (such as Wikipedia, Medium, WordPress and Github) use system fonts. They’re available for use on computer operating systems. This is a worthwhile strategy when styling is not a primary concern like small mobile phones. Not referring to tablets! On heavy-traffic mobile sites, traffic is 20-percent tablet visitors. The 80 percent bulk is small phone screens.
Blogs claim, “Great typography is crucial on the web” for readability, legibility and “well-crafted typographic design.
Is well-crafted a must for brand recognition and the success of your message? We say credibility and readability trump branding. Frivolous branding requires special fonts. They’d do better paying attention to other readability details. Like not using small, squinty fonts or low-contrast gray colors.
Fast-loading mobile (modern?) font stacks look something like this in CSS:
Google says one thing. We say the opposite. What’s the truth?
We strip fonts unless a site already achieves under target speed goals. Then they’re ignored. But generally, we disable them. Site users are oblivious to the differences.
Trends in mobile include new speed themes like GeneratePress and Astra. And the Twenty-nineteen default theme. Out of the box they enable mobile font stacks defined in the style.css file. They don’t use Google Fonts. Fonts have a stigma for mobile. They consume unnecessary bandwidth and data limits.
Single-column, 350-pixel wide images or resized images are what’s served up. All that matters is legibility and readability. Creating any mood is from color choices. Color combinations recall memories. Memories have feelings associated with them. It’s a subconscious influence.
How much “mood or emotion” can you muster in a small 5.5-inch screen space? Be honest. Small blocks of color whizzing by with the flick of a thumb. That’s mobile user experience? More like roulette.
Stripped-down “speed themes” often don’t enable jQuery by default either. If you resist the temptation to install a slider, top-of-page button, or some other jQuery intensive plugin, you avoid the extra load. Themes did this in the past (like Susty, Frank and Sobe themes) but were seen as esoteric or fanatic and not well received. Now it’s a mainstream trend. The Herd wants extreme modifications because they suppose speed will save their site. Speed never compensates for poor content. Ever.
Discarding font baggage and jQuery are nuances for speed. They make for fast themes. But you can destroy that with a few popular plugins. Then the gain is minuscule by comparison. Dwarfed by thoughtless plugin abuse.
Fussing about choosing Google Fonts is wasteful.
Theme authors retrofitted speed change based on requests from users. The demand was high enough and thus offered the chance to sweeten the deal.
This means using Google Font usage is now seen as painful to speed and UX. And thus SEO. Big deal.
You don’t have to install a plugin to remove Google Fonts on these speed themes. The theme loads are transparent: meaning less than 50 millisecond load times. But if you buy the premium version, they’re no longer the fastest kid on the block. They don’t tell you that fact. The themes then are more average than special.
Human eyes have limitations. There’s a theme trend to use light-gray type on web pages. This is not good UX. But designers, who should know better, are setting bad examples. Black on white was the standard for many years. That color combination is fatiguing when reading a large block of text onscreen.
The recommendation is #333 dark-gray on white to reduce harsh contrast. But going lower contrast than #333 makes viewers squint to attempt reading text – even when the font size is 18px. We recommend using browser tools for checking font specifications including color and size. We use FontFinder for Firefox. There are equivalent tools for Google Chrome.
FontFinder type specification tool using Google Chrome.
“An article about how the web is becoming unreadable has been making the rounds. I feel like most designers already know that light gray text on a white background is a bad idea. The article focuses on text color but I think a more relevant issue is font weight – I’m seeing so many sites these days set body text in 100 and 200 weights which were not designed for body text use.” — Jeremiah Shoaf of TypeWolf
How the Web Became Unreadable I thought my eyesight was beginning to go. It turns out, I’m suffering from design. by Kevin Marks
Look at these websites. They look fabulous indeed but how good is that if people can’t read them?
Light-gray text is fake minimalism.
“Minimalism in web design started as a backlash against decades of interfaces that increased the prominence of so many elements at once that they all clamored for attention and became visually overwhelming.
What’s great about minimalism is the principle of stripping out non-essential elements. In most cases, this is a best practice to follow.
When it becomes an issue is when there is lots of essential content on a page. Having a lot of content doesn’t suit the minimalist approach to design. So the designer’s compromise has become reducing the contrast of those elements so that, at a glance, the page still ‘looks’ minimal.
Yes, low contrast text does ‘look’ minimal, the same way a blurred photo on Instagram can ‘look’ retro. But you wouldn’t blur your website even if it were fashionable. Don’t lower your contrast, either.” — Nielsen Norman Group
Easy reading helps learning and enjoyment, so what we write should be easy to understand. Readability is about ease of reader understanding. Text should be inviting. Text depends on content (vocabulary) and typography (font size, line height, and line length).
Readability Plugins for WordPress An interesting article about web readability mentions several WordPress plugins that help assess the readability of body text. The one plugin we feel is most appropriate (because it’s lightweight) is: FD Word Statistics Plugin. It shows word and sentence counts at the bottom of the WordPress editor. Plus a readability analysis of the page or post currently being edited is shown using three different readability measurements. Those are the Gunning-Fog and the Flesch-Kincaid indexes. (Plus one labeled Flesch that we don’t care about). [/pullquote]
Various factors to measure readability have been used, such as speed of perception, perceptibility at a distance, perceptibility in peripheral vision, visibility, the reflex blink technique, rate of work (e.g., speed of reading), eye movements, and fatigue in reading.
Readability and legibility aren’t the same. Legibility is a measure of how easily individual letters or characters can be distinguished from each other.
The average adult reads at the 9th-grade level. It also shows that, for recreation, people read texts that are two grades below their actual reading level.
Four variables give the most reliable measure of web reading ease:
Words per sentence.
Average grade level of words.
Characters per word.
Sentences per paragraph.
Readability should be your number one goal. Someone in your company or organization should especially check graphics to ensure they’re readable. This means:
No “reverse” (white body text on a colored background, which is hard to read).
As few italics as possible (they’re hard to read).
Not too much boldface (ditto).
Not too much super-wide full-width copy (ditto).
No type above headlines (confusing).
No hard-to-read colors like light grays. There should be a 30% grayscale differential between text color and background color. We search for edges of letters for character recognition.
Measure onscreen font sizes in pixels using the Firefox browser tool: Font Finder or the Google Chrome browser tool: WhatFont.
Do you pride yourself on not being a sheep or blindly following the herd?
Have you watched hours and hours of YouTube videos and read pages and pages of blog articles?
Have you dotted your “i’s”, crossed your “t’s”, and checked everything in triplicate?
Maybe someone has gently implied and then outright accused you of overthinking and told you in no uncertain terms that you know “enough.”
Maybe it is as simple as wanting to do right by your website and to be an informed WordPress site owner.
And yet, even with all this research, here you are still searching for the “truth.”
Because many of the things you “know’ just don’t make sense — 1 + 1 should equal 2. So how come it is adding up to zero and page load times in the tank?!
Well, today is your lucky day. Because lo and behold…
Here you are at PagePipe, you just serendipitously stumbled across us.
HOW TO WIN THE RACE TO A LIGHTNING FAST WEBSITE
So now that we have your attention, let’s connect the dots. We promise that you will save yourself wasted hours and money from the pursuit of nonsense, outright lies, and hidden agendas.
Let’s start at the top:
1Web Hosting: Choose Wisely
Every website must have a web host. Your web host is the server computer where your website files will live.
It is your web host’s job to deliver your web pages fast and securely.
Many hosts claim to be fast, even super fast. But rarely, is it shared how the average website owner can verify the truth of these claims to speed.
Well, PagePipe to rescue…
Here are a few hallmarks of a good web host:
Shared hosting is sufficient
Has a 99.95% uptime
Allows you to write to your .htaccess file
Has a stable TTFB of 300ms or less
That last one is key.
What the heck is TTFB, you ask?
Well, it is an acronym for Time-To-First-Byte, which is the time it takes a web host to deliver the first byte of data for a requested page to a visitor’s browser.
Knowing the TTFB of a web host allows you to objectively determine if their promises of speed are in fact true.
And you can check TTFB at ByteCheck. Just run the homepage of the web host company through the test at least six times to assess.
There are simple ways you can identify a high-quality, fast theme out in the wild:
It isn’t obese with features and code. To test a theme, download the theme from the WordPress repository. Ideally, the compressed zip file should be in the neighborhood of about 1MB or less.
It’s FREE. Generally, a high-quality FREE theme will always be faster than its premium first cousin. Why? Because all those added bloat — er, features — come at a cost of increased page load time.
It does not include Google Fonts by default. Instead, it installs with system or web safe fonts. (Typography is a gorgeous thing. But we question how valuable it is as a branding to do.)
It does not include Font Awesome.
There is nary a slider or other animation in sight. Sliders are a speed suck. Please stop.
And if you doubt us, check out the file size of one of the fastest themes around GeneratePress and the file size of its premium plugin.
GeneratePress theme free version: 935k zip file size and and GeneratePress paid version (pro plugin) adds another 854k file. Effectively, doubling the load time. They forgot to tell us that at checkout didn’t they. Sin of omission.
Those premium add-on features are almost the same size as the entire theme itself.
A plugin is add-on software that extends the capability of a program.
And one of the truly great things about WordPress is the functionality that can be added to a vanilla website to make it do pretty much anything you want it to do.
This is the blessing and the curse.
There are literally thousands and thousands of plugins in the WordPress repository. And that is no exaggeration.
On the issue of plugins, there are still two camps:
Those that believe you need to limit the number of plugins to like 10 or 20.
Those that believe it is not the number of plugins but the quality of the plugin. We should choose well-coded plugins.
But how does the average non techie website owner choose a quality, well-coded plugin?
Well, we have the answer…
A well-coded plugin is a discrete plugin. And a discrete plugin has these five characteristics:
It is located in the free WordPress plugin repository.
It provides ONE function. In other words, it does NOT try to do everything under the sun. Hence, it is discrete.
If you download the plugin’s zip file from the WordPress repository, it has a file size under 100kb. The lower the better. We’ve seen plugins with a zip file size as low as 3kb. Sweet.
Once installed and activated, there are typically no settings to configure and confuse you. And if there are any settings, they are minimal. In other words, a discrete plugin is plug-n-play.
It has little or no impact on your site’s load time. Load times are under 2ms.
So now that you know what a discrete, well-behaved plugin looks like, can you pick out the potential problem in the image below?!
Look at those two huge plugins. Make sure they’re deactivated if unused. They’re maintenance only plugins.
Bonus tip: It is always a good idea to check your site speed before and after installing a new plugin.
Bottom line: Plugins that try to be all things are good for nothing and they will drag your site speed into the bottom rungs of website speed purgatory. Delete and move on.
You don’t need a fat, multi-function security plugin on your website, mucking about with your site speed and littering your WordPress database with tables and thousands of row entries.
No, you don’t.
We know. It is sacrilegious.
Because everyone knows you must have a security plugin or risk being hacked to death by evil hackers.
But the truth is, you’ve been fed a load of hooey. In fact, just about everything you think you know about keeping your website secure is an over-inflated lie.
Here’s the least you need to know about website security:
Choose a web host with a commitment to security.
You can do a lot from your end to secure your website. For example:
Please change the default username from admin or administrator. Make a hacker work for their ill-gotten gains. Too easy.
Use a password that is at least 12+ characters long. And keep those evil hackers guessing for an eternity.
Keep WordPress core, your theme, and all plugins updated.
Delete unused themes, plugins, and widgets.
Disable XML-RPC, which allows you to upload and edit content remotely to your WordPress site. Here’s a great lightweight plugin for that: Deactivate XML-RPC Service.
Install Limit Login Attempts Reloaded plugin; it adds a lightweight layer of defense against brute-force attacks. This plugin also automatically removes XML-RPC. Bonus.
Finally, if you care about your content, take the time to do a proper backup. As Nike would say, “Just Do It.” Or as mom would say, “Be safe.”
Is there more you can do? Yes.
But doing the above is a powerful start — with these steps, you’re over 90% covered.
The alleged goal of caching plugins is to speed up your website.
But look, here’s the truth…
If you build your site from the start with mobile site speed in mind, you don’t need a fat, multi-function caching plugin.
Yep. Sacrilegious, again.
Take a breath and hear us out.
First the truth…
Scores on speed testing sites are irrelevant.
We know…
It’s so nice to get that green 90+ score, but it is irrelevant. Do not get side-tracked trying to get a B or an A. Instead, focus on what really matters and counts:
Page load time: This is how fast a requested page loads in the browser. Ideally, you want 1 to 2 seconds on desktop and no more than 3s on mobile. Make sure to test your home page and other important pages on your site. (By the way, a 1,000 ms = 1 s.)
Page weight: This is the sum of all the assets — images, other media, HTML, scripts, and style sheets– required to display a web page. It will vary from page to page, but try not to exceed 1MB. The internet average is 2.3 to 3 megabytes. Heavy.
Having the wisdom and knowledge to build your website optimized for mobile speed is called origin optimization. This should be your true goal.
And it really isn’t hard at all. And to prove it, let us share how you can build your website from the ground up to fly…
Choose a web host with a Time To First Byte (TTFB) that is less than 300ms.
Do not automatically install a web host’s proprietary caching plugin. Instead, build a fast website and then assess if you really need it. Many of these proprietary caching plugins like most caching plugins are an unholy mess. In any case, most modern web hosts implement caching on their servers — let the issue of caching stay there.
Choose a FREE fast theme.
Implement Gzip compression. Gzip compresses text in HTML, JavaScript, CSS, and PHP files, which speeds up file transfer.
Minify and concatenate JavaScript and CSS files – only when necessary.
Say “no” to Google Fonts (Yes, they are pretty. Yes, you should let them go.)
Say “no” to Font Awesome.
Lazy load media (WordPress core now lazy loads images.)
Do NOT design your website using Page Builders like Elementor.
Use static images that are resized and compressed in the hero section (at the top) of your web pages.
If you are not using a theme, plugin or widget, you should deactivate and then delete them. Unused plugins don’t slow down your site. They just make things confusing.
If you take the above steps to build an optimized website, you don’t need caching plugins and Content Delivery Networks (CDNs) “band-aids.”
We hope that you see the value of building speed into the foundation of your website and that speeding up an already fast website is, well, redundant.
6Make It Relevant. Make It Valuable. They Will Find You.
You also don’t need a complicated, obese Search Engine Optimization (SEO) plugin.
No. You don’t.
We know, shocking, right?!
The amount of settings in the average SEO plugin is mind-boggling.
And then, all those “required” criteria they insist is mandatory to write a post that is SEO-ready for the Google demigod.
YIKES. Do you really want to exhaust yourself frantically scurrying to tick off that long list of green dots in the average SEO plugin?!
And for what?!
You still can’t “game” Google. And Google will continue doing what Google secretively does in the background.
So we say, “Just don’t.”
Here’s all the SEO you need to know:
Just write super helpful content.
Write stellar headlines. Because if your headline doesn’t grab, no one is reading your content.
Plus…
If your site is slower than molasses in the middle of winter at the North Pole, because you installed obese, multi-function plugins on your site, visitors are unlikely to stick around to read your content.
That is a fact. You know it.
So don’t be duped into wasting time. Stop chasing the elusive green dots of “proper” SEO and focus on the things that matter:
Fast page load time
Helpful content that can be easily read and searched
A website consists of lines and lines and lines of words and code.
Minification removes unnecessary spaces between the words and lines of code. This removal of these spaces is harmless and can offer a small decrease in site load time, especially over slower connections.
Here’s a word you may not have encountered: Concatenation.
So what the heck is concatenation?
Concatenation combines HTTP requests and scripts.
What isn’t so commonly known or shared is that when caching plugins minify, they concatenate too.
And it is concatenation that has the potential to break your site. But it is the harmless minification that gets all the blame.
WordPress’ handling of images is not really a simple matter. Or, is it?!
Here’s the least you need to know about WordPress and images.
When you upload an image to WordPress Media Library, WordPress core automatically creates at least four additional copies (thumbnails) of your original image to embed in posts and pages and to respond to requirements of devices of various sizes. (Your theme may also add to this number.)
Large: 1024 x 1024px
Medium: 300 x 300px
Thumbnail: 150 x 150px
Medium_large: 768px wide (This size is not shown in WordPress Media Settings.)
Basically.
Websites light on images will not need to be overly concerned about how WordPress handles images.
But websites that upload loads of images need to be aware that these additional thumbnails are being created each time they upload a single image.
Here’s the thing…
If speed is important to you, then you should always take the time to do the following to all images BEFORE you upload them to your WordPress site:
Resize images. Under no circumstances is it ever a good idea to upload giant images directly from your camera or mobile phone to your website. You need to find out the width of your post content area, and then, use that number when resizing your images.
Then, you need to compress images and reduce image resolution to about 70 dpi. Just know that 70 dpi is a general recommendation and can vary based on the image. Ideally, you are striving for image file sizes under 200kb.
We like Optimizilla for an online image compression tool.
Check out Imsanity plugin for onsite optimization. Offsite link
And on the issue of webP images…
Skip them for these reasons:
They are a proprietary Google offering.
They are not relevant (1) if you have built your site with origin optimization; (2) if you resize and compress images before uploading them; and (3) if you lazy load your images, which WordPress core now has built-in.
And one more thing for now…
There seems to be a lot of confusion about retina images. You can lose a lot of sleep and time over optimizing for retina display. Many have. It’s sad.
But here’s the thing…
Did you know that retina displays were created to reduce eye strain?
Yes, it was all about reducing eye strain, not improving image quality.
So relax. You can probably ignore the “special” requirements of retina display and get on with your life and what is most important:
Fast page speed
Helpful content that can be easily read and searched
Listen, it is never a good idea to add any “asset” to your website without seriously assessing the value of that “asset” to your website.
Everything that you have on your site should earn its keep.
Sure, these days, certain add-ons or features are “standard” like comments, social media sharing plugins, chat boxes, carousels, sliders, pop ups, and Gravatar images.
But we challenge you to ruthlessly assess every “asset” you allow on your website…
Are they really necessary?
Do they provide a tangible meaningful value?
Are they earning you money or just “preening?”
Don’t be a sheep – Just think about it. Don’t let “standard” features and add-ons weigh down your mobile site speed.
Google Analytics gives you the free tools you need to analyze data for your business in one place, so you can make smarter decisions.
OK, so let’s break this down…
Question #1: Do you believe that Google is the Internet demigod we all must serve or starve?
Question #2: Do you believe that if assorted content marketer extraordinaires say you must, you must? After all they have made millions as content marketers; so they know, right?
Question #3: How the heck does one even begin to understand the confusing and convoluted interface of Google Analytics?
Plus…
Question #4: What do you do with all this data if you could find the time to analyze it?
Let us answer that last question: Most of you will be too overwhelmed to do anything with all that data. The reality is this: Too much data can be overwhelming and good for nothing.
Plus…
Question #5: What about Google’s fundamental lack of respect for the privacy of individuals on the Internet?
Plus…
Your website’s load time seems in the tank since you installed the Google Analytics tracking code on your site.
Wait…
Are you thinking, “Hey, that’s the price one has to pay to be found in organic search, right?!”
Well, I want you to stop right here and let’s rethink the subject of Google Analytics. Here’s the least you should know:
If you have a personal blog (also known as a vanity site), you can skip it. Because you are just having fun.
However, if you have an eCommerce site, analytics may be useful. But did you know that your web host can most likely provide analytical data WITHOUT the appalling negative impact on your site speed?!
The four main pieces of data you need about your visitors is (A) bounce rate; (B) dwell time; (C) traffic sources; and (D) return visits. That’s it. That’s all.
Finally, the data in Google Analytics may not even be accurate. And if the data isn’t accurate, how can it be truly useful in helping you achieve your goals. Just sayin’.
In fact, the truth is that they can’t even pass their own tests and much of their prescriptions are biased and hypocritical.
Yes, we just wrote that.
Bottom-line: If you care about mobile site speed, then you must do your best to eliminate or limit your reliance on Google products, including but not limited to:
Google Fonts (We know. They are pretty. But just let them go.)
Google Analytics
Google Maps
Google ReCaptcha
Google webP
Google Snippets
Google AMP
Google PageSpeed Insight (lies and irrelevant)
Whew!
We know it’s hard to break up. But be strong and say a firm no to Google abuse.
Most email service provider plugins are a total nightmare to mobile site speed. These plugins are not discrete — it is just the nature of the beast.
Your email service provider and other “content marketing gurus” may instruct you to place a subscription signup form on every page of your site.
Please. Don’t.
Instead, create a landing page (a page with a single function) on your website and then, add the signup form there — ISOLATE it. Then, put a link on your primary navigation menu and in your footer that links to that page.
Now, you can build your email list of true fans and still respect your mobile site speed.
How brilliant is that?!
THE END
We know that’s a lot — and, frankly, there is more.
But if mobile site speed is important to you — and we sincerely hope it is — then, you need to know these truths.
And if you take care of the tips and tricks listed on this page, you are well on your way to a website built with mobile speed in mind.
And why does this matter?
Well, because serving up a fast website is one way of caring for others — and the environment (saves energy). Yes. We believe in those principles. We’re idealists.
So be kind, always question and challenge the prevailing “wisdom,” and speed up your site.
Janine Helligar is a daughter, sister, friend, sewist, amateur writer, and WordPress enthusiast living in Georgia. She blogs at Stitching in Colour.
UNBELIEVABLE. Look at how many site owners are drinking the WebP image Kool-aid. “Drinking the Kool-Aid” refer to a person who believes in a dangerous idea because of perceived potential high rewards. That’s right we’re saying WebP is *dangerous*. There is no reward. Why? Because it wastes time and money and your personal energy. Chasing ideas that don’t make a significant difference in speed or ranking is wasteful. True entrepreneurs can’t afford to waste limited resources.
WebP is a speed hoax.
Oddly, the hoax is most perpetrated by professional speed optimizers. And image plugin authors say it’s state-of-the-art “best practice.” We hate WebP with derision.
Why derision? Because WebP is so fake, we don’t know whether to laugh or puke. Or both.
You may say, “Prove it doesn’t help speed. We issue a challenge.”
OK. We accept your challenge. But if you spent even a little money converting your media library to WebP, you won’t appreciate how this fairy-tale story ends. You may feel angry or foolish.
The WebP Torture Test
So we took an optimized PNG image (45k). We put it through a WebP online tool – and the resultant file size is 25.5k. That is a 43 percent decrease in file size.
Whoopee! Sounds impressive, doesn’t it? 43 percent better! But better than what? Is the speed better? Let’s check.
This is the image. It’s one we formerly used to advertise our speed services.
Does that fantastic WebP reduction make the page 43 percent faster? No.
Surely at least the image loads 43 percent faster? No.
What? It makes no difference at all in speed?
Skeptical? Keep reading. We’ll explain with real numbers.
Side-by-side comparison of images.
Now we’ll upload both the PNG and a WebP conversion onto our WordPress test page. Then we’ll make separate measurements to find the speed difference of each image using a browser timer addon.
Note: What curiosity is this? The LiteSpeed dashboard claims:
Significantly improve load time by replacing images with their optimized .webp versions.
Why did they say that? To appear cool offering a fashionable magic image format? Imitating the big and popular technology doesn’t make things cool.
Who started this WebP fairy tale?
We’ll soon prove the WebP web myth is pure rubbish. Not significant at all for speed improvement.
Who claims it is significant? Google influences many ignorant blogs who assume Google speaks the truth. Who claims to have invented WebP? Genius Google does. Did they? No. They acquired the technology inadvertently in a corporate buyout. They didn’t know what good it was. It had no purpose. It was supposed to help videos. Not static PNG and JPEG images.
WebP is an image format employing both lossy and lossless compression and supports animation and alpha transparency. Developed by Google, it is designed to create files that are smaller for the same quality, or of higher quality for the same size, than JPEG, PNG, and GIF image formats.
https://en.wikipedia.org/wiki/WebP
Sorry, Wikipedia. Google did not develop this. They bought it in a business error. WebP is face-saving salvage after the flub. “What should we do with this silly thing?”
Nudging the marketing guy next to him, “Let’s tell website owners this stupidity we paid for is good for still images. Then we’ll look smart instead of dumb.”
WebP as speed goodness is now regurgitated over and over on web blogs. And in plugins read.me files. And, by image optimization plugin authors. And, on server caches. Incredible.
It’s not true. It isn’t goodness for speed. At best, it’s benign.
Didn’t anyone test this WebP thing in a real web environment?
WebP may slow your site if you create and load the WebP images using offsite remote image storage. CDNs like ShortPixel for example.
TRUTH: WebP does make images lighter.
But does WebP make a difference in real speed? You know: page load time in milliseconds?
TRUTH: Not a bit. It makes no difference in speed.
We’ll demonstrate. You can try this experiment for yourself.
Wait! Seriously? Everyone says, “WebP improves my web core vital metrics.” It may improve some lame scores. But it won’t improve your page speed. Page rank improves not one iota either.
Because various online speed tests vary so widely, for this test we use a browser timer. We prefer using a browser add-on or extension. In this case: app.telemetry page speed monitor. This handy tool checks the page load times of any web page. It shows the offset and duration of each page load step based on W3C navigation timing. And it’s free for Chrome and Firefox. Nice.
Wait! Isn’t that faster? Shouldn’t adding the image slow down the page?
The installed image is being lazy-loaded in parallel with the page favicon. The image addition made no change. Because of image lazy load and parallel loading. Lazy load is now a default in WordPress core since August 2020. Is it better than a standalone lazy load plugin? Not always. Test to make sure. Primed cache speed is identical in this case.
Replace PNG with WebP image.
Now we remove the PNG image and replace it with a optimized WebP image. Sadly, it won’t upload to the media library until version 5.8 is released on July 20, 2021. So we do a plugin workaround. We installed: https://wordpress.org/plugins/webp-converter-for-media/
WebP Converter for Media – Convert WebP & Optimize Images is a free plugin from the WordPress directory of over 60,000 open-source plugins.
The bogus promise in the plugin description: Remember that a better-optimized website also affects your Google ranking.
No it doesn’t. Not again. Shocking how the WebP propaganda runs so deep. But why would this plugin author lie to us? Oh, no. He drank the toxic Kool-Aid, too.
We convert the JPEG image installed on the page to WebP using the conversion plugin default settings. We then purge the LiteSpeed cache.
WebP image -after results.
The image is now a 31K WebP format derived from the same original PNG. A little lighter than the other online tool WebP conversion. 36.8 percent lighter than the original PNG image. Bonus.
Seriously! Slower after conversion to WebP conversion. Wasn’t it 36.8 percent better in goodness?
So? WebP conversion made zero difference in WordPress speed.
WebP Test Two
Let’s get super serious and torture test.
We download a huge open-source jaguar image from Pixabay. Weight: 4.1 megabytes. Dimensions: 5616 x 3744 pixels. A monster size image. It would ruin page speed in the good old days of site-building. We upload it “as-is” without any preparation.
Uploaded as a featured image: WordPress does it’s magic and resizes the huge JPEG to: 1366px × 911px (scaled to 1166px × 777px). It also changes the JPEG compress quality setting to 82. Final result: 223.78 kilobyte featured image — not the original 4.1 megabytes.
No image optimization plugin did that. WordPress core did. 4 megabytes down to 224 kilobytes. Think about that. Wow. WordPress protects you from overloading your site with bloated images.
The WebP plugin wouldn’t convert a featured image. It failed. We decide to try an inset image in the page body in stead for testing.
On the page, we inset the huge JPEG image. WordPress automatically converts it to:
JPEG: 1024 × 683 pixels. (scaled to 608px × 406px by the browser) Weight: 114.46 kilobytes.
Inconsequential, insignificant speed change from WebP.
Let’s check some more numbers with speed test results instead of a timer.
WebPageTest.org: TTFB: 329 ms load time: 624 ms.
Now let’s uploading a properly-sized JPEG image so the browser and WordPress don’t have to do resizing or scaling. We use GIMP free image editor using save for web GIMP plugin features.
68.2 kilobytes 608×405 pixels optimized.
It’s then changed some more by WordPress during upload. The only change is a slightly smaller weight: 66.6 k. We take another measurement:
You Probably Don’t Need All That Stinking “Data.”
Google Is Not the God of the Internet!
Gathering Your Fans: Email Service Providers
