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.
After downloading SpeedSwitch, install it by uploading the zip file from your computer.
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.
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.
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.
Our performance budget is under a 2-second load time – or 2000 milliseconds.
W matters is load time for best user experience. Scores are meaningless. Performance grades don’t affect SEO. Page size affects mobile bandwidth and data rate consumption. The number of requests doesn’t matter as much since they often load in parallel.
The YouTube video preloads fonts, ads, tracking beacons, recommended videos, etc. The heavy load added by one single video slows a page around 500 milliseconds. The best solution is to lazy load the video using a plugin.
Twenty nineteen theme doesn’t load Google fonts. This is a speed benefit. A mobile system font stack loads fast. The authors designed Twenty nineteen for mobile users and speed.
Speed improved 50 milliseconds with caching. A 10 percent improvement for extreme optimization.
The heaviest plugins in this tutorial load in around 17 milliseconds. Very fast. Many are less than one millisecond. WordPress core is 120 milliseconds. The Twenty-nineteen theme loads in 15 milliseconds. Twenty nineteen is the fastest theme on the planet – once stripped using plugins. No coding needed. Amazing!
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
Image optimization and webP implementation
Render-blocking script and above the fold optimization
CDN and Cloudflare 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 GT Metrix or Google PageSpeed Insight test scores are not an indicator of a speed professional. Those are tools used most by pretenders and wannabees. Sorry.
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
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.*
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.
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.
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 services like CDN
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.
There are at least 8 noteworthy WordPress speed service competitors:
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.
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.)
“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.
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.
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.
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.
Lazy Load for Video Plugin
LazyLoad XT Plugin
BJ Lazy Load Plugin
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.
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.
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: 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.
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.”
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.
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.
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.
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 Tiny Hestia. And the Twenty-nineteen default theme. Out of the box they enable mobile font stacks defined in the style.css file. They don’t use Google Fonts. Fonts have a stigma for mobile. They consume unnecessary bandwidth and data limits.
Single-column, 350-pixel wide images or resized images are what’s served up. All that matters is legibility and readability. Creating any mood is from color choices. Color combinations recall memories. Memories have feelings associated with them. It’s a subconscious influence.
How much “mood or emotion” can you muster in a small 5.5-inch screen space? Be honest. Small blocks of color whizzing by with the flick of a thumb. That’s mobile user experience? More like roulette.
Stripped-down “speed themes” often don’t enable jQuery by default either. If you resist the temptation to install a slider, top-of-page button, or some other jQuery intensive plugin, you avoid the extra load. Themes did this in the past (like Susty, Frank and Sobe themes) but were seen as esoteric or fanatic and not well received. Now it’s a mainstream trend. The Herd wants extreme modifications because they suppose speed will save their site. Speed never compensates for poor content. Ever.
Discarding font baggage and jQuery are nuances for speed. They make for fast themes. But you can destroy that with a few popular plugins. Then the gain is minuscule by comparison. Dwarfed by thoughtless plugin abuse.
Fussing about choosing Google Fonts is wasteful.
Theme authors retrofitted speed change based on requests from users. The demand was high enough and thus offered the chance to sweeten the deal.
This means 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.
“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
“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.
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.
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.
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 #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.
There is likely no “perfect” host, but now you have information to help you choose web hosting more wisely.
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.
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.
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.
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.)
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 currently supported by all browsers, including Apple browsers like Safari.
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
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.
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?!
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.
If you enjoy our caustic speed articles, you’ll love our pithy bi-monthly newsletter. Discover what matters most for mobile WordPress page speed. Fast load times require more than just installing a caching plugin – or CDN.
We’ll share with you our latest speed experiments and discoveries. Stay up-to-date with what matters for mobile WordPress page speed.
WooCommerce hurts speed. Freebie.
LEARN HOW TO MAKE MOBILE WOO FASTER 9 WooCommerce Speed Tips
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!
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.
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
Google Analytic code causes your site to fail two speed tests. And the test criteria are invented by the web-demigod Google. Yes. Contradictions in their very own self-acclaimed PageSpeed test:
How do you leverage browser cache when Google’s very own Analytics.js has it’s expiry time set to 2 hours?
Google Analytics usually adds three HTTP requests. And anywhere from 100 milliseconds to 500 milliseconds load time. It can be slower during peak hours. We’ve seen up to one second. But that’s uncommon. Speed varies in different parts of the globe. That means certain hours are better and some are worse for waiting.
Google Analytics is a freemium web analytics service offered by Google that tracks and reports website traffic. … Google Analytics is now the most widely used web analytics service on the Internet. – Wikipedia
There were times when we built 50k to 70k home pages for speed. Page weight today averages 2 to 3M. We coded lightweight sites by hand in HTML and CSS. Today most site owners use CMS like WordPress to build websites.
Back then, adding Google Analytics added about 31k to the page weight. This, of course, was a horrific detriment to good speed. Today, Google serves a Gzip-compressed version weighing 13k. Much better page weight.
In 2010, Google introduced a third-generation asynchronous tracking code. This helped speed immensely – and in time for the Internet mobile revolution. But, does that mean Google Analytics code has no impact on speed? Or is it significant? It depends.
The more modern alternative is using the Goggle API ID number and copying that into a plugin. This protects your Google Analytics code from being overwritten by updates. A safer approach.
But not all Google Analytics plugins are equal. Some cause server overhead that slows down your site indirectly. The page drag from these database-intensive plugins aren’t worth it.
If you need to look at Google Analytics statistics every single day or more than once per week, ask yourself: Why? What is so important about seeing the numbers and metrics so often? Are you obsessed? Spend time writing relevant content. Bring more qualified visitors to your site.
Header or Footer? Small decisions.
There’s a silly debate whether to place Google tracking code in the WordPress header or footer. Those obsessed with statistics say, “Put it in the header.” Those obsessed with speed say, “Place it in the footer.” Even Google’s different departments can’t agree where’s the best placement.
It’s reported pages load 100 milliseconds faster with the Google Analytics code in the footer.
Placing the code higher in the page theoretically decreases bounce rate. It’s claimed to reduce data inaccuracies as much as 5 percent – in some tests by Google Analytics-certified partners. Certified by who? Google partners! No conflict of interest there.
“If Google Analytics tracking code doesn’t load before a visitor leaves or clicks away from the page, the page data won’t show up in Google Analytics.”
Oh, dear. Statistical tragedy.
Pages load so snappy we don’t think users can determine content value that fast. And then navigate to the browser back button. Yes – that would technically be a bounce. But the idea of putting tracking at the top seems a moot point. By putting it at the bottom, you’re effectively lazy loading the tracking code. Lazy loading anything that delays page rendering is a good idea for speed. The slight chance of losing a minutia of visitor data is more than offset in the gain in display speed.
Isn’t the Google Analytics code cached in the browser?
If your Google Analytics code is slowing down your site by more than 1 second, something is wrong. You need to investigate how you’re managing things.On slow-loading pages, a browser status message may say “Waiting for google-analytics.com”. If this happens you’re running an ancient version of Google Analytics tracking code. Time to upgrade.
Which version of the code? OK. We’re being cynical. Maybe it is. Maybe it isn’t. It doesn’t make a difference if it’s cached by the browser. For some reason, Google Analytics interrogates the Google remote server anyway. What’s it looking for? That new version you don’t have cached? Or just reporting in for Google’s own nefarious snoopy purposes? We’ll never know. From what we’ve seen in tests: The ga.js communicates with Google servers even when ga.js is cached. At least once. Perhaps always.
Now, some *premium* hosts provide server caching. This can benefit Google Analytics code load time. But not always. The best improvement we’ve seen is a 50-millisecond load time. That’s about 6-times faster than normal shared hosting. Is it worth paying extra for that 50 milliseconds? Well, you will pay 10 times more for the hosting. So don’t signup for Google Analytics sake!
Some reports say the Google Analytics files are marked as “no-cache.” Others say they’re cached for 24 hours. The latest news is only 2 hours. We agree – it’s 2-hours from tests we’ve run. That is too short for any value to your return visitors. And online speed tests show that shortness is a failure. The majority of users are first time visitors. At the first visit, Google Analytics code loads at least once. It may not loaded after that (cached). But it’s part of the “first impression speed” for mobile users. It’s not uncommon for first-time visitors being 80 percent of traffic.
“… you can reduce your external HTTP requests to Google from 2 down to 1 and you now have full control over the caching of the file. This means you can utilize your own server’s cache headers.
You have also probably seen the leverage browser caching warning in Google PageSpeed Insights that comes from Google Analytics. This is kind of ironic seeing as this is Google’s own script. The issue is that they set a low 2 hour cache time on their asset … They most likely do this because if for some reason they were to modify something on their end, they want all users to get the changes as fast as possible. However there is a way to get around this, and that is by hosting Google Analytics script on your own server.”
AN ALTERNATIVE: HOST LOCALLY
Coding Jargon: Host the ga.js and __utm.gif file locally and execute the _setLocalServerMode() method.
Wow! That sounds complicated. But there’s a free plugin that does all this magic for you. Now, you can optimize Google Analytics. We’re using this plugin on PagePipe and other sites.
Note: When you do the CAOS method, your pages will fail various, odd online tests – not speed tests. The Google Analytics code won’t appear where the test *expects*. Your site’s OK. It’s the test that’s broken. Everything will appear normal in the Google Analytics dashboard and controls.
This plugin inserts the Analytics tracking code into the header or footer (you choose). It saves the analytics.js file locally. It then keeps it updated daily using scheduled automation.
Whenever you test speed on Google Pagespeed Insights or Pingdom, they’ll tell you to leverage browser cache. That’s because Google set the cache expiry time to 2 hours, it always fails the test. This plugin will get you a higher score on PageSpeed and Pingdom and make your website load faster. (Scores are nice – but saving milliseconds of load time is what really counts). No more roundtrip to download the file from Google’s external server.
Will the CAOS plugin make your website go from a 10-second load to a 1-second load? In Disneyland! Get real. It’s a small speed boost – but it’s worth it.
The Complete Analytics Optimization Suite for WordPress gives you the best of both worlds. This way you can minimize DNS requests, leverage browser cache, track your visitors – and still follow Google’s recommendation to use the latest features and product updates. If you’re using a CDN, you’ll need to use CDN Enabler plugin to host your Analytics-script (local-ga.js) from your CDN.
UPDATE: Let’s take a closer look at a real-world site, PagePipe! Below is a waterfall from WebPagetest.org:
With the CAOS plugin activated – the tracking occupies the space of 1.3 seconds to 1.7 seconds. (The site’s favicon also lazy loads. This happens when placed in the root of your host server – but that’s another topic). A little math and we see that it’s a 500-millisecond delay for Google Analytics to respond. Without Google Analytics, the site would theoretically load in 1.2 seconds. Let’s turn off Google Analytics and the CAOS plugin for a moment. What’s the real difference in seconds?
The page now loads in under 1.1 seconds. We can ignore that lazy-loaded favicon. So Google Analytics adds a repeatable 500 milliseconds to every page. That’s site drag! We’ve seen delays of over a second – but it isn’t repeatable. It’s random. Simply waiting in line.
So now we ask, “What is Google Analytics affect when using the Super Simple Google Analytics plugin?” Here’s the answer:
A 1.8 second load time is the result. Instead of 500 millisecond addition with CAOS plugin, it’s now a 700 milliseconds addition. 200 milliseconds more!
CAOS plugin saves 200 milliseconds. For mobile speed, that’s great. And optional loading in the footer is reported to save an additional 100 milliseconds. That’s 300 millisecond gain of total improvement.
The fastest loading Google Analytics: No Google Analytics at all.
Ask yourself, “Why am I installing Google Analytics?”
Now, some sites need Google Analytics more than others. For example, an ecommerce site. But a typical blog site usually not. And a vanity site, definitely doesn’t. Many site owners install Google Analytics code because everyone else does it. And then they never even look once at the metrics. Ever. All they did was slow things down – without any benefit.
Using too much data to make decisions is worse than having no data. Seeing that 35 people visited on Wednesday last week, do you care about that detail? Whoopee. The data provided by Google Analytics is massive and takes time to learn how to use. We drown ourselves in data and just sink deeper into the quagmire.
Google Analytics statistical data gathering is never 100% accurate. The data extracted is still subject to human evaluation, spam, and error of judgment. It’s like reading tea leaves, fortune cookies, or tarot cards. You *interpret* what your mind wants you to see.
There is no science to SEO (or even UX) since no one can prove the outcome was a direct result of the method. It’s professional guesswork based on experience and a moving target. Page One in Dallas does not ensure Page One in Seattle.
Data can twist your perception.
Because everyone else uses Google Analytics, should you jump off the cliff, too? Would you install a plugin because:
It’s very easy to use.
Everyone else uses it, so it must be the best.
It’s free. Who can argue with free?
Are these the right reasons for choosing an analytics tool?
What would your mother say about peer pressure?
It’s actually very difficult to get real insight. 25 to 33 percent of your traffic is non-human (bots). With Google Analytics, spam-bots get recorded as a real live visitor. Most ad-blockers and tracking blockers also block Google Analytics. Those things affect your numbers.
Google Analytics can be a time waster.
If we can’t define what “the best” or even “good enough” means, how can we say Google Analytics is the best solution?
Google Analytics is good for a baseline in projects. It helps ecommerce know what products customers searched for. And what they viewed when they got there. Most people don’t know how to read the data. Less than 1 percent of website owners know how to use Google Analytics. Let alone how to glean helpful information from all that data.
Google Analytics data won’t help you write better thought provoking content. Instead, it may twist your thinking to chasing the herd.
Most (major) web hosts give you the ability to read the server logs. There you get the basic traffic info you’d get with Google Analytics. And the best part is that it requires no script to load: it works on the server, not the client side. Those will show key performance indicators (such as bounce rate, page views, time on site).
“Yes – looking at analytics data over time is helpful. But do you really need to know if you had 100 or 200 visitors today? … Does any of that data actually do anything for you in the moment? Years of experience have taught me that it doesn’t.”
Our rule of thumb: Google Analytics adds at least 100 milliseconds to the first page view of your site. That page is most critical for mobile users. That can be 10 percent of wasted load time. Whenever possible, delete Google Analytics. Use either a plugin counter or Cpanel or server web statistics as a substitute.
We’re not against using Google Analytics if you need it. Read the data collected. Use it to make your site better. If you do that then keep Google Analytics on your site. If you’re never going to look at the data, speed up your site by removing this unneeded code from loading.
It’s claimed Google monitored bounce rate (via GA) affects SEO. We don’t believe it. We really don’t need more data. We get numbers from a plugin and server stats. They are fine and with no speed delays.
WP Counter is a lightweight, simple site visitor counter. See unique site visitor status in different date ranges. (Today, Yesterday, Current Week, Current Month). We’ve been using this plugin for months to see if it correlated with Google Analytics. Frankly, nothing correlates to Google Analytics exactly – but it was close enough.
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.
5Too many plugins slow down your WordPress website.
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.
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.
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
Test Camera Output JPEG Image
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
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:
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.
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.
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.
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 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.