Reading through the documentation I found the topics on enqueing, dequeing and how this ties in with compiling matters into nice tiny scripts. With this in the back of my mind I (apologies) ran some tests on the getbeans.io site, figuring if there's one perfect beans site it'll be that one.
While both in general and in many specific details the results show how it leaves other frameworks and framework created themes far in the dust (not kidding), there's one thing which does remain: something commonly known as the Above The Fold Challenge.
To make a long story short, the only remaining thing to "out of the box" deal with it comes down to javascript presence. One thing I picked up from getting ran over by Google's code magicians was that this is not a case of "just defer" or "just use async".
The key is actually allowing a webpage to fully load and then (and only then) loading external JS.
And that has consequences for both design and code focus. It comes down to designing so that the page / content is presented functionally to the user before effectively activating functionality.
Which means you have to resort to code right at the last stop, just before the actual closing body tag. I presume people can see the challenges this represents.
There is an effective method though. I am however not sure whether or how this could fit with beans.
<script type="text/javascript">
function downloadJSAtOnload() {
var element = document.createElement("script");
element.src = "yourdeferredscript.js";
document.body.appendChild(element);
}
if (window.addEventListener)
window.addEventListener("load", downloadJSAtOnload, false);
else if (window.attachEvent)
window.attachEvent("onload", downloadJSAtOnload);
else window.onload = downloadJSAtOnload;
</script>yourdeferredscript.js is the awesomely compiled single script bean produces. Simply put, this way it waits until the page fully loads, and only then it pushes the big red button. So to speak.
The one consequence/consideration I can see is that the order of scripts compiled into the single bean script is highly important. Ideally a good design does not require scripted support to load the page, an alternative design approach follows from that. What also becomes clear is that it is very important to categorise the actual scripts used on a page: that which is needed for the page to load, and that which is needed for doing stuff after it loads.
The nice thing is that beans is awfully close to the mark. Depending on what is introduced upon customisation that can easily become more complicated, obviously. It strikes me that this is a big case for sticking with beans API guidelines. But beans does not (yet) follow the abovementioned methodology.
After this wall of text, the question should be clear: is it possible to enable beans to utilise that methodology?
Adding async to all js files might cause some problems. anyways here is the code. copy and paste it.
function hyperindian_defer_attribute($url) {
if FALSE === strops($url, '.js')) {
return $url;
}
return '$url' defer='defer';
}
add_filter('script_loader_tag', 'hyperindian_defer_attribute', 11, 1);it doesn't matter if you add async or not but in the end its your content which will appear on google. so write good content you'll have a good seo ranking. you don't have to fix all the issues that shows up on google page insight.
I appologize for any mistake because i wrote this on my cellphone.
I may doing something wrong, but adding async does not solve it as such. Good content, I should mention, is weighted after data structures & relations. As I understand it that's an emphasis set to increase following AMP.
Anyhow 😛 Beans already does an amazing job of combining & compiling. Which makes me wonder whether it would not be possible to change the location within the generated markup where beans outputs the generated js in line with the abovementioned method.
IDK about that but one more thing you canot add async or defer to every script. IDK why but wordpress doesn't allow you to do so. And if you use any plugin then you cannot add async or defer in their script and by chnce if you add that tag this might cause your website with various issues.
There is a reason why WP is a bit touchy in these matters, or rather, there's several reasons. One of the older ones is the commercial focus on wordpress.com, where specific integration / optimisation / feature / project paths are considered to fall within that realm. That it's not going very far (it's been years) is clear, but that's a matter of organisational prioritising. One other reason is that a lot of what is out there comes from a much older time, in many ways it's a legacy issue. And a big third reason is that Wordpress is a market, where sizeable marketplaces provide solutions which focus more on feature capability rather than concepts which actually carry seo / data relation benefits to end-clients.
That said, javascript itself is tricky either way. There is however something to be said in favour of a framework which provides best practices. It isn't as if it's not possible to adher to proper deferrance, it's just that convenience and third party commercial aspects make it a trench of choice dependancies.
As I said, in many ways on a project level it's a design issue first, code second. Now I could be wrong, but I think beans isn't just a theme framework. I'm getting the idea that it is also capable of feature layers (or projects, as the WP people are now claiming to want to call it): plugins and widgets. This however might be something to take up in the Extend section, but it would be nice to see some hands-on samples & concepts.
Seems to me, beans is at a point where it still is possible to make root choices in these matters. Obviously that ties into questions on what beans wants to become (open source, commercialisation, anything in between). But as I said, I'm getting the idea that with beans it is possible to completely sidestep the usual pitfalls. Now that, would be worth something.
Hey guys,
When it comes to enqueueing files, Beans uses the core WP enqueue method so there isn't any added control over the HTML script tag output. Beans offers high level of customization when it comes to enqueueing UIkit components and compiling assets on a per page basis but do the final enqueue the WP way to make sure it is compatible with other plugins.
Asynchronous loading is something which is very specific to a project and has to be configured accordingly. It is important that Beans work smoothly with other plugins and that level of customization would cause issues if it was automated.
There are plans to make it possible to load some UIkit componenst in a separate file to make it possible to load some components asynchronously depending on the project need but I have no ETA for that.
Feel free to share what ever solution you come up with in the end 🙂
🙂 Well, correct me if I am wrong, but isn't there already support for specifying the order of scripts to load? That is a big step already.
I did some twitchy messing around with - essentially - forcing the use of the abovementioned downloadJSAtOnload method. To my surprise, for beans + uikit "as is" this did not present any issues. Solving the Above The Fold thing.
But you raise a good point. When I tried that with a test where a third party nav widget was in place ... suffice to say it wasn't pretty. Now if that widget were built with beans (TM) 😛
Hehe, plugins and widgets built with Beans will come in the future 😉
I want that future now!
🙂