We demonstrate a common but little understood speed problem usually labeled as Leverage Browser Caching. Various tests report this fault condition slowing down pages. But they don’t explain much about what it is and how to fix it. It’s pretty simple – and there’s a nice plugin solution.
There are various sites for testing page speed. Our favorite is WebPagetest.org. It’s a popular place so you usually have to wait in line – plus their test is pretty comprehensive adding more delay for results. Our go-to test for faster quick-and-dirty results is Pingdom.com – and after that GTmetrix.com
Here’s a screengrab of a Pingdom test for an optimized site:
The test says there are two “failures” (big red Fs). Those are #1 Minimize request size and #2 Leverage browser caching. That seems like pretty harsh criticism for a page that loads in only 658 milliseconds on cheap, shared GoDaddy hosting. We soon discover the bad review isn’t really warranted. Let’s take a closer look by expanding the “accordion” performance insights:
We almost laugh out loud at the itemization of errors. First, there’s only one URL that doesn’t fit into a single packet causing the first error condition: Minimize request size. And that’s an HTTP request call to Google CDN for a webfont. Completely beyond our control and something Google should care about more than us. Let’s move on and just ignore that single call. But talk about harsh – an “F” (41).
The second category,Leverage browser caching, says there are 6 errors. Five are image files and the last file is another Google font. Again, we have to ignore the errant Google font.
Note: A simple font solution would be killing (removing) Google fonts and use the native browser fonts in the CSS stack. We could do this with Remove Google Font References plugin. But we feel the fonts add to the page “style.” The pages are pretty fast already and load time is more important than getting a good Pingdom score.
So how do we get rid of this Leverage browser caching problem? They give us a hint with the instructions:
The following cacheable resources have a short freshness lifetime. Specify an expiration at least one week in the future.
What does that mean? They are talking about a web speed trick called far-futures expiration. It is a best-practice for speeding up your website by using Expires or a Cache-Control Header. This is server-side coding that is added in the .htaccess file that resides on your server. There are many tutorials on how to do this manually. But if you are inexperienced at editing these kinds of files via Cpanel or FTP, we have a simpler, automated plugin solution. Read on:
This plugin appeared abandoned but it’s author returned and updated it recently. While this isn’t always necessary, it’s a good sign the plugin is “fresh.” We’ve used it for years.
This plugin will add a “far future expiration” date for various file types (like image files) to improve site performance. This is a best practice advocated by the Yahoo Extreme Performance Team. It keeps files and images cached longer. There is also a radio button to enable Gzip – a nice addition. (More about Gzip >)
A first-time visitor to your page causes many HTTP requests, but by using the Expires header those components become cacheable. This avoids unnecessary HTTP requests on subsequent, repeat page views. The web server uses the Expires header in the HTTP response to tell your visitor’s browser how long a component can be cached (stored).
The Expires response header gives a date when a page component becomes stale.
Using a far future Expires header affects page views only after a user has already visited your site. It has no effect for first-time visitors and the browser’s cache is empty. The impact of this performance improvement depends on how often users return. About half of your users or more could be return visitors.
Your server’s .htaccess file can be appended by using some simple plugin settings:
The plugin doesn’t add page weight to your site. We call this a “weightless” plugin.
Will you see a speed improvement? It depends. If you didn’t have Gzip already activated on your server, you will see a big improvement. You’ll have a better Pingdom test result. Returning visitors will have a better user experience because images and other assets are already on the browser cache waiting. You’ve paid homage to a theoretical speed improvement. The effort to make it happen is minimal. So why not just do it? We do – always.
Leverage Browser Caching score is now an “A“. The only file that can’t be cached is the webfont from – ahem – thanks, Google.
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.
★★★★★ Super Simple Google Analytics Active installs: Fewer than 10,000 Zip file size: 31k All-time downloads: 108,457 Retention rate: 9 percent (low)
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).
Tip: We use a popular-post plugin to build a database of what is trending on our 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 Active installs: 2,000+ Zip archive: 5.2k Retention: 24% Last updated: 1 year ago
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.
For tracking article popularity, we use WP Popular Posts plugin’s dashboard settings to view stats on all of our posts:
★★★★★ WordPress Popular Posts Active installs: 300,000+ Zip archive: 122k Retention: 11% Last updated: 3 weeks ago PHPv7.1 compatible
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.
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 the Codium Grid theme, we found Cloudflare doesn’t guarantee consistent load speeds. During this project, 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 results in WebPagetest.org. Our cached time improved from 750 milliseconds to a 500-millisecond load. We’re giddy from this discovery.
Christian Nelson, ally and web critic, saw this weird, random, delay phenomenon years ago – but not only on Cloudflare. He’s maintained a low opinion of CDN solutions since. He’s right on the money. CDN response times can be unpredictable.
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.
Now, on Shopify – one reason they have such fast loading stores – is the big money they throw at edge optimization. That’s the best place to host and build a store. That’s our recommendation. And we get paid to build ecommerce sites with WooCommerce. It’s no match in the speed department.
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.
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 and 501 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. 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.
Removing Query Strings From URLs With Free Plugins
Remove Query Strings From Static Resources 100,000+ active installs, compressed download 2.5k. We don’t recommend this one any more (see below at end). This plugin killed a test sites mobile pages but not desktop with unstylized CSS.
Query Strings Remover 9,000+ active installs, compressed download 1.6k. This was our favorite – but it is no longer in the directory. It was removed for noncompliance to WordPress rules. Who makes those rules?
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.
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.
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!
Lazy loading is a technique for deferred loading of page content. It’s loaded when it’s needed rather than all at once – typically by scrolling through the page.
With lazy loading, pages are created with placeholder content which is replaced with actual content when the user needs it. Lazy loading is a technique that increases user time spent on a page because the new content loads automatically.
Lazy Loading is good because it delays loading of images below the fold. It’s a good trick.
But it can give us lousy UX as slow images on mobile devices leave blank spaces. Images eventually appear when scrolling. (We use lazy loading wherever and whenever possible anyway).
Go to Settings > LazyLoad and check the 3 boxes to activate. This will then lazy load:
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 have also 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.
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.
“A single YouTube embed can load up to 400KB of data before you even hit the play button.”
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.
As the name suggests, Infinite Scroll continuously loads content as the user scrolls down the page. The page’s footer – normally inaccessible in an infinitely loading web page – is displayed as an overlay beneath the scrolling content. WordPress claims that users read more posts when Infinite Scroll is enabled, as opposed to the traditional page-based approach. Infinite scroll plugins are hard to get to work with some themes. We’ve never had success with them on stripped-down speed themes. But we’ll keep trying. Here’s a list:
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.
Apopular WordPress form plugin is installed on over 1 million WordPress websites. The favored culprit is Contact Form 7. It adds 37k page weight to all pages on your website. Even when the plugin is only used on one page – such as your contact page – the plugin “globally” slows down all pages. This “global” activation is even more problematic for heavier plugins like Google Maps or social media controls. We call global plugin activation “site drag.”
Other form plugins are lighter and faster. But substitution isn’t the solution or our main concern. What if we absolutely needed to use Contact Form 7 plugin because there is a special addon plugin that gives us more extended utility (And, there are addons!) How can you prevent global loading?
We fix it with a plugin that restricts a “heavy” plugin to just the pages where it’s needed.
both let you deactivate or activate plugins on a page-by-page basis.
Update: We’ve located two others we haven’t tested yet – but they have potential. We’re surprised these have more downloads than Plugin Logic. Both are a heavier download. Once again, we see how product naming affects findability in the plugin directory.
★★★★★ WP Asset CleanUp (Page Speed Optimizer) Active installs: 10,000+, Zip archive 1.4M
With these plugins, you can selectively disable plugins by any post type or WordPress-managed URL. But if you’ve read our recommendations about plugins and themes, you know we usually choose the lightest plugin when possible. Smaller file size usually equates with efficiency, which means it will probably load and work faster.
You don’t need to buy the $29 Gonzales plugin. Use one of these four alternatives instead.
Of the four plugins, Plugin Logic (only 100+ active installs) is the simpler and easier to use. It hasn’t been downloaded much yet compared to Plugin Organizer (10,000+ installs). Using the Plugin Organizer is more complicated because it let’s you change the plugin load order. Changing the load order can help prevent plugin conflicts, which is a nice bonus feature if you need it – but we don’t, so we’ll stick with Plugin Logic.
While our main focus is page-speed improvements, here’s another example of how plugin deselection can help:
We’re using the WP Image Borders plugin (266k compressed download) on a client’s website. It makes it easy to add image borders to pictures on pages or posts – but activation is global. The plugin adds borders to images on all pages.
But we don’t want borders around every image – as in the case of these circular buttons show here – the border ruins the look. So we deselect the border plugin for just that page. Problem solved.
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.)
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.
Calculating retention rate is a better indicator of usefulness – rather than popularity (active installs). To determine ballpark retention rate: Take “active installation” from the plugin page. Let’s say it’s: 200,000. Then click on “advanced view.” And scroll down. Get the “All-time downloads:” Let’s use: 2,560,081. Do the math division. The result is 7.8 percent plugin retention rate. Less that 8 percent of the people who tried the plugin kept it. Not great.
Rule of Thumb: Below 10 percent is low retention. 10 to 25 is OK. 25 to 30 is good, and 50 percent is excellent.
Plugin quality can’t be judged by “last updated” any more than “active installs.” Retention is a better indicator than popularity or freshness. 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.
One of the faster free themes we’ve experimented with and reviewed is Frank Theme. It uses the “Don’t use jQuery” speed strategy. The same goes for the Sobe theme. And also, more recently, GeneratePress v2.0.
jQuery is usually one of the biggest chunks of WordPress code. It deserves special attention and treatment.
Optional WordPress plugins may use jQuery for animation like sliders or other interactive elements. So the theme may not use jQuery but a plugin might. You can know for certain by testing with Pingdom.com or WebPagetest.org.
Almost every browser on the planet already has Google’s jQuery CDN address loaded in cache.
You can change the WordPress code to substitute Google’s CDN hosted jQuery. But there’s an easier way. Just use WP jQuery Plus. It’s a WordPress plugin that loads jQuery from Google’s free Content Distribution Network (CDN). Users geographically far from you can download jQuery faster. The Google version of jQuery is also Gzip compressed and minified for fastest page loading. Yet, even though Google’s CDN servers are fast, it’s still not the biggest motivating gain.
Note: An alternative Use-Google-Libraries plugin exists but WP jQuery Plus is better because it has a failsafe or fallback. If Google jQuery doesn’t respond, the plugin just loads the slower, local WordPress version.
Potential performance benefits:
Using the Google Library CDN eliminates some HTTP requests from your site. This allows more of your local content to downloaded in parallel. It doesn’t make a gigantic difference for users with a modern six-concurrent connection browser. But for those still running older browsers, the difference is noticeable.
The greatest benefit of using Google’s CDN is that your users may not need to download jQuery at all. The chance is high that a user already has these files cached for up to one year.
No matter how well optimized your site is, if you’re using a local WordPress jQuery then it must be downloaded at least once. If forced this way, the user’s browser ignores dozens of identical copies of cached jQuery.
CDN-hosted jQuery references refer to the exact same file. The browser trusts those files are identical and won’t waste time re-requesting the cached file. Thus, the browser uses only a single copy that’s cached on-disk, regardless of which site the CDN references appear on.
Google’s CDN serves the jQuery file with headers that cache the file for up to one year. This creates a potent effect of “cross-site caching.”
The most trafficked sites on the Internet already use the Google CDN to serve jQuery. Many users will never have to make a single HTTP request for jQuery. It only needs downloading once before.
Note: If your theme and a plugin both use jQuery, your pages may end up with jQuery loaded twice causing even slower pages. The only way to know for certain is to check using Pingdom.com or WebPagetest.org.
Some claim the WP jQuery Plus plugin isn’t a “real” speed fix because it’s small and inconsequential. jQuery by itself is 91KB when it’s minified and further optimized to 33k with Gzip compression. For many, this 33k footprint left by jQuery is insignificant when the average homepage is a heavy 2M to 3M page weight. But if page weight is efficient (around 100k, for example) jQuery weight becomes one-third of the page weight. That’s significant overhead. Plus, do you know how to minify and Gzip your site? If not, this is a easy solution to reduce a 97k load by over 70 percent.
Increased parallelism is sometimes argued as an invalid benefit of Google CDN since there’s a WordPress-coding workaround: Just load jQuery in the footer rather than the header. This way pages load scripts faster. For WordPress, it’s done by editing the functions.php header code. But there’s no plugin for this code change. It requires some bravery and skill. We just don’t recommend it – even if it makes the plugin unnecessary.
The genius for this speed strategy is the pervasive ubiquity of the Google CDN address in browser caches. We recommend you try out the WP jQuery Plus plugin and test if it speeds up your page load times.