Over the years I have encountered trends of development and design concepts and aspects that I consider flawed. In many of those cases, the industry eventually realises they are based on flawed logic and either replaces them with something else or switches to alternative methods. In my opinion, this is another one of these situations. What most likely happened was that one performance site probably used it and the rest eventually copied it for inclusion in their own so-called "performance" testing methodologies in order to seem more legitimate because if other speed test sites are using it, then how can they not.
When the performance testing sites use the phrase "render blocking" they are referring to external javascript code (<script src="...">) that is located near the top of your page. Of course, JavaScript was always designed to be placed and loaded within the <HEAD></HEAD> tags, structure wise, because in most cases, JavaScript helps format the presentation of the page.
This is where the flawed logic comes into to play for me. If you are using JavaScript to alter elements on the page and/or to retrieve content via ajax calls, why would you want to show the user the page before it is finished or at least formatted correctly?
One of my biggest issues with the design of a site is what I refer to as "user disorientation". User disorientation happens in two situations. The first is when common elements change locations from page to page such as a menu. If a menu is on top of the page, it should remain on top as you navigate the site as long as the viewport (window) does not change sizes. The second situation of user disorientation is when a page is loading and, as a user, you see the page displayed before its design and presentation have been completed, so the page starts shifting (jumping) around as more elements are propagated with ajax powered content and/or selective show/hide processing.
My point is that this "render blocking" so-called "performance" trend right now is pointless and the industry will soon realise that and remove it as a scoring weight. With front-end development growing in popularity with javascript frameworks such as Angular (Google) and ReactJS (Facebook), you are going to see more and more sites requiring scripts to be loaded before the page can show no matter where the external scripts are loaded within the page.
My suggestion is to ignore the final score and the "OMG stop the render blocking" warnings they throw at you and focus on the other areas, if there are any, where those performance sites suggest you could improve your site. Even better, avoid those performance sites all together and ask your users directly how your site performs for them. To most users, any page that loads (not generates, but loads) in 1.5 seconds or less will be fast and anything under 1.0 second will be considered "instant" so I would not worry about it.
Besides, HTTP/2 for the most part makes "render blocking" a non-factor on all but very slow bandwidth users as it loads everything at the same time.
XenForo is very fast and, like most sites, it leverages browser caching to make all pages after the first page load much faster. All of those so-called "render blocking" scripts will be cached after the first page view and become a non-factor on the rest of the pages.
