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.
“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
But, WebPagetest.org doesn’t. Why? Maybe WPT.org feels like we do: Better scores aren’t equal to speed changes.
Removing Query Strings makes a significant improvement in page speed. That’s the claim anyway. We’ve never seen “significant” speed improvement. That word “significant” gets used a lot with speed test braggadocio. The word should shoot up a suspicious red flag. The removal-suggestion always changes your speed test score. Big deal. Scores aren’t the same as load time gains.
A lot of speed technical stuff is hot air. Nerds puffing their chests out to prove who’s the biggest and best nerd. Removing query strings is one of those technical things that doesn’t make much difference in the world. But speed tests insist it’s important for a good score.
Usually “query strings removal” improves load times by milliseconds – and not seconds.
IMO it is recommended to ignore 50% of the Google PageSpeed recommendations, this is one of them:
‘Resources with a “?” in the URL are not cached by some proxy caching servers. Remove the query string and encode the parameters into the URL for the following resources…’
… the chances of any page of any small or medium site being cached – and reused from the cache is minimal. … removing static resources is not worth the zero speed improvement your site will gain. Author – Mark Kaplun
So, what the heck are Query Strings?
Query strings are the URLs containing special characters such as “&” and “?”.Scripts and stylesheets often contain a modified URL to identify versions.
Query strings can help track users like HTTP cookies. Query strings are often used in association with web beacons. Google Analytics uses web beacons (a 1-pixel, square, transparent, GIF image). A web beacon is an object embedded in a web page or email. It allows checking that a user accessed the content.
What’s cache busting?
Speed improvements do not improve SEO. They improve UX. Google doesn’t use PageSpeed test scores in it’s ranking algorithm. They use TTFB (time to first byte). TTFB is host-server access-time – a speed overhead measured in milliseconds.
Browsers store a cached static file until an expiration date. The file version in your visitors’ browser may prevent seeing new changes.
Cache busting solves the problem with a unique file version identifier. This tells the browser a new file version is available. Then the browser doesn’t retrieve the old file from cache. Instead, it makes a request to the original server for the new file.
The query string is a method for plugins and themes to pass version details about new updates. This trick is a plugin author’s workaround or “cheat.” It’s not best-practice. And may have a theoretical impact on website loading speed. Removing the query string from the file name “fixes” this without harm. But in reality, it only improves your speed score – and not the milliseconds of extra load time we yearn for.
You can remove query strings from files – without touching a single line of code.
Below, we give a list of free, lightweight plugins that do the job for you. No longer. Sorry all these types of plugin have been removed from the WordPress Directory except one. These plugins need no configuration. They’re all plug and play. Install and you’re good to go. Make sure to clear your cache after installing to see changes. You can download the plugins from the WordPress repository. Or by searching within your WordPress dashboard under “Add New” plugins.
These plugins search all static files loaded from plugins or themes for “?” or “&”. Then removes them. This won’t damage website functionality. It helps your website get better page speed scores. It may even help make your site faster. But better speed is rare.
These plugins are super lightweight and usually benign. You may see millisecond improvements. There’s no reason not to install one for speed.
The bottomline is: removing query strings does no harm – but the only benefit most likely is an improved test score – not speed. Of course, the question is, “Why do speed tests insist it be done?” It’s ivory tower idealism.
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 (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.
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.
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!
Our performance budget is under a 2-second load time – or 2000 milliseconds.
Never activate SSL on a site for mere search engine optimization purposes. It’s only needed when doing electronic transactions for eCommerce. HTTPS / SSL slows down every page by a half-second. Think before you leap. You can’t remove SSL without ruining all your Google links. We rebuild websites to cut 500-millisecond SSL site drag. It’s painful.
What 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!
“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)
Settings Image Overlay: Select Show
When Image Overlay is set to Show, the following options become available:
Image: Set your static overlay image from the media library (an optimized JPEG you choose).
Lazy Load: Set to YES.
Image Size: Set to full.
Play Icon: Slide to YES to show a Play Icon (triangle in circle)
Lightbox: Leave off.
This defers loading of video resources until the user clicks the Play button. Lazy load replaces the video embed code with a lighter weight static image of your choice. And an optional play icon on top of the static image. The video is only loaded when the user clicks the image.
This speeds up the initial page load time by 500 milliseconds (typically per video on a page).
Note: Videos will not autoplay if an Image Overlay is set. You don’t want autoplay anyway. It’s considered intrusive and bad user experience. Let the user choose to activate the video sound and play.
From surveys, the top three biggest challenges for WordPress users are: 52% performance issues, 41% security issues, 35% site-breaking updates. NOTE: These are all fear related – not reality related.
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 the SpeedXRay plugin 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.
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 pagebuilder 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
wood 63.94k, -98% savings
Size limit = 10MB, 2,000px wide, Cropping or resize option.
PagePipe’s quick-test criteria.
We’re only interested in compressing photograph files. The online compressor is best if it works for two different samples: a large digital camera file and a smaller web banner. Both JPEG images. Specifications for test images are below:
The software needed for image optimization must be only the browser. No other programs or plugins; such as Adobe Air, Windows Only, Flash, etc.
We want to upload the test images by browsing or drag-and-drop.
We consider it a bonus if the browser imaging tool has an image resizing option.
The tool must work. Seriously? If it fails, it’s off the list.
We’re only interested in lossy compression for the most page-weight reduction. Lossy is a type of compression where a certain amount of information is discarded. It is best. 50 to 70 percent reduction in file size.
We prefer optimizers with reduction control in steps of 10-increment quality settings. 90Q down to 10Q range. We pushed down to 10Q for testing when possible.
The 7 random losers.
We’ll share these just so you don’t wonder if we tried them or not:
Smush We’ve used smush before. It’s part of Yslow performance measurement tool by Yahoo! It never makes much of a difference. There are better alternatives. Many swear by this method. We don’t think it’s that cool by comparison. On the test, it failed to upload the images. We tried again – and gave up. We didn’t care that much. You only use lossy settings on the pro version. The free plugin has 10 percent reduction. That isn’t good enough.
Kraken.io We think Kraken has potential with the WordPress plugin version. But the online browser version doesn’t allow you to make quality settings. Our trees-rocks test image only compressed by 12.4%. Unimpressive. And the larger “wood” image wasn’t allowed. They said for that size we’d have to upgrade to Pro version with an upper limit of 16MB. Forget it!
RIOT (Radical Image Optimization Tool) For Windows only. Disqualified.
Puny PNG FAILED uploading and gave an error message. “Sorry, there was a problem with the image(s) you are uploading. Please ensure your image is a supported format and complies with your quota.” Our images worked fine everywhere else? Go figure. Yes. We tried more than once.
Shrink O’Matic Desktop app for Adobe AIR. Disqualified because it requires more than a browser.
TinyPNG – 5MB limit Has a 5MB limit and made no difference. “Zero Percent” change on the trees and rock image.
Compressor.io Compressor.io didn’t cut it either. trees – rocks only compressed by 24%. That’s not good enough for us. The “wood” image was better (-72%) but no resizing option. It wasn’t of much value for those big, fat digital camera images.
Slow speed is caused by images that aren’t optimized. It’s a trade-off between file size and image quality. Learn about proper image optimization. Heal the Internet.
72k, 8-page, 8.5 x 11 inch, printable b&w
There is no one-size-fits-all solution for image optimization. No common formula. That’s why robot-plugin optimization is usually too conservative and overcautious. They don’t compress enough. The human eye is the best judge of how much is enough. Every image is different in potential gain. Only optimize on your 10 most important landing pages. You don’t need to worry about every image site wide.
Even though you could squeeze an additional 200k of image weight from the homepage, it wouldn’t make a significant difference. Why? Browsers load images in parallel.
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.)
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.