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!
🙂