Are there any scripts Beans natively uses / creates (so nothing Third Party) which are needed for the page to load properly. I mean, things which set positions, layout, things like that.
A second question: is there a way to tell Beans to compile its javascript with a specific filename?
(reason I ask is I'm trying to figure out a way to seperate any third party stuff from beans scripting to get things ready for the august Google changes for Above the Fold). I think I have a way, but right now it's theory.
Hey J.C.
Beans uses javascript (actually UIkit does) for some components such as the grid margin on resize, off-canvas menu etc. If you don't want it, you can totally remove Beans UIkit JavaScript using the following snippet:
add_filter( 'beans_uikit_euqueued_scripts', '__return_false' );You cannot change the filename as this is what determines what is included in the file and whether it should serve the static file or re-create a new one if other UIkit components where added. It is part of Beans intelligence and the reason it is so fast, so changing the filename would mess it up.
You may however control over what is included and your are not forced to have it compiled with other third party files by not enabling the Admin->Appearance->Settings Compile all WordPress scripts option. If that option is disabled, UIkit script is output in the head tag but you can change that using the following snippet:
add_filter( 'beans_uikit_euqueued_scripts_args', 'example_uikit_euqueued_scripts_args' );
function example_uikit_euqueued_scripts_args( $args ) {
return array_merge( $args, array( 'in_footer' => true ) );
}Hope that helps,
That's the thing, I'm not sure whether the UIkit js is required for inserting layout elements, it is however clear that parts of it are required for things like interaction. As far as I can tell, it is all the kind of interaction which is fine to load once the page itself is rendered.
I suppose this is the real crux though, if the above is the case, it should be perfectly ok to move everything (beans compiled js) to the footer. Leaves only to be careful with any third party stuff one might have, but most of that (for example Google Analytics, map script) is not required in the header anyway.
That said, beans itself - so besides the uikit beans contains - does not use any scripting? That would be quite neat. Very different from just about every typical (commercial) theme framework.
As for the filename, hm. Damn. The idea I had in mind was to compile to a specific name, which I could then append to body for eventlistener / attachevent.
Hm.
The snippet you gave, that is interesting. But - if I understand it correctly - this does require giving up Beans ability to keep everything tidy in a single output file?
What about placing the beans compile output in the footer by default? It would be a change for people, since the de factor standard seems to be to dump it all in the header, even though that's most of the time not needed, can easily complicate matters, and is about to get heavily sanctioned by Search. Keep in mind, I'm still trying to wrap my head around this, but it seems to me that as this is a tech adoption change either way, wouldn't it be an idea to be ahead of the curve?
Not sure if this makes sense, but Beans outputs a compiled script. Does this generated script, even though it is randomly named, carry an identifier within the Beans framework which can be read or picked up by a function?
Hey J.C.
Beans itself does not require an JS, only the JS in UIkit is used which is part of its beauty 🙂
What about placing the beans compile output in the footer by default?
If you enable Admin->Appearance->Settings Compile all WordPress scripts and set it to Aggressive, it will automatically output it in the footer 🙂 In fact this is the difference between Standard and Aggressive as explained in the option description (click on More...).
From there, Beans Compile all JS (third party included) and enqueue the script in the footer using WP Core Enqueuing API. So you may search for various technics to lazyload script, maybe using preg_match for the url containing /beans/compiler that way the dynamic filename doesn't matter since /beans/compiler never changes.
Hope that helps,
Gah, that's what happens when you look too deep in the microscope, you miss the details 😛
Now that you mention lazyload, makes me curious to see how Beans matches with memcache and third party tools like wp-rocket which utilise a cache mechanism for such purposes.
Anyhow, I must be doing something wrong on this end, I had a look at the aggressive option. When I have that active, I see the script hugging the closing body tag, but it's still marked as render blocking. I ran the same tests for www.getbeans.io, where - somehow - the js is not blocking. The only difference I can see, takes us back to uikit: no off-canvas.
Hey J.C.
Since Beans euqueues all scripts using the Core WP Enqueue (the way it should be), caching plugins such as WP Rocket work smoothly 🙂
Regarding Beans official website no trowing an error, the offcanvas does not cause an issue as if you test Beans Demo you will see that the JS is not marked as JS blocking. I am not entirely sure why it would complain on your website. Maybe post a link which might help finding out what the issue is.
Thanks,