asynced JS loads and executes faster then deferred JS, but the problem is you have no guarantee it loads in time for (in your case) the lazy-loading JS (which depends on jQuery) to function. so indeed async may sometimes work and sometimes not. so you could leave jquery excluded OR you could look for a lazy-load solution that does not rely on jquery? 🙂
Thread Starter
Anonymous User 14978628
(@anonymized-14978628)
Just a thought, but why not put all the js at the bottom of the page in one AO file, like you currently do, but have problematic scripts, such as jquery, also at the bottom but above the main AO JS so that it loads first before the other JS.
Would this not allow all JS to be non render blocking without the risk of something breaking?
I did try a non jquery lazy loading script before but experienced the same issue, but i think that might have been due to a conflict with another jquery dependent plugin which i only recently discovered. Making jquery non render blocking also caused some console errors with that plugin, although, it’s functionality didn’t seem to be affected.
I will give that another look however, thanks.
Just a thought, but why not put all the js at the bottom of the page in one AO file, like you currently do, but have problematic scripts, such as jquery, also at the bottom but above the main AO JS so that it loads first before the other JS.
main reason we’re not doing that is inline JS, which cannot (always) be aggregated or moved around and which indeed also may depend in jQuery 🙂
Thread Starter
Anonymous User 14978628
(@anonymized-14978628)
Is there any issue with doing the following?:
1) Don’t exclude jquery from AO so it’s aggregated with the other JS in the deferred AO JS file at the bottom of the page.
2) Copy the url for the jquery.js file and paste it in the footer so it appear above the AO JS file?
This would remove the render blocking jquery JS but still allow it to load before the other JS.
I’m not sure if this would cause it to load twice, or if there is some other technical reason why this shouldn’t be done (assuming there’s no inline js which depends on jquery?)
don’t think this would be truly useful;
1. jQuery would indeed be loaded twice; once stand-alone and once aggregated
2. the stand-alone version would probably still be considered render-blocking (even if at the very end, it still blocks the rendering of the _full_ HTML)
3. if there is no inline JS that depends on jQuery (and if you’re not excluding anything else), you should not need to exclude jQuery in the first place?
Thread Starter
Anonymous User 14978628
(@anonymized-14978628)
It just occurred to me as soon as i walked away from my pc that AO would still probably aggregate the other jquery.js url i would put in the footer. So that wouldn’t work anyway.
I have a plugin which uses jquery so can’t escape that. It seems to inline some js further down the page.
I will try the async again and see if that works and use another lazy plugin that doesn’t use jquery like you suggested.
Thread Starter
Anonymous User 14978628
(@anonymized-14978628)
Just a quick update.
So i found using async caused console errors. It appears my theme uses jquery and trying to make it non render blocking causes rendering issues with Googlebot in addition to the console errors.
Strangely, when i enable Rocketloader in Cloudflare, it adds the async but i don’t get any console errors or Googlebot rendering issues.
Does Rocketloader do something different to this plugin?
Does Rocketloader do something different to this plugin?
yes, it does, it has pretty advanced (some say hack-ish) logic to disable inline JS and re-enable it using other JS. if you google “rocketloader” you might find a more detailed explanation.
