Loading plugins redundantly and globally decreases the speed of your pages. It’s best to deactivate heavy plugins on pages where they’re not needed. JavaScript, CSS files, and SQL queries are then reduced during page load.
Selective deactivation means you can conditionally disable heavy plugins to speed up page load times.
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. And a 79.9 millisecond delay. Everywhere. 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 than Contact Form 7. 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. SpeedSwitch plugin allows you to selectively activate or deactivate a plugin using the post or page URL, the address of a World Wide Web page.
Any residue database is removed on SpeedSwitch deletion. It won’t bloat your database. It works with PHP 7.4 and up. The first line of code is a security check.
DISCLAIMER: SpeedSwitch may not work on managed WordPress hosting like Pressidium or WP Engine. They don’t allow the one-time writing of plugin information to their servers. Not nice.
Other SpeedHospital Proceedures
KrunchKore Extra collection of 11 discrete plugins to strip or disable unneeded and unused baggage. This rescue kit includes an…
Instant-jQ lets you use faster universal cached resources for better speed. WordPress theme developers normally use the resident jQuery included with WordPress. It reloads fresh every time someone visits your site. This is inefficient.
Before a browser can make a page, it builds the HTML markup. If the browser encounters a CSS script or JavaScript, it must wait for the scripted resource to download. That pause increases latency for page rendering.
JavaScript is a client-side, dynamic-scripting, program language. Web programmers use it to alter displayed page content. JavaScript is one alternative to using server-side PHP scripting language.
jQuery is a free, open-source, cross-platform JavaScript library. It deserves special attention and treatment. This library is used in the creation of dynamic web pages and web applications. WordPress theme developers normally use the resident jQuery included with WordPress. But just because it’s there doesn’t mean it’s “always on.” jQuery activation is optional – such is the case in the GeneratePress v2.0 theme and other fast loading themes. jQuery activation isn’t the default with these speed themes.
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 WebPagetest.org.
For example, the GeneratePress theme is fast but if you add a jQuery-activating slider plugin, suddenly all site pages will slow down. It defeats the purpose of using themes that don’t use JavaScript. The same thing will happen if you use the popular Contact Form 7 plugin. JQuery is then loaded globally for every page, not just your Contact page. Other contact forms, like Very Simple Contact Form plugin, do not require jQuery.
One of the bigger benefits of using jQuery is the seamless handling of cross-browser issues. JavaScript usage differs among browsers and can cause difficulty. The authors of jQuery have made JavaScript programming work much easier.
Google’s jQuery is cached in every browser on the planet.
You can change the WordPress code to substitute Google’s CDN hosted jQuery. But there’s an easier way. Just use Instant jQ plugin. 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.
Instant jQ plugin has a failsafe or fallback. If Google jQuery doesn’t respond, the plugin just loads the slower, local WordPress version.
Potential performance benefits for mobile speed.
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.
Letting Google handle part of your site’s JavaScript footprint free of charge is too good to pass up. It’s an easy optimization because Google CDN has a vast caching advantage.
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 Instant jQ 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.
BEFORE
Load time of WordPress resident Gzipped jQuery files before adding Instant jQ plugin. Two files: 97 milliseconds and 55 milliseconds loaded in parallel.
AFTER
Two minified files are loaded when using Instant jQ plugin. One from Google, the other from CloudFlare CDN. There’s a high probability they’re already in the browser cache. Each file loads in 5 milliseconds in parallel with other assets. The page weight is the same but delivery is faster.
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 Instant jQ plugin.
Note: A rebuttal/rant about this approach is explained in the article, “Why Loading Your Own jQuery is Irresponsible” Be sure to read the comments. They explain why “The WordPress Way” isn’t always the right way.
KrunchKore Extra collection of 11 discrete plugins to strip or disable unneeded and unused baggage. This rescue kit includes an…
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 we offer 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 GTmetrix.com
Here’s a screengrab of a Pingdom speed 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 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 – a red “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 speed 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:
LongCache plugin adds 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:
Enable the LongCache plugin.
Set the expiration to 365 days (yes, 1 year).
Select all of the file types you are using.
Select Gzip compression.
Save.
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 speed 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.
Other SpeedHospital Proceedures
SpeedSwitch Loading plugins redundantly and globally decreases the speed of your pages. It’s best to deactivate heavy plugins on pages…
