I thought there was no way around this, so I was resigned to loading jQuery in my header as a render-blocking script. My focus was on reducing its impact on the page load times by loading it from a public library. Earlier, I was happy with what seemed to be WordPress’s willingness to dump jQuery for time-sensitive functions like the lazy loading of images.
I can confirm however, that if we have an inline script that says:
We simply need to change it to:
Making Changes to Plugins
Still, the benefit of being able to do this and deferring jQuery is so large, that it might be worth it. Using this, I was able to reduce my First Contentful Paint (FCP) times by more than 50%! And all with no loss of functionality. That’s a benefit I can’t afford to miss out on. I’ve made a note on which plugin files I’ve changed and will repeat the changes whenever they update.
I feel like I’ve finally won a battle with jQuery. I’ve lived with the fact of its existence in the header of my site for so long, and now I’ve found a way to safely defer it without breaking my site. It’s quite a good feeling!
I’m a NameHero team member, and an expert on WordPress and web hosting. I’ve been in this industry since 2008. I’ve also developed apps on Android and have written extensive tutorials on managing Linux servers. You can contact me on my website WP-Tweaks.com!
John Benedict says
How much have you tested this? Work on all the major browsers?
Bhagwad Park says
I’ve been using it on my production website for a few months now. Chrome and Firefox are both fine…
Great find, I was also looking for a way to defer my inline scripts. Can I use says it’s 92% supported in September 2020.
Interesting breakdown of the different defer / async
This has a major limitation which is that you cannot call module functions from outside the module. You would always have to export each function and import it from outside the module.