With over a million sites using our plugins, one of the things we know all too well is that there is no such thing as a one-size-fits-all solution. From the beginning, SWIS has included a flexible rules engine (Slim) to let you disable JavaScript and CSS that isn’t being used on any given page. But when it came to options like Optimize (defer) JS Loading, you could only exclude scripts site-wide.
Before SWIS was built, I knew from experience that some scripts, like jQuery, can be deferred just fine on some pages, but not all of them. As soon as you introduce some inline jQuery (JS) code, things fall apart in a bad way. So what if you could use the Slim rules engine to customize JS defer?
JS Defer Rules
In version 2.0, when you enable Optimize JS Loading, you can use the Manage JS/CSS panel from the front-end SWIS menu to do just that! With the new Slim rules integration, you can limit JS Defer to a single page, a group of pages, custom post types, or even use full-blown regex patterns for more complex scenarios.
The Slim rules work either in an additive mode (defer on these pages), or a subtractive mode (defer everywhere except these pages) for the ultimate in customization.
Defer Made Safer
As mentioned, one of the biggest problems with deferring JavaScript is when you have inline scripts that depend on the external JS files. This is because inline scripts run as soon as the browser receives them within the initial page load, but deferred JS doesn’t run until the initial page load is complete. To combat this, SWIS would detect inline jQuery code and automatically prevent jQuery from being deferred. Which is great for jQuery, but there are lots of other cases where SWIS can’t catch potential breakage.
With that in mind, we’ve taught SWIS a few new tricks, and now it can defer inline scripts too! This means that all JS is run after the page load is complete, and in the correct order. There are some inline scripts that don’t need to be deferred, and SWIS will ignore those automatically. However, if you don’t want any inline scripts deferred, you can add ‘inline-scripts’ to the exclusions… Or you can even use Slim to prevent deferring inline scripts on specific pages.
Break Delay Your JS
Okay, we really hope you don’t use this to break the JS on your site. However, I have to say right up front that the JS Delay feature is both powerful AND dangerous.
The first thing you might ask is, “where is the Delay JS option?” Before we get to that, let’s talk about what it does. SWIS can already defer all JS so that it doesn’t block the rendering of your page. Delaying takes this to a whole new level, and prevents JS from loading at all until the user does something on your page: clicking, scrolling, moving the mouse, etc.
Why Delay JS?
The potential here is pretty cool. JS can slow a browser down, and delaying JS loading & execution makes sure all resources can be used for the critical job of rendering the page. It’s also a cheat code, because it hides your JS from speed tests and search engines, makes your site look faster than it really is, and can drastically increase your score on page testing sites.
Why Not?
That might sound exciting at first glance, but what if you have a menu that opens on hover? That menu is using JavaScript to detect the hover event, and if the JS has been delayed, you start to get weird behavior, and your user is stuck there wiggling their mouse until the JS kicks in. Especially if you have a lot of JS, imagine what’s going to happen to the browser when it has to download all of that JS and run it as soon as someone clicks, scrolls, etc…
You might have other animations on your site (like we do), and if those are delayed, the page will come to life “all of a sudden” when the user moves their mouse or touches their screen. Content might jump around unexpectedly, and how many times have you almost punched your computer when something moved right when you tried to click on it? No one? Is it just me??
Seriously, we all hate that, and Google hates it because we hate it, and eventually the clever folks at Google are going to find a way to trigger user interaction via their search bot… and then a LOT of site scores are going in the toilet. Plus, lots of your visitors use Google Chrome, so guess what? Google is already tracking how your page behaves for real users (including layout shift) and feeding it into their search algorithm.
Delay it Right!
Alright, I’m done ranting, so let’s get back to how cool this thing is! For all the reasons listed above, SWIS does not allow you to delay ALL your JS. Instead, SWIS gives you the control to delay any JS file on your site using the same Slim rules. You can customize each JS file, on specific pages, or even site-wide. Have some JS that is used to submit a form? Delay it, and it’ll load while the user fills in the form, ready to go when they are.
You can even delay the inline scripts on your page, but watch out for errors. Sometimes inline scripts work great delayed, other times they’ll throw a fit if the script order is changed by delaying them. Which leads us to another new trick SWIS learned.
Catch JS Errors
With all this flexibility and control comes the possibility that you might just break something along the way. If you know how to use the developer console in your browser, that works great. But what if you forget to check the console, and you just added three new Delay JS rules, and now you don’t know which one caused the problem?
The Slim panel now shows you as soon as it detects a JS error. Of course, you still need to refresh the page after each change that you make. But right at the top, you’ll now have an alert if you’ve broken anything, and can undo your changes right away.
Slim More…
Sometimes developers do silly things, like ignoring the standard way of adding JS and CSS to your pages. For a while, SWIS has been able to find non-standard JS/CSS files and defer them as well. With version 2.0, these non-standard assets are still deferred, but now you can also use the Slim panel to Disable those JS or CSS assets, apply page-level Defer rules, or even Delay them wherever you like.
and Slim Less
Some plugins, like SWIS itself, use JS on the front-end to enable site administrators to do things without going into the admin side of the site, or even to perform tasks that can only be done on the front-end. Naturally, we can detect our own JS and hide it from the Manage JS/CSS panel so it isn’t cluttering things up. But what about the other 60k plugins out there? What if they’re using front-end admin JS, and you’re not sure which resources are actually used for your visitors?
SWIS will run a quick check as a logged-out visitor, and then compare that with what was found while logged in. If your site isn’t using a JS or CSS asset for visitors, then SWIS will hide it from the list. Naturally, you might want to check those anyway, just to make sure. So you’ll see a handy notice that some assets have been hidden with a button to show them all.
JS or CSS that is only visible for logged-in users will then have a nifty lock icon in the Status column so that you can easily find them.
Test Mode
Have we mentioned that messing with your JS can break things? Oh right, of course! Wouldn’t it be neat if you could mess around with the SWIS options and Slim rules, and not worry about breaking your site for your visitors? Well, I think it would be fantastic, so I added a Test Mode option that disables all JS/CSS related functions for visitors, and only makes SWIS effective for you as a logged-in admin.
So go ahead, kick the tires, get a little dirty, and have some fun learning how your site works while SWIS helps you make it even faster than before. Just remember to wash your hands and turn off Test Mode when you’re done!
