I’m afraid I’m not that deep into sliders ossser, but maybe aj@wpfaster knows of slider plugins that allow full optimization? 🙂
In the mean while I would simply exclude jquery.js from optimization (forcing into head + try/catch have a bigger impact on perf.)
frank
To the best of my knowledge, ossser, all sliders with any degree of functionality (Master Slider, Slider Revolution, Soliloquy etc) have jQuery dependencies and almost always inline scripts that can’t be aggregated.
This however, will effectively render jQuery in a non-blocking fashion: https://www.wpfaster.org/blog/when-and-how-to-load-jquery-from-googles-cdn 🙂
Be well,
AJ
AJ; what if we could wrap such inline JS in a poller (setTimeOut) which checks for jQuery being defined and if not continues polling and once jQuery defined loaded executes the payload? should work, no?
It should, Frank.
However, some issues might be: Firstly — if speaking of Chrome — Chrome (the browser itself) runs its own experiments and does not always behave in accordance with even the most technically executed, brilliant trickery 😉 This is one of the reasons why CloudFlare’s Rocket Loader doesn’t always work in Chrome or Firefox (very similarly constructed browsers), in spite of re-executing JavaScript in the exact order in which it appears in the HTML but after onload.
Secondly, and I think this is more important: Sliders, when they are, are above the fold content… This raises, I think, two sub-points:
1.) We ought not be deferring anything that is going to be jarring to the user if executed later than indented. (This is one of the points at which the layman misinterprets GPSI, in spite of it being a layman-centric tool).
2.) Again with Chrome: Chrome, during its parsing of the page, may ‘decide’ that it needs jQuery to render the page properly, and wait for jQuery to load before painting will begin in spite of jQuery being deferred or asynchronously loaded with standard attributes; or, via the method you’re talking about.
I’d certainly love to see some experiments though, Frank. It could certainly work and do so consistently. But either way, it seems to me, we have a render-blocking scenario/a situation in which the browser is waiting for jQuery to be defined.
AJ
P.s. Sorry if this reads a bit muddled. I’m running on about 3 hours of sleep in 3 days.
I’ll put this on my wild ideas list, who know what’ll come of it (if/ when I find the time) 😉
Thread Starter
ossser
(@ossser)
Thanks for prompt reply Frank/AJ.
I found a solution to this. I ditched Masterslider (which uses jquery) and purchased CSS Slider (uses mostly CSS – enough for my needs). Only two js files inside my saved CSS Slider plugin are tinymce_plugin.js and ie.js – whether or not they used a lot not sure.
I’m able to enable the setting ‘Optimize JavaScript Code’ ONLY (in Autoptimize) leaving all others disabled (NB if I enable other settings eg. include in <head> or exclude jquery I receive huge dint in performance.
I also purchased ‘Indeed My Testimonials‘ which uses mostly CSS to render – there is no conflict with this – like before. There was conflict with my previous testimonials plugin and this is why I changed.
I am really happy with my website performance thanks to your plugin Frank.
Also, I purchased AJ @ WpFASTER.org course, thanks AJ!
Website:
https://protoncleaninggeelong.com.au
NB I use Cloudflare with Rocket Loader.
Some results:
Google Insights: 85% Mobile, 90% Desktop (non cached)
@www.webpagetest.org – SpeedIndex Avg: 1500
Am hosted at Wpengine – I was able to install and use EWWW Image Optimizer (Cloud version) which is compatible @ Wpengine – however, not the original non-cloud version – thanks for the suggestion AJ.
thanks again to you both!
Osssr (Mark)
Wonderful. 🙂
You’re certainly a step ahead of the rest now, ossser (and I’m always there in the course to help you, you need but ask).
WordPress performance optimization summed up in three words: Test, test, test. 🙂
Be well,
AJ
